■_
ジュンク堂新宿店
今の場所からなくなるのは確定と。
コンピューター関連の洋書の扱いが徐々に少なくなってきてて
それにあわせてあまりいかなくなったなあ。
交通費からいうと新宿店も池袋店も変わらないし。
新宿店だと代々木の方へ行って紀伊國屋書店の新宿南店も回るというのができるけど
(池袋店だと電車降りないと)。
4年間続いた「さよなら絶望放送」が本日の配信でさよなら～ :おた☆スケ
こもりきりぞうさんが…
2011年08月30日
![YOUNGKING OURS (ヤングキングアワーズ) 2011年 10月号 [雑誌]](http://ecx.images-amazon.com/images/I/61jE-vPj98L._SL160_.jpg)
■_ SWIG
Why the author of SWIG 'hates' SWIG とか
Why the author of SWIG 'hates' SWIG... : Python Why the author of SWIG 'hates' SWIG... (code.activestate.com)Everything he has said here makes perfect sense. In order to correctly parse C++ code you basically need a full C++ compiler. What's more, you need the compiler to be the same compiler as the compiler you are actually using (due to differences in different C++ compiler parsing). This is one of the reasons I really approve of the approach that boost::python takes to python binding: It uses the built-in C++ knowledge of the type system and code structure that the compiler itself uses to bootstrap the binding code.But building your import module, packaging, etc become a huge pain. I much prefer either ctypes or Cython/Pyrex myself.I agree with the ctypes approach - you provide the linkage info by defining the interface between the library and python, you make it work. No huge expectations that the binding between one extremely complex system (C++) and another very complex system (python) should be easy or magical. If it's hard, it's hard, and you don't get to turn your problem into someone else's (and then complain that free software doesn't have any support for simple things like reading your mind :)Building is a pain, particularly on Windows where you don't have a packager to deal with Boost for you, because Boost is an asshole. It's one of those problems you just need to solve once, though. (And take good notes.) I had a much better time of things after I decided to ditch bjam and use waf.Having recently used SWIG, I was very much interested in the idea of being able to write a single definition file that produces bindings for a variety of languages. The first problem I encountered was that SWIG doesn't handle callbacks, but the library I was wrapping used callbacks. I figured this out, but it required some Python-specific typemaps. "No problem," I thought, "at least I can just write the callback stuff for each language, and SWIG will take care of the rest." However when I got to looking at Java and dealing with representing callbacks in listener objects, I went and learned a little about JNI and realized it wouldn't be so hard to just write the wrapper directly in JNI. Then I looked at other languages, and realized the number of corner cases I'd have to handle with SWIG for each language, and sort of threw up my hands... I also realized it might have been less work to use ctypes in the first place for Python. So in the end I have a SWIG binding which is Python-specific and a Java binding, and haven't really gotten around to thinking about other languages because I'm scared off by the idea of having to learn the ins and outs of n runtime engines. I still think a multi-language binding generator is a great idea and would be immensely beneficial. However, SWIG doesn't go far enough, as it's too tied to C types. Higher-level languages require higher-level types. For instance, in a sort of Haskell-inspired way, in my SWIG binding I defined a "maybeFloat" typemap for functions that took a pointer to a float, where the pointer could be NULL. Then I just had to define a typemap that translated Python numbers to float and passed in its address, or translated None to NULL, or threw an exception otherwise. If higher-level typemaps like this can be used to describe the semantics of a C function beyond the C semantics but instead cover the semantics of the target language, then perhaps this approach could work. The lack of callback support was a show-stopper for me, though, in terms of using SWIG for multiple languages.I love C++, I really do. I think C++ is an amazing language. That being said, C++ is a horrible thing to use in a library. If I would want to write a library in C++ I would do it like zmq does and provide a C API from it. As such I would write a tool that automatically generates a C API/ABI from a C++ API and then automatically generate Python bindings for that via ctypes. And yes, clang would be the tool of choice for both parts.Also, you can't dynamically link to C++ API.Regarding writing libraries and plugins in C++.. I do like C++ for giving me features that save me time while developing. Foremost the STL (yay std::vector<T> and algorithms). I really don't want to implement and maintain these basic data structures myself, like you see in so many C programs. Another thing I love is being able to define interfaces via abstract classes. If I screw something up while i.e. doing heavy refactoring the compile just tells me. A real time saver. But what drives me nuts is when you compile a C++ plugin and the proprietary host program, written at least partly in C++ as well, crashes randomly all of the sudden. The reason: STL implementation/version mismatches. This happens even if you're using a C API provided by this C++ host. Debugging these issues is a nightmare, require deep knowledge and determination. Many of my colleagues aren't even C++ coders and it would be virtually impossible for them to handle these situation, let alone within a reasonable amount of time. I'm sure one can work around all these issues. Boost.org's unholy trend to have header only libraries is one way to solve this issue and make compile times binary sizes explode. The question is if it's worth the hassle. These days I still write i.e. python modules in C++ when I hit a bottleneck, since the code just flows out of my fingers. But when I know something will be used outside of my machine I rather sit down I learn how to write yet another C implementation of a basic data structure, knowing that my code will work just fine for the next 10 years.
元記事を読まないと何がなにやらw
■_
I'm starting Functional Programming class next semester and I have few questions. (repost from /r/compsci) : lisp (Repost from http://www.reddit.com/r/compsci/comments/jy4tn/askcompsci_im_starting_functional_programming/) In October, I'm going to attend FP class (last year of MSc studies). As far as I heard from friends, there will be two major assignments for this class: one Haskell project, and one report on some other functional programming language, each student picks one. Moreover, the class will also cover theoretical aspects of FP, such as lambda calculus. 十月に、わたしはFPクラス (last year of MSc studies) に参加しようと思っています。 友人から聞いたところでは、このクラスには二つの majro assignments があるのだそうです。 ひとつは Haskell project で、もうひとつは何か別の関数プログラミング言語についての report です。学生はそれぞれひとつ選択します。 加えてこのクラスでは、ラムダ計算のような FPの理論的な背景もカバーするそうです。 I have only little experience with FP, mainly some Haskell and Scala, nothing serious though. わたしはFPについてはほんのわずかの経験しかなく、HaskellとScalaを ちょっと使ったことがあるだけです。 My questions are: わたしの疑問は以下の通りです: * Which other FP language should I pick and why? (it doesn't have to be Lisp) I'd like to know how they compare in terms of popularity, difficulty, tool support, novel ideas, non-standard ways of problem solving. I want my choice to be potentially useful in my career and/or to help me broaden my horizons. Haskell 以外のFP言語としてどれを選択すべきで、またそれはなぜでしょうか? (これはLispである必要はありません) * What good on-line and/or printed materials on FP would you recommend? Language tutorials and also more theoretical stuff? I'd especially appreciate good materials on lambda calculus, because apart from the name I don't know anything about it. * Is there anything I should keep in mind when trying to understand all of it, especially if it's counter-intuitive for someone used to imperative programming or typical maths? * Apart from FP languages and lambdas what else should I expect? * Full name of the class is actually "Equational and Functional Programming". What does "equational programming" mean and does it differ from FP? Thanks in advance.It must be Lisp. (disregard username)Apart from FP languages and lambdas what else should I expect? Purely Functional Data Structures.As soon as I take a photo of it at faculty building and translate it to English, so not sooner than in 20 hours. Our faculty does a rather sloppy job with updating the website, some subjects' syllabi are not available on-line. I managed to find a part of recommended literature list: J.Fokker's Functional Programming, Hugs98 User Manual, R.Page's Two Dozens Short Lessons with Haskell and The Craft of Functional Programming EDIT: and also L.C. Paulson's Foundations of Functional Programming, and H. Barendregt's Lambda Calculi With Types and The Impact of Lambda Calculus in Logic and Computer Science As I said, I'll post more tomorrow.
■_
5 Reasons To Write Tests For Your Code - Master Nerd's Guide to the Force August 29, 2011 5 Reasons To Write Tests For Your Code あなたのコードのためにテストを書く五つの理由 I hate to admit it, but I wasn't always an advocate of writing tests. My past self understood tests to be good practice; but typically saw them as a luxury. Like fine china, they were shiny, but not something I could afford. That being said, if I could go back I would certainly have some brutal lessons to share. So as my first post, here are five arguments that I believe would convince my past self to write programmatic tests. I hope that these can convince others who are debating whether tests are worth the time. 1. Tests use programming skills to check programming skills. テストはプログラミングのスキルをプログラミングのスキルをチェックするために使う 以下略
■_
- ＞ これ | OKWave
- Big Sky :: Googleから小包届いた
- Island Life - 因果律を否定するバグ
- 晴読雨読＠エンジニアライフ: 『Being Geek』――スペシャリストかPMか？ 望むキャリア戦略を実現する
- 社内ネットワークで困っています。助けて下さい。(1/2) | OKWave
- Amazon.co.jp： Scalaスケーラブルプログラミング第2版: Martin Odersky, Lex Spoon, Bill Venners, 羽生田 栄一, 水島 宏太, 長尾 高弘: 本
- Short Code: 燃え尽きていました
- 30歳を過ぎても現役エンジニアでいるために必要なこと － ＠IT自分戦略研究所
- ブロック構文はC++アルゴリズムに突っ込める - 名古屋３１３の日記
- プログラム言語での孟母三遷の教え - きしだのはてな
- 多忙なデベロッパのサイドプロジェクトの展開運用を代行するBushido
- wrong, rogue and booklog - ドイツZDF-Frontal21 福島原発事故、その後（日本語字幕） (by...
- C++ 11 Concurrency Tutorial - Part One
- e frontier store（イーフロンティアストア) - Shade・Poser・AQUAZONE・直販サイト
![シリコン・バレーの百年 [DVD]](http://ecx.images-amazon.com/images/I/5164ZM6gPhL._SL160_.jpg)
![ディスカバリーチャンネル アップル再生: iPodの挑戦 [DVD]](http://ecx.images-amazon.com/images/I/41yvDfcWfqL._SL160_.jpg)
![日経ソフトウエア 2011年 10月号 [雑誌]](http://ecx.images-amazon.com/images/I/615Rig2dHnL._SL160_.jpg)
