一つ前へ
2012年1月(下旬)
一つ後へ
2012年2月(中旬)
まんがライフオリジナル連載の「ういういDAYS」も次回が最終回とか (最後のページの柱にそうあった)。
グラフ(チャート)色々
パイチャートとか棒グラフとか色々ありますよね。
あれってどこかにカタログのようなものないでしょうか。
本でも何でも良いのですが、このグラフ(チャート)はこういった用途に向いている
といった解説もあるとなおよし。
で、それと関連して「プロジェクトの状態の可視化」でいい表現方法はないものでしょうか? 進捗(の度合い)ではなく、ある時点で切り取った状態。 進捗を関数で表せるとしたならその微分を求めるとか (自分で書いててよくわからなくなってきたw)。 ジュンク堂でプロジェクト管理やらなんやらの本をいくつか見てみたけど これというのには遭遇せず。 みなさんどうやってプロジェクト管理してるんでしょう (ってその本通読すればいいんだろうか)?
MicrosoftのC++コンパイラーが最初のリリースから20年だそうで。 MS-C/C++ 7とかVisual C++ 1.0って確か買ってたよな (今よりよほど余裕があったらしいw)。 さすがにマニュアルの類は処分しちゃったけど (この頃は分厚い紙のマニュアルが何冊もついてきた)、 インストールメディアは残しているはずだな。どこだろ。
The Microsoft C++ Compiler Turns 20! - Visual C++ Team Blog - Site Home - MSDN Blogs The Microsoft C++ Compiler Turns 20! 3 Feb 2012 8:30 AM Microsoft C/C++ 7.0 This month, we enter the third decade of C++ at Microsoft. It was twenty years ago, in February of 1992, that we released our first C++ compiler: Microsoft C/C++ 7.0. Before then, we already worked with several of the C++ “preprocessor” compilers that took C++ and converted it to C before our compiler then created the executable program. But starting in 1992, Microsoft's premier native compiler supported C++ directly, and has done so ever since. 20年昔、1992年の2月にわたしたちの C++ コンパイラーである Microsoft C/C++ 7.0 を わたしたちはリリースしました。それ以前にわたしたちはすでに C++ の入力を C へと変換してからわたしたちのC コンパイラーで実行ファイルを生成する ような C++ "プリプロセッサー" コンパイラーをいくつか使っていました。 しかし1992年のはじめ、Microsoft の premier native compiler は直接 C++ をサポートしました #has done so ever since って･･･そうだっけ? #英文の意味を取り違えてるか C/C++ 7.0 shipped in a box that was over two feet long and produced MS-DOS, Windows and OS/2 applications. It also sported the last of the character oriented development environments for C that we ever shipped – the following product was Visual C++, which built on what we had learned from delivering QuickC. Since those early days, we have shipped eleven major releases of C/C++ products (ignoring small point upgrades) for both Windows and embedded development. C/C++ 7.0 は2フィートを超える長さの箱に詰められて出荷されており、 MS-DOS、Windows、OS/2 のアプリケーションを生成するものでした。 このコンパイラーはまた、わたしたちが出荷した最後の character oriented な C 向け開発環境 でした。このあとの製品は Visual C++ で、これはわたしたちが QuickC の delivering から 学んだことに基づき開発されたものでした。 そういった時代から始めて、わたしたちは11個の major リリースを Windows 環境向けおよび組み込み環境向けの C/C++ 製品で行ってきました (小さなアップグレードは無視しています)。 (略)© 2012 Microsoft Corporation.
特に初期のMFC(の内部構造やら設計やら)については書きたいことがあるんだけど、資料集めがままならない。 あまり熱心にやっていないというのはある。
しかし「20年前」が「1992年」という事実に改めてショックを受けた(謎)
コメント欄がだいぶ賑やか
Betrayed by a bitfield [LWN.net] Betrayed by a bitfield By Jonathan Corbet February 1, 2012 Developers tend to fear compiler bugs, and for good reason: such bugs can be hard to find and hard to work around. They can leave traps in a compiled program that spring on users at bad times. Things can get even worse if one person's compiler bug is seen by the compiler's developer as a feature - such issues have a tendency to never get fixed. It is possible that just this kind of feature has turned up in GCC, with unknown impact on the kernel. developer はコンパイラーのバグを恐れる傾向があって、それには理由があります: そういったバグは見つけるのが難しく、回避するのも難しいからです。 developer はコンパイル済みのプログラムにある罠を放置できます #that 以下のこれなに… ある人にとってのコンパイラーバグが、コンパイラーの開発者によって機能だとみなされた りすると事態はさらに悪化します。そういったものは決して修正されない傾向があるのです。 One of the many structures used by the btrfs filesystem, defined in fs/btrfs/ctree.h, is: struct btrfs_block_rsv { u64 size; u64 reserved; struct btrfs_space_info *space_info; spinlock_t lock; unsigned int full:1; }; Jan Kara recently reported that, on the ia64 architecture, the lock field was occasionally becoming corrupted. Some investigation revealed that GCC was doing a surprising thing when the bitfield full is changed: it generates a 64-bit read-modify-write cycle that reads both lock and full, modifies full, then writes both fields back to memory. If lock had been modified by another processor during this operation, that modification will be lost when lock is written back. The chances of good things resulting from this sequence of events are quite small. Jan Kara は最近 ia64 アーキテクチャ上においてこの lock フィールドがときおりおかしくなる (corrupted) ことを報告しました。多少の調査の結果、GCC がビットフィールド full が変更された ときにおかしな振る舞いをしていることがわかりました。 詳しく書くと、コンパイラーは lock と full の両方を読み込んで full を変更するような 64bit の read-modify-write cycle を生成していたのです。 One can imagine that quite a bit of work was required to track down this particular surprise. It is also not hard to imagine the dismay that results from a conversation like this: I've raised the issue with our GCC guys and they said to me that: "C does not provide such guarantee, nor can you reliably lock different structure fields with different locks if they share naturally aligned word-size memory regions. The C++11 memory model would guarantee this, but that's not implemented nor do you build the kernel with a C++11 compiler." Unsurprisingly, Linus was less than impressed by this response. Language standards are not written for the unique needs of kernels, he said, and can never "guarantee" the behavior that a kernel needs: #Linus のおことば #言語の標準というものはカーネルのためだけに作られたものじゃないし #カーネルが必要とする振る舞いを“保証”することはできない # でいいのかな So C/gcc has never "promised" anything in that sense, and we've always had to make assumptions about what is reasonable code generation. Most of the time, our assumptions are correct, simply because it would be *stupid* for a C compiler to do anything but what we assume it does. But sometimes compilers do stupid things. Using 8-byte accesses to a 4-byte entity is *stupid*, when it's not even faster, and when the base type has been specified to be 4 bytes! しかし時としてコンパイラーがばかげた動作をすることがあります。 そうすることでそれほど速くならないときや その base type が4バイトであることを指定しているときに 4バイト長のエンティティのために 8バイト長のアクセスをすることは *馬鹿げています*。 As it happens, the problem is a bit worse than non-specified behavior. Linus suggested running a test with a structure like: 実際に起こった場合、この問題は不定動作 (non-spcified behavior) よりもたちの悪いものです。 Linus は次のような構造体を使ったテストの実行を提案しました struct example { volatile int a; int b:1; }; In this case, if an assignment to b causes a write to a, the behavior is clearly buggy: the volatile keyword makes it explicit that a may be accessed from elsewhere. Jiri Kosina gave it a try and reported that GCC is still generating 64-bit operations in this case. So, while the original problem is technically compliant behavior, it almost certainly results from the same decision-making that makes the second example go wrong. この場合、b に対する代入で a に対して書き込みが行われるとその動作は明らかにバグです。 volatile キーワードはどこからでもアクセスされる可能性があることを明示します。 Jiri Kosina はこれを試し、これに引っかかるような 64ビットオペレーションをGCCが 生成することを報告しました。 Knowing that may give the kernel community more ammunition to flame the GCC developers with, but it is not necessarily all that helpful. Regardless of the source of the problem, this behavior exists in versions of the compiler that, almost certainly, are being used outside of the development community to build the kernel. So some sort of workaround is likely to be necessary even if GCC's behavior is fixed. That could be a bit of a challenge; auditing the entire kernel for 32-bit-wide bitfield variables in structures that may be accessed concurrently will not be a small job. But, then, nobody said that kernel development was easy.Copyright © 2012, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds
禅プログラマーにしちゃうと意味が変わってしまう気がするんだけど さてどうしたものか(実のところどーでもいい)
The 10 rules of a Zen programmer « Grobmeier on Dart, Java, Struts, PHP and more The 10 rules of a Zen programmer On a rainy morning I found myself sitting on the desk thinking about efficient working. Before I started as a freelancer I had some days were I worked lots but could look only back on a worse outcome. I started with Zen practice back in 2006. What clearly came to my mind before a good while was: the old Zenmasters alredy knew before hundreds of years, how today programmers should work. Even when I don't like these “be a better programmer” posts, I want to outline some of my thoughts from that morning. It shall serve me as a reminder, but if you have some ideas about it, feel free to comment. 1. Focus (集中する) If you have decided to work on a task, do it as good as you can. (略) 2. Keep your mind clean (心をクリーンに保つ) Before you work on your software, you need to clean up your memory. (略) 3. Beginners mind. (初心者の視点を忘れない) Remember the days were you were a beginner. Or memorize, if you still are one. (略) 4. No Ego. (自儘に振舞わない) Some programmers have a huge problem: their own ego. But there is no time for developing an ego. There is no time for being a rockstar. (略) 5. There is no career goal. (キャリアに終わりはない) If you want to gain something and don't care about your life “now”, you have already lost the game. Just act as good as you can, without looking at the goal you might reach after a long time. (略) 6. Shut up. (黙る) If you don't have anything to say, don't waste the time of your colleagues. (略) 7. Mindfulness. Care. Awareness. Yes you are working. But at the same time you are living and breathing. (略) 8. There is no Boss (ボスはいない) Yes, there is somebody who pays you. There is somebody who tells you what needs to be done. And he can fire you. But this is no reason to give up your own life or to become sick of your work. Finally your Boss has no control about you. It can even be doubted that you have control about you – but don't lets go down this path. (略) 9. Do something else (ほかのことをする) A programmer is more than a programmer. You should do something which has nothing to do with computers. In your primetime, go sailing, fishing, diving. Do meditation, martial arts or play Shakuhachi. (略) 10. There is nothing special. (特別なものはない) A flower is beauty. But it's just a beauty flower – nothing more. There is nothing special around it. You are a human who can program. Maybe you are good. There is nothing special around you. You are of the same kind as I am or all the others on this planet. (略) Disclaimer (おことわり) I am not a Zen monk. I am just practicing and learning. Please ask your local Zen monk if you feel there is something you need to understand deeper. Of course I can try to answer on this blog, but well, I am just a beginner. Anyway I am glad about your comment and if you would send a tweet with this pages url if you liked this post. Thanks for reading! Posted on Friday, February 3rd, 2012 at 8:52 pm
ちと意訳に過ぎたかも＞見出し
fogus: Where is LL.next? Where is LL.next? Feb 10, 2012 Some time in late 2001 MIT held an event called the Lightweight Languages Workshop or LL1 for short. While I'm certain the event itself was influential to those in attendance, the truly magnificent byproduct of the workshop was the associated LL1 mailing list. Scanning down the messages to that mailing list reads like a roster for the programming languages hall of fame. The topics on display, from historical recollections to bleeding edge to wholly new topics (that we've yet to catch on to in many cases), are of a ridiculously high quality that almost any random thread puts every current outlet of rampant opinion to shame. 2001年の終わりごろ、MIT で Lightweight Languages Workshop 、短い名称では LL1 と 呼ばれたイベントが開催されました。 #でそのイベント(ワークショップ)は影響力があって云々 #ワークショップに関してメーリングリストがあって And that's a problem. There is a true gap in the computing ecosystem since the LL1 mailing list went silent. Certainly there are other important mailing lists and message boards in operation today, including Fundamentals of New Computing, Squeak-dev, and (at times) Lambda The Ultimate, but none of them have the same mix of breadth of conversation and tone of respectfulness of LL1. そしてそれが問題なのです。 LL1 メーリングリストが沈黙してからの computing ecosystem には true gap が存在しています。 確かに、現在も稼動している重要なメーリングリストも Fundamentals of New Computing, Squeak-dev, Lambda The Ultimate のような メッセージボードもありはします。しかしそのどれひとつとして the same mix of breadth of conversation and tone of respectfulness of LL1 というものを持っていないのです。 The world needs a new LL1. But it's not as simple as just putting together a mailing list and calling it LL.next. Any LL.next mailing list would need most (if not all) of the following to garner even a hint of the magic in the old: 世界は新たな LL1 を必要としています。 しかしそれはただ単にひとつのメーリングリストに集めてそれを LL.next と呼べばよい という単純なものではありません。すべの LL.next メーリングリストは 以下に示したことの (すべてでなければ) 大部分が hint of the magic in the old (旧世界の魔法のヒント?) でさえも 集めるために必要です。 A bevy of thought leaders thought leader たちの集まり Supplemented with a bevy of open-minded and respectful enthusiasts A general desire to push the collective envelope as opposed to individual agenda Thoughtfulness An enthusiasm for the new, with a deference to the past No sacred cows Invite only (maybe — depending on the following) Fair but firm moderation A clear focus on the goals of said list Where is this LL1.next, and who are the right people to get it started?
くー微妙に訳しにくいぞ(わたしの実力では) ＞項目
こっちも試してみるかなあ
優勝しました。
うーむまけた
メールで書き込み主に教えてもらいました。 長年(おおげさ)の疑問がついにっ
くだすれFORTRAN（超初心者用）その5 [chaika] 818 デフォルトの名無しさん [sage] 2012/02/08(水) 19:16:27.77 ID: Be: FORTRANで整数変数の暗黙宣言がI～Nになっていることの根拠を知りたいと いう人がいた気がするが、まだ解決していないなら朕がその謎を解いてやろう。 John Backus 本人がそのものずばりを質疑で答えている。 ちなみに質問は会場の爆笑を誘っているｗ J.A.N. Lee. Transcript of question and answer session: "The History of Fortran I, II, and III". In in: R. Wexelblat, editor. History of Programming Languages, ACM Monograph Series, Academic Press, 1981, pages 68-71. http://www.softwarepreservation.org/projects/FORTRAN/paper/p68-lee.pdf LEE: Helen Gigley asks: "Why were the letters I through N chosen to designate integers?" [Laughter and applause] BACKUS: Well, it just seemed for a while that people always used I, J, and K for subscripts, and we thought we'd be generous and add a few more. ようするに適当ｗ まぁ数学では記法としてΣ_i^Nとかが一般的で、添え字にO以降は使われないから、 I～Nまでを整数とするのは適切な気がする。 819 デフォルトの名無しさん [sage] 2012/02/08(水) 19:19:26.81 ID: Be: ついでに言うと、伝説と異なりFORTRAN I で配列のRankが3以下に制限されたのは インデックス・レジスタが３個しかないせいではないとも言明している。
配列の次元の上限は以外だった。確かに示されているリンク先にあるPDFの中身をみると、 はじめ三次元、後に七次元になったことについてのコメントがあった。
いや実にすっきりしました。 ゆっくり眠れます :)
よーするにカーソル移動やらを「最適化」せいと
Vim anti-patterns | Arabesque Vim anti-patterns Posted on February 7, 2012 The benefits of getting to grips with Vim are immense in terms of editing speed and maintaining your “flow” when you're on a roll, whether writing code, poetry, or prose, but because the learning curve is so steep for a text editor, it's very easy to retain habits from your time learning the editor that stick with you well into mastery. Because Vim makes you so fast and fluent, it's especially hard to root these out because you might not even notice them, but it's worth it. Here I'll list some of the more common ones. Moving one line at a time If you have to move more than a couple of lines, moving one line at a time by holding down j or k is inefficient. There are many more ways to move vertically in Vim. I find that the two most useful are moving by paragraph and by screenful, but this depends on how far and how precisely you have to move. { — Move to start of previous paragraph or code block. } — Move to end of next paragraph or code block. Ctrl+F — Move forward one screenful. Ctrl+B — Move backward one screenful. (以下略)
本文はどうでもよくてですね
IT Software Community - John W. Verity - LISP Is Back, and It's Baaaaad! LISP Is Back, and It's Baaaaad! John W. Verity, Editor in Chief, 1/25/2012 Functional programming, as embodied in a new version of LISP, is finding growing use across the mainstream, enterprise landscape. In 1958, MIT computer scientist John McCarthy invented a new programming language called LISP, and it changed the world of computing. From that moment on, this "list processing language" has been the tool for exploring the frontiers of computer science, for writing programs that were thought to be impractical or even impossible. In the early 1980s, LISP had a brief moment in the commercial spotlight when artificial intelligence (AI) suddenly looked promising. Specialized computers were created just to run LISP programs. But AI failed to deliver on its promises, the long "AI winter" set in, and LISP slunk back to the research lab. But now, it appears, LISP is back, reappearing on the commercial, enterprise stage and making waves again. In particular, a new dialect called Clojure is tackling some of the most demanding programming tasks faced by companies in industry after industry. Startups and established enterprises alike are scrambling to hire from the growing ranks of Clojurists. User groups are forming everywhere from Hamburg to Silicon Valley and beyond. (略)
IT Software Community - John W. Verity - LISP Is Back, and It's Baaaaad! Re: Clojure resources @jan: I've worked on Ruby extensively and each time I use it, I'm really impressed by it's simplicity in design as well as ease of use. You have to give credit to the Japanese for it.Re: Clojure resources But the Japanese could not have done it without some work by crafty Americans!
このコメント二つのやり取りがなぜかツボにはいった。
Python プログラマーなんですが Ruby を始めたいのですけどなにかよい資料などは
I am a python programmer who needs to learn ruby. Any good resources or advice? : ruby The languages are often compared so I am hoping my knowledge of python will make learning ruby faster. Maybe the best method is just to read a ruby book and learn from scratch, I am not sure yet how similar they are. However if anyone has made the switch and knows what a good starting point would be or if there are resrouces geared toward switching I would apperciate the advice. Thanks. Edit: I will be using ruby as a scripting language. Mosly maintaing and updating existing scripts that put together XML files used for input for other applications and things like file management and such. So if there are resrouces geared towards scripting rather than building ruby applications that would be helpful.Ruby KoansI can't say enough nice things about the koans approach. It's a really great way to learn all the gotchas in a language. It shows you how things are done in a idiomatic way. And it's fun.Here's a comparison of the languages, from a great Python programmer: http://groups.google.com/group/comp.lang.python/msg/28422d707512283?pli=1 Also, here's the learn ruby from other languages page: http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/Thanks!
Byteman allows you to insert extra Java code into your application, either as it is loaded during JVM startup or even after it has already started running.
しかし実は、Rubyのfor式はたんなる構文糖よりも少し罪が重い。
O'Reilly Media - Tech Books, DRM-Free Ebooks, Videos なんか2冊買うと1冊無料でついてくるって話らしいんですが、 欲しいなあってのが Upcoming - O'Reilly Media の辺りにしかなかったりして。 ラクダ本マダー?
Upcoming - O'Reilly Media Programming Perl, 4th Edition By Tom Christiansen, brian d foy, Larry Wall, Jon Orwant February 2012 (est.) Ebook: $39.99 Pre-Order Print: $49.99
↓この辺も早く
Upcoming - O'Reilly Media Code Simplicity By Max Kanat-Alexander February 2012 (est.) Pre-Order Print: $24.99
Upcoming - O'Reilly Media Think Complexity By Allen B. Downey March 2012 (est.) Pre-Order Print: $29.99
おや、こんなのが。 Free as in Freedom [Paperback] - O'Reilly Media 確か自分が持っているのはハードカバーだったような (ろくに読んでなかったりする :)。
前後のページとの関連がよくわからない(^^:
Razzle Dazzle | 1: Origin Story | The History of Rubinius The History of Rubinius As Told by Its Creator by Evan Phoenix During the winter of 2006, I got interested in the implementation of the Smalltalk language. Following discussion with Ryan Davis about Ruby and Smalltalk, I decided to order the Blue Book from Powell's Books online. The Blue Book is the holy bible of Smalltalk, containing not only a complete introduction to the language, but also a sample implementation of the language itself in the last few chapters. The intention of these chapters was to provide the interested reader some details into how Smalltalk works at the lowest level, so they could use the language well. To my eyes though, it was like opening the face of a watch to see the gears turning. It was amazing, and proved to be the initial spark of life for Rubinius. (以下略)
幸いまだこの辺で苦しんだことはない。たぶｎ
getaddrinfo() edge case behavior on Windows, Linux and OS X – klickverbot.at by David Nadlinger getaddrinfo() edge case behavior on Windows, Linux and OS X (略) Host Port Flags Windows Linux OS X null null - NONAME NONAME NONAME AI_PASSIVE NONAME NONAME NONAME "" - loopback loopback NONAME AI_PASSIVE catchall catchall NONAME "0" - loopback loopback loopback AI_PASSIVE catchall catchall catchall "80" - loopback loopback loopback AI_PASSIVE catchall catchall catchall "" null - public NONAME NONAME AI_PASSIVE public NONAME NONAME "" - public NONAME NONAME AI_PASSIVE public NONAME NONAME "0" - public NONAME loopback AI_PASSIVE public NONAME catchall "80" - public NONAME loopback AI_PASSIVE public NONAME catchall "localhost" null - loopback loopback (v4) loopback AI_PASSIVE loopback loopback (v4) loopback "" - loopback loopback (v4) loopback AI_PASSIVE loopback loopback (v4) loopback "0" - loopback loopback (v4) loopback AI_PASSIVE loopback loopback (v4) loopback "80" - loopback loopback (v4) loopback AI_PASSIVE loopback loopback (v4) loopback hostname null - public loopback (v4) public AI_PASSIVE public loopback (v4) public "" - public loopback (v4) public AI_PASSIVE public loopback (v4) public "0" - public loopback (v4) public AI_PASSIVE public loopback (v4) public "80" - public loopback (v4) public AI_PASSIVE public loopback (v4) public getaddrinfo() behavior on Windows Server 2008 R2, Arch Linux (Kernel 3.1.4, glibc 2.14.1), and OS X 10.7.2 (Lion).
reddit で500overの反応があった記事
Dear Boss: For a programmer, 10 minutes = 3 hours - edw519 Dear Boss: For a programmer, 10 minutes = 3 hours 10:48 Boss: Hey Ed, Sue in Detroit says that sometimes, the wrong Invoice Part Number is showing up on the Product History Screen. Can you help us figure this out. Ed: I'm busy with something else at the moment. Put the ticket in my queue. Boss: This will only take 10 minutes. Ed: Are you sure about that? Boss: Yes. I'll just set up a web conference. Sue can show you right away, then you can look into it when you have time. Ed: OK. Boss: Great. Check your Outlook for an invite. (略) 1:48 Boss: OK, this sounds like a problem. It looks like I'll have to escalate this to the Steering Committee. I'm glad you had 10 minutes to spare. Thanks. (Ed continues to read Hacker News in another tab.)
ちゃんちゃん。 詳しい顛末は元記事をどうぞ
Dear Boss: For a programmer, 10 minutes = 3 hours : programming Crucially, when the boss first says "This will only take 10 minutes", he means 10 minutes of his time, not yours"This is just a simple feature to add in; we're only changing 3 fields. Shouldn't take more than 30 minutes." ... and running items on a 3rd party database with no API provided, changing the data that is being sent, and turning that into 3 service calls instead of 1, to "speed things up a bit". 2 hours later: "Why isn't this done yet?! Don't bill for more than 30 minutes; I already told the client that's how long it would take."My running joke at work when someone asks how long it would take to get a minor change done. 1 minute to make the change 1 hour to test 1 day to get it into QC 1 week to get someone to sign off on UAT 1 month to get someone to sign off on PROD An exaggeration that isn't too far off from reality.
こういうのは全文きっちりやったのほうが良いのかな
ShipSolid - Software ConsultingYou Need a Code Review (あなたにはコードレビューが必要だ) Alex Bartlow 2012-02-05 On many of my projects, I have the pleasure of working with a team of highly skilled developers and designers to deliver a working, finished application. Many of these developers are shocked when I often ask for code reviews, or use a pull-request on github to deliver a feature, instead of just pushing it into master. It seems that I'm regarded as a senior developer, that should be above such formalities that prevent junior developers from making a build-breaking change, and as such, I should resent the idea of someone else auditing my changes. I don't resent it. I need it. I need a code review, on every significant commit.
Simula - Wikipedia INTRODUCTION TO SIMULA Cim for Windows An Introduction to Programming in Simula
なんか動く処理系があるっぽいのでやってみようかという気になりつつある
Twitter / @y_shindoh: grep vs. Awk: http://t.co/ ... Hena Hena Nikki ～悔い倒れの日々～(2012-02-08)
Twitter / @y_shindoh: grep vs. Awk: http://t.co/ ... grep vs. Awk: quruli.ivory.ne.jp/diary/?date=20… 「GNU grepよりGNU Awkの方が速い!」 という噂を聞いて試してみた。 ちなみに、この結果と正反対の結果が手元のGnuWin32環境では出 たので、環境によってかなり違うと見た方が良さそうだ。
バージョンによって正規表現ライブラリが入れ替わったり(grep)、 インタープリターがバイトコード形式になったり(gawk)で その辺の条件を明確にしないと同じ比較ができないような。
Clang: Defending C++ from Murphy's Million Monkeys | GoingNative 2012 | Channel 9 Clang: Defending C++ from Murphy's Million Monkeys : programming Murphy's とあるのは何か深い意味があるんだろうか それはともかく、音声のみのダウンロードもできるっぽいのでそれを聴いてみよう。 初日のキーノートやらも含めると聴くための時間がとんでもなくかかるけど。
Clang: Defending C++ from Murphy's Million Monkeys | GoingNative 2012 | Channel 9 Were we to craft a Lenox Globe of programming languages, C++ might be followed by a famous cautionary phrase: Here Be Dragons. The language can be complex and daunting to programmers who are often shouldered with the task of writing large, complex programs. Those millions of code monkeys need help to resist Murphy's siren song and navigate C++'s treacherous waters of memory corruption and concurrency bugs. (略)
code monkey と Murphy's siren song やらからでてきたのかな＞百万匹の猿
初日のキーノート。 Day 1 Keynote - Bjarne Stroustrup: C++11 Style | GoingNative 2012 | Channel 9
Day 1 Keynote - Bjarne Stroustrup: C++11 Style | GoingNative 2012 | Channel 9 We know how to write bad code: litter our programs with casts, macros, pointers, naked new and deletes, and complicated control structures. Alternatively (or additionally), we could obscure every design decision in a mess of deeply nested abstractions using the latest object-oriented programming and generic programming tricks. Then, for good measure, we might complicate our algorithms with interesting special cases. Such code is incomprehensible, unmaintainable, usually inefficient, and not uncommon. わたしたちはひどいコード (bad code) の書き方を知っています。 自分たちのプログラムを、キャストやマクロ、ポインター、素の new や delete、それに 複雑な制御構造であふれさせること。です。
昨年大晦日に手に入れられなかったアイツが委託されたので COMIC ZIN 通信販売/商品詳細 インフラエンジニア双六 買ってきました。 いけね。証拠写真撮ってないw
PowerShell でリストスライスを取り出そうと $ary[5..-1] として予想外の動作をしてびびる。
Ruby、Python もこれとそれぞれ違って混乱したり。 どれがいい、他はだめということではないのだけど悩みの種ではある (複数使うほうが悪い?)
PS > $ary="a b cd e f g".split(" ")
PS > $ary
a
b
c
d
e
f
g
PS > $ary[0..7]
a
b
c
d
e
f
g
PS > $ary[4..7]
e
f
g
PS > $ary[-4..-1]
d
e
f
g
PS > $ary[4..-1]
e
d
c
b
a
g
減少方向もいけるのね。
PS > 4..-1 4 3 2 1 0 -1 PS > -4..-1 -4 -3 -2 -1
一般化されすぎということ? ＞ Overgeneralization
Erik McClure: "Programmer" is an Overgeneralization February 5, 2012 "Programmer" is an Overgeneralization "Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth Earlier today, I came across a post during a google-fu session that claimed that no one should use the C++ standard library function make_heap, because almost nobody uses it correctly. I immediately started mentally ranting about how utterly ridiculous this claim is, because anyone whose gone to a basic algorithm class would know how to properly use make_heap. Then I started thinking about all the programmers who don't know what a heap is, and furthermore probably don't even need to know. 今日わたしは、それを正しく使える人がほとんどいないのだから C++ の標準ライブラリ 関数にある make_heap は誰も使うべきではないという主張を google-fu session の間に post しました。 basic algorithm class を理解しているような人であれば make_heap の適切な使い方を 知っているでしょうから、わたしは即座にこの主張がまったくばかげているものであることを mentally ranting しました。 それからわたしは、ヒープがなんであるかも知らず、 それが何のためにあるのかすらも知らないであろう プログラマーすべてについて考えはじめました。 Then I realized that both of these groups are still called programmers. そうして、プログラマーにはそういった二つのグループがあるのだということを認識するにいたりました。Copyright ©2011 Erik McClure. Powered by Blogger.
Four Levels of Idea Theft Four Levels of Idea Theft アイデアの剽窃の4レベル Imagine you've just seen a tremendously exciting piece of software--a mobile app, a web app, a game--and your immediate reaction is "Why didn't I think of that?!" With your mind full of new possibilities, you start on a project, a project enabled by exposure to the exciting software. What happens next is up to you. How far do you let your newfound motivation take you?Borrowing specific features. General inspiration. Using the existing product as a template. Wholesale borrowing of the design.
Amazon さんから Kindle touch 買わない? と販促メールが
続編。 code examples ということでそういう話でした。
Why I love Common Lisp and hate Java, part II – code examples « Piece of mine Why I love Common Lisp and hate Java, part II – code examples Writing programs that write programs.This is a sequel to my previous post where I urged those who gave up on programming — probably because of the spoon-fed association with Java and stress — to give coding another chance with a whole “new” (read: different) approach: Common Lisp. The purpose of this sequel is to address the open-minded skeptic, unconvinced yet unafraid of paradigm-shifting change. Common Lisp is not just another language, it is a different way of coding. While I tried to make a point that the REPL completely alters the experience of coding — which can only be experienced and not by reading a blog post — this time I will try to showcase Common Lisp's powerful meta-programming through some example code. Writing programs to write programs is mind-boggling if you come from the imperative world of Java. Simply because it is not possible in Java, therefore not taught, hence not even considered as a powerful way of abstraction and code reduction. We write methods and functions to abstract away reoccurring computational patterns. Why not write functions that take the abstraction level even higher and abstract away coding patterns? (以下略)
NSApplication プログラムの作成 XO: 再：CarbonかCocoaか？
Cocoa での hello, world 的プログラムってどんなんだろうと疑問に思いつつちと調べた。 Windows、昔の Mac OS のように自分でディスパッチするのではないのね。 X のメッセージはどう処理してたっけ?
職業プログラマに山形浩生みたいな完膚なきまでの英語理解は不要ですのでその点はご安心いただきたいですけれども、かといってあなたがもし何を学んでよいか分からないほど五里霧中なのであれば、まず必要なのは知識そのものではなくて知識を得るためのツール、つまり言語ですよ。
仕込みの時間が欲しい…
Rの特色だが、C言語やJavaの静的スコープと異なり、Perlのような辞書的スコープが用いられる。
そもそも「たのしさ」というのは指標たりうるのだろうか。
を丸投げ。 洒落になっとらんな。
javaでの金額の丸めについて（至急、お願いします | OKWave javaでの金額の丸めについて（至急、お願いします 調べ方が足りていないのかもしれませんが、 わかりませんでした。教えていただけないでしょうか。 金額の丸め処理をしたいのですが、どのように書けばいいのかわかりません。 金額は、もちろんマイナス表記もあります。 100円単位の切捨て、切上げ、四捨五入 1000円単位の切捨て、切上げ、四捨五入 少数以下の処理は、いろいろとサンプルがあったのですが・・・・ どなたかご教授願います。ANo.2 class Q7283233 { public static void main(String[] args) { int c = 100; int n = 113; System.out.println((int)Math.floor((double)n / c) * c); System.out.println(Math.round((double)n / c) * c); System.out.println((int)Math.ceil((double)n / c) * c); n = 355; System.out.println((int)Math.floor((double)n / c) * c); System.out.println(Math.round((double)n / c) * c); System.out.println((int)Math.ceil((double)n / c) * c); n = -113; System.out.println((int)-Math.floor((double)-n / c) * c); System.out.println(-Math.round((double)-n / c) * c); System.out.println((int)-Math.ceil((double)-n / c) * c); n = -355; System.out.println((int)-Math.floor((double)-n / c) * c); System.out.println(-Math.round((double)-n / c) * c); System.out.println((int)-Math.ceil((double)-n / c) * c); } }ANo.1 100円単位なら、元の金額を100.0で割ってから切り捨て・切り上げ・四捨五入の操作を行い、その結果を100.0倍する。
この回答者さんたちはわかってて質問者をからかっているのかそれとも(ry
大英帝国海軍の戦艦あたりの命名規則はなかなか理解しがたいものが (彼らにしてみれば、日本海軍の駆逐艦なんかはなんじゃそらだろうなあ)
ジャック・キャンベル ～彷徨える艦隊～ 2番艦c 623 名無しは無慈悲な夜の女王 [sage] 2012/01/09(月) 02:28:08.28 ID: Be: ７巻表紙の女性は誰？ デシャーニ大佐だよね？ 副題がドレッドノートだからジェーン・ギアリー大佐？ 624 名無しは無慈悲な夜の女王 [sage] 2012/01/11(水) 13:22:58.35 ID: Be: ドーントレス以外だと作中の活躍とリンクしてない名前だよね ヴィクトリアスってなんかやったっけ 625 名無しは無慈悲な夜の女王 [] 2012/01/12(木) 15:39:15.58 ID: Be: 日尼見ると、8巻のハードカバーとペーパーバックが同じ月に出ることになってるがおかしいな。 翻訳の質はともかく、刊行中のシリーズに追いつきピッタリマークしてるなんてなかなかないな。 626 名無しは無慈悲な夜の女王 [sage] 2012/01/12(木) 19:23:27.12 ID: Be: >>624 戦艦の名前じゃなくてただの形容詞 627 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 01:36:41.43 ID: Be: >>626 何が形容詞だって？ 彷徨える艦隊 旗艦ドーントレス 彷徨える艦隊 ２ 特務戦隊フュリアス 彷徨える艦隊 ３ 巡航戦艦カレイジャス 彷徨える艦隊 ４ 巡航戦艦ヴァリアント 彷徨える艦隊 ５ 戦艦リレントレス 彷徨える艦隊 ６ 巡航戦艦ヴィクトリアス 彷徨える艦隊 ７ 戦艦ドレッドノート 628 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 01:59:52.75 ID: Be: 帰還によって初期の目標を達成し勝利を得たではないか。 艦名とその意味を掛けてるんじゃない？と思うのだが。 1.Dauntless 不屈の 2.Furious 怒り狂った 3.Courageous 勇敢な 4.Valiant 雄々しい 5.Relentless 冷酷な 6.Victorious 勝利を得た 7.Dreadnought 恐れ知らず 629 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 03:26:47.16 ID: Be: >>628 いや、そうじゃなくて >>626 は、 >戦艦の名前じゃなくてただの形容詞 と言った 630 626 [sage] 2012/01/13(金) 04:16:59.38 ID: Be: 形容詞だろ 戦艦の名前とかけてるけどそれ自体はただの形容詞だろ 631 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 06:18:27.32 ID: Be: >>627 原書のサブタイには「旗艦」だの「特務戦隊」だの「戦艦」だのといった単語は付いてません 日本語版のタイトル付けた奴のチョンボ 632 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 08:35:51.55 ID: Be: 「戦艦の名前とかけてる」のはみな理解してる。 >>624 がいってるのは、 「ドーントレス以外だと作中の活躍とリンクしてない」 活躍じゃないけど撃沈されたのはあったと思う。 635 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 22:33:50.60 ID: Be: まぁ軍艦の名前ってのは最重要な要素だと思うが、 本の内容と関わってるのはその意味の方だ罠 原書は読んだことないので俺には分からんけど、艦名の冠にH.M.Sみたいなのが付いてたら 副題はもう純粋に形容詞だがｗ 636 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 22:37:30.20 ID: Be: 書き込んでから気付いたが、theが付いてないから形容詞の方が主か 637 名無しは無慈悲な夜の女王 [sage] 2012/01/14(土) 00:42:41.95 ID: Be: >>628 故郷への生還で始まり凱旋で終わる第６巻に「Victorious」とつけるあたり、 作中での艦の活躍よりは「形容詞」重視っぽいね。 638 名無しは無慈悲な夜の女王 [] 2012/01/14(土) 05:37:30.61 ID: Be: 普通にストーリー上のタイトルロールの艦と形容詞的用法上のダブルミーニングを狙ってるんだろ。 タイトルロールの艦の活躍がちょびっとorほぼ見当たらない巻もあるし、 それほど各巻ごとに大きな変化があるストーリーでもないけど。 さて、これから巻名になりそうな艦名を拾ってみると Vengeance 復讐 Vanguard 前衛 Revenge 復讐 Triumph 勝利 次点で Majestic 堂々とした Brilliant 光り輝く こりゃなんじゃ？ Intemperate 不摂生な 642 名無しは無慈悲な夜の女王 [] 2012/01/14(土) 13:29:57.81 ID: Be: >638 やり過ぎ、の方が良いかも。 呑んだくれって意味の方も捨てがたいがｗ 異星人の脅威が明らかになると Redoubtable 恐るべき とか 最終巻は Glorious 栄光ある だろうなぁ 781 名無しは無慈悲な夜の女王 [] 2012/02/01(水) 13:11:25.95 ID: Be: ついでに 艦隊が与えた損害をギアリーが見積もらなければならないが、今の時点では大虐殺としかいいようがない。 now he had to figure out how much damage they had done. All he could tell at the moment was that the damage hadn't been the massacre it might have been. 翻訳の無免許運転としか言いようがない。 782 名無しは無慈悲な夜の女王 [] 2012/02/01(水) 13:44:58.81 ID: Be: 逆だね。 789 772 [sage] 2012/02/01(水) 17:02:38.63 ID: Be: >>781 そこも「？」と思ったところだった。 大した損害がないのに“大虐殺”とはこれ如何にと・・・ >>778兄，>>779兄のおかげでスッキリしたよ。 790 777 [sage] 2012/02/01(水) 20:36:13.73 ID: Be: やっぱり誤訳かよ！ チェック体制とかどうなってんだ……返金ものだろ…… 791 名無しは無慈悲な夜の女王 [] 2012/02/01(水) 20:54:33.96 ID: Be: 景気悪い ->出版社: 経費節減 ->翻訳のチェック無し(翻訳者まかせ) 翻訳料も下げ ->翻訳者: 見直し最低限(細かいことやっとれん、出版社でやれよ) 下訳料金も下げ(or 翻訳ソフトでもいいか) ->下訳者: 雑でもいいな(金に見合うし)、 ついでに間違いも入れといたろ まさか、こんなじゃないだろうな...
Sorting algorithms used in the CL implementations « Jorge Tavares weblog Sorting algorithms used in the CL implementations (略) What sorting algorithms do the major open source CL implementations actually implement? I was curious about it and went to check the source for ABCL, CCL, CLISP, CMUCL, ECL and SBCL. Not surprising, we find some differences between the implementations. What it was more unexpected to discover is that some implementations also use different sorting algorithms according to the sequence type. A quick survey of the findings is summarized in the following table (if anythings is incorrect, please tell me). The links for the source code are in the implementation name (careful, in CCL and SBCL there are two links). Implementation sort stable-sort ABCL merge sort (lists) / quicksort merge sort CCL merge sort (lists) / quicksort merge sort CLISP tree sort tree sort CMUCL heapsort merge sort ECL merge sort (lists) / quicksort quicksort (strings + bit vectors) / merge sort SBCL merge sort (lists) / heapsort merge sort In terms of the implementation of sort, quicksort is the most used algorithm, followed by heapsort. The choice for these algorithms is expected. Both have an average-case performance of O(nlgn) and heapsort guarantees a worst-case performace of O(nlgn) too. Quicksort has a worst-case performance of O(n2) but it can be optimized in several ways so that it also gives an expected worst-case performance of O(nlgn). However, it seems that the quicksort implementations are not completely optimized. In ECL (and ABCL) quicksort implements a partition scheme which deals better with duplicate elements (although is not the three-way partitioning) but it always picks as pivot the first element. CCL chooses the pivot with a median-of-3 method and always sorts the smaller partition to ensure a worst-case stack depth of O(lgn). (略)
使われている度合いではクイックソートが一番というのはともかく、 続いてヒープソートってのは意外な気が。
わたなべさんのところから辿った元記事。
Re: テキストファイルをソートするときに頻繁に使うUnixコマンド - jarp,
→
[O] テキストファイルをソートするときに頻繁に使うUnixコマンド
で、
sort するときは LC_ALL=C sort を使わないと、環境によって結果が変わってしまう場合があるし、一定量以上のファイルをsortする際には、sort処理自体の速度もLC_ALL=Cありの方が速いです。
locale が C でない場合に処理速度ががた落ちになってしまうというのはおいといて
(ありゃあ実装が以下略なところもあるような気がしないでもない。
といってきちんとしたコードを書くのも大変だろうなあ)、
sort するのに collating order 無視というのはどうなんだろうねえ。
まあ、基本的に文字コード順で不自由ないんだろうけど。
LC_ALL. LANG, LC_COLLATE その他の役割(とか影響範囲)ってあまり理解されてない? いやまあメッセージ出力のエンコーディングがどうこうはわかってるんだろうけど。
紀伊国屋書店新宿南店の洋書売り場も模様替えやらなんやらでCSの棚がだいぶ寂しく…
codermetrics
洋書のスペースがさらに狭くなったジュンク堂で発見。
去年の8月に出ているもの
(Codermetrics - O'Reilly Media) だったのか。
今までぜんぜんアンテナに引っかかってこなかったw
家に帰って確かめるまで、ずっと「codemetrics」と思い込んでました。
こんなサイトも → Codermetrics.org
んで、裏表紙にはこういう一文が
Codermetrics is the Moneyball for software teams. Who would have thought that
sports and software development had so much in common?
The book is purposeful and thought-provoking -- a great read for any software team participant.
容量が4GBってのだけでもいいなあ Kindle Touch WiFi モデルが日本からも購入可能に、139ドル -- Engadget Japanese
これは自分も疑問に思ったことがあるんですが、なんでなんでしょうね。
スレ立てるまでもない質問はここで 116匹目 868 デフォルトの名無しさん [sage] 2012/02/04(土) 09:01:26.61 ID: Be: 何で日本はチャートの事をグラフって教えるんだろうか。 869 デフォルトの名無しさん [sage] 2012/02/04(土) 09:02:46.27 ID: Be: 図のことをフィギュアとは言わないなあ。 870 デフォルトの名無しさん [sage] 2012/02/04(土) 09:41:08.80 ID: Be: マならチャートとフィギュアを使うのは当然だよな。 グラフなんて言ったら紛らわしいし。
C言語での桁落ちの以下のプログラムを教えてください | OKWave C言語での桁落ちの以下のプログラムを教えてください C言語の本の問題で答えが書いてなく困っております。 f(x)=xの5乗-ルート（1+xの10乗)+1/{2×ルート（1+xの１０乗）}の式が与えられ ｘ＝0,1,2・・・50 における f(x) の値を求める場合のプログラムを教えてください。 注＊＊そのまま計算した場合と式を変形して正確に計算した場合を比較せよ（一つのプログラムで両方計算）．何が分からないと?補足 C言語での桁落ち：：： f(x)=xの5乗-ルート（1+xの10乗)+1/{2×ルート（1+xの１０乗）}の式 が与えられていてｘ＝0,1,2・・・50 における f(x)のプログラムです。
丸投げっぷりは脇に置いといて、R は↓こーゆーことができるので好き :)
> fx <- function(x){x**5 - sqrt(1+x**10) + 1/(2*sqrt(1+x**10))}
> fx(1:50)
[1] -6.066017e-02 -3.810975e-06 -8.711305e-09 -1.164152e-10 -4.150059e-12 -4.044512e-13 -7.689121e-13
[8] -7.105427e-15 2.710343e-12 5.583029e-12 1.370892e-11 1.197672e-12 1.113648e-11 -2.059970e-11
[15] -8.846262e-12 -2.168404e-19 1.082057e-10 1.151358e-10 -1.664620e-10 -2.121925e-10 -4.295505e-11
[22] 1.614090e-10 3.840912e-10 3.947581e-10 9.085810e-10 -7.581706e-10 -5.443981e-10 -7.500674e-10
[29] -1.700046e-09 -1.775610e-09 -1.161735e-09 -6.617445e-24 -2.125002e-09 3.554049e-09 2.069262e-09
[36] 8.185052e-10 7.210434e-09 6.310329e-09 5.541751e-09 4.882813e-09 4.315695e-09 3.825811e-09
[43] 3.401165e-09 3.031842e-09 2.709614e-09 2.427621e-09 2.180122e-09 1.962293e-09 1.770067e-09
[50] 1.600000e-09
> gx <- function(x){1/(2*sqrt(1+x**10))-sqrt(1+x**10)+x**5}
> gx(1:50)
[1] -6.066017e-02 -3.810975e-06 -8.711311e-09 -1.164153e-10 -4.092726e-12 0.000000e+00 0.000000e+00
[8] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
[15] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
[22] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
[29] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
[36] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
[43] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
[50] 0.000000e+00
> (function(x){1/(2*sqrt(1+x**10)) - sqrt(1+x**10) + x**5})(1:20)
[1] -6.066017e-02 -3.810975e-06 -8.711311e-09 -1.164153e-10 -4.092726e-12 0.000000e+00 0.000000e+00
[8] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
[15] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
式を変形して正確な値を求めるというのはこういうことですよね。 三つ目のはお遊び :)
その話題の元
10x Productivity Myths: Where's the 10x Difference in Compensation? - 10x Software Development 10x Productivity Myths: Where's the 10x Difference in Compensation? In response to my recent blog post on the research support for 10x productivity differences among programmers, Pete McBreen made the following comment: "One point in his article that McConnell did not address--programmer compensation does not vary accordingly. This is a telling point--if the difference is productivity can be 10X, why is it that salaries rarely fall outside the 2X range for experienced developers?" [emphasis in original] This is a good question. It's timely because the Software Engineering Productivity group on LinkedIn has recently had a 130-comment discussion on the question of “Should pay be tied directly to productivity?” It's also a question that I wrestled with personally for about the first 10 years of my career. Indeed, it's part of the original reason I decided to became self employed back in 1989 and eventually founded my own company in 1996. The Intuitive Version of the Question I started my personal “10x compensation quest” from the point of view of, “I know I'm 3-5x as productive as the guy sitting next to me. Why am I not making 3-5x as much money?” Over a period of many years I found that this formulation of the question embodied several assumptions that were naïve or just plain wrong from a business perspective. Six Myths of 10x Compensation Let's look at each of these myths of 10x compensation. Myth 1. The guy next to me is getting paid what he's worth. 略 Published Jan 22 2011, 05:42 PM by Steve McConnell
t1: Expressing integers using four nines :: Strangely Consistent 3 Feb, 2012 by Moritz Lenz t1: Expressing integers using four nines (This is a guest post by Moritz Lenz. If you're wondering what this is all about, it's the aftermath of The 2011 Perl 6 Coding Contest. If you're not wondering, it's still about that.) Let's consider the first task from the Perl 6 Coding Contest 2011. Here is the description of the task once more: What non-negative integers can you write as expressions containing exactly four occurrences the number 9, and any of the binary operators *, /, %, +, -, prefix negations, and any number of matching pairs of parentheses you care to use? 9 が四つと二項演算子 *, /, %, +, -、前置の negation、任意個のカッコ対を使った 式として記述できる非負の整数 #よくわからん The program should accept an upper limit N as a command-line argument. It should then print all integers 0..N in increasing order, along with an expression with four nines, if any such was found. この問題はコマンドライン引数として上限値 N を受理すべきである。 0 から N までのすべての4つの9で表現できる整数を昇順に出力する。 #でいいのかな It was probably the easiest of all tasks, and the one we got the most submissions for. Yet there were still some things that could go wrong, and some submissions got some of them wrong: non-negative implies that we start at 0 = 9 + 9 - 9 - 9, not at 1 1 からではなく 0 から開始 integers means that the result must be an integer; it does not mean that intermediate results are automatically rounded or truncated 結果は整数でなければならない。中間結果は自動的に丸められたり切りめられたりしない the expressions must consist of four times the number 9, not the digit nine. Thus 99 is not a valid expression of two nines. 式では数字の 9 ではなく、数値の9 を4つ含んだものでなければならない。 したがって 99 は二つの9を使った vaild な式ではない 略
BeautifulSoup for Python 3!
どうやら毎週のように週末このトルタコスというお店でプログラミング談義が行われているらしい。
パターンマッチは時々欲しくなるのでRuby 3.0あたりで言語仕様に取り込まれないかなぁと思うんだけど、あまりパターンマッチについて議論されているところを見た記憶がない。
しかし池袋のジュンク堂、CS関連の洋書の棚をあそこまで削るとは… ○|￣|＿ 紀伊國屋書店も以前よりは面積減ってるしなあ。 どうすべえ。
カッコの対応をリアルタイムに強調表示やらしてくれるエディターってどれが最初?
例によって日本語版と英語版とでだいぶ違う
評価戦略 - Wikipedia 値渡し 値渡し（Call-by-Value）評価は、C言語からSchemeまで多くの言語で採用されている典型的な評 価戦略である。値渡しでは、引数の式を評価し、結果として得られた値で関数内の対応する変数 を束縛する（通常、捕獲回避置換か新たなメモリ領域への値のコピーをする）。その関数が引数 となっている変数に値を代入しても、それは局所的なコピーへの代入であり、呼び出した側から 見れば、その関数に渡したものは何も変化していない。 値渡しは一種類ではなく、関数に渡す前に引数を評価する戦略全般を指す。多くの言語（Eiffel や Java）は値渡しの際に引数と左から右の順序で評価するが、中には右から左の順序で評価す る場合もあり、言語によっては（Scheme、OCaml、C）順序を明示していない。
評価戦略 - Wikipedia 参照渡し 参照渡し（Call-by-Reference）評価とは、関数に対して引数の値そのものではなく、引数の参 照を暗黙のうちに渡すことをいう。その関数が引数を変更すると、呼び出し側からもその変化が 観測できる。引数の式が左辺値であれば、そのアドレスが使われる。そうでない場合、呼び出し 側で一時的オブジェクトを構築し、そのオブジェクトへの参照が渡される。そのオブジェクトは 関数から復帰した際に捨てられる。 言語によっては、参照を第一級オブジェクトとしている。例えば、MLには "ref" コ ンストラクタがある。C++でも参照は明示的に生成できる。これらの言語では、関数の引数とし て値への参照を渡すことを参照渡しと呼ぶこともある。 C言語のようにポインタを持つ言語では、参照渡しではなく「アドレス渡し（Call-by-Address）」 と呼ぶこともある。
最後の一文、Cに call by reference があると読めるような気がしないでもないんですが。
こっちが英語版。 訳はいいっすよね?w
Evaluation strategy - Wikipedia, the free encyclopedia Call by value Call-by-value evaluation (also referred to as pass-by-value) is the most common evaluation strategy, used in languages as different as C and Scheme. In call-by-value, the argument expression is evaluated, and the resulting value is bound to the corresponding variable in the function (frequently by copying the value into a new memory region). If the function or procedure is able to assign values to its parameters, only its local copy is assigned — that is, anything passed into a function call is unchanged in the caller's scope when the function returns. Call-by-value is not a single evaluation strategy, but rather the family of evaluation strategies in which a function's argument is evaluated before being passed to the function. While many programming languages (such as Eiffel and Java) that use call-by-value evaluate function arguments left-to-right, some evaluate functions and their arguments right-to-left, and others (such as Scheme, OCaml and C) leave the order unspecified (though they generally require implementations to be consistent). In some cases, the term "call-by-value" is problematic, as the value which is passed is not the value of the variable as understood by the ordinary meaning of value, but an implementation-specific reference to the value. The description "call-by-value where the value is a reference" is common (but should not be understood as being call-by-reference); another term is call-by-sharing. Thus the behaviour of call-by-value Java or Visual Basic and call-by-value C or Pascal are significantly different: in C or Pascal, calling a function with a large structure as an argument will cause the entire structure to be copied, potentially causing serious performance degradation, and mutations to the structure are invisible to the caller. However, in Java or Visual Basic only the reference to the structure is copied, which is fast, and mutations to the structure are visible to the caller.
最後のパラグラフによく議論になるアレに関係することが書かれてますね
Evaluation strategy - Wikipedia, the free encyclopedia Call by reference In call-by-reference evaluation (also referred to as pass-by-reference), a function receives an implicit reference to a variable used as argument, rather than a copy of its value. This typically means that the function can modify (i.e. assign to) the variable used as argument- something that will be seen by its caller. Call-by-reference therefore has the advantage of greater time- and space-efficiency when the argument is a large datatype (since arguments do not need to be copied), as well as the potential for greater communication between a function and its caller (since the function can return information using its by-reference arguments), but the disadvantage that a function must often take special steps to "protect" values it wishes to pass to other functions. Many languages support call-by-reference in some form or another, but comparatively few use it as a default; Perl and Visual Basic are two that do, though Visual Basic also offers a special syntax for call-by-value parameters. A few languages, such as C++, PHP, and REALbasic, default to call-by-value, but offer special syntax for call-by-reference parameters. C++ additionally offers call-by-reference-to-const. In purely functional languages there is typically no semantic difference between the two strategies (since their data structures are immutable, so there is no possibility for a function to modify any of its arguments), so they are typically described as call-by-value even though implementations frequently use call-by-reference internally for the efficiency benefits. Even among languages that don't exactly support call-by-reference, many, including C and ML, support explicit references (objects that refer to other objects), such as pointers (objects representing the memory addresses of other objects), and these can be used to effect or simulate call-by-reference (but with the complication that a function's caller must explicitly generate the reference to supply as an argument).
そして日本語版にはないこれ。
Evaluation strategy - Wikipedia, the free encyclopedia Call by sharing Also known as "call by object" or "call by object-sharing" is an evaluation strategy first named by Barbara Liskov et al. for the language CLU in 1974.[1] It is used by languages such as Python,[2] Iota, Java (for object references),[3] Ruby, Scheme, OCaml, AppleScript, and many other languages. However, the term "call by sharing" is not in common use; the terminology is inconsistent across different sources. For example, in the Java community, they say that Java is pass-by-value, whereas in the Ruby community, they say that Ruby is pass-by-reference[citation needed], even though the two languages exhibit the same semantics. Call-by-sharing implies that values in the language are based on objects rather than primitive types. The semantics of call-by-sharing differ from call-by-reference in that assignments to function arguments within the function aren't visible to the caller (unlike by-reference semantics)[citation needed], so e.g. if a variable was passed, it is not possible to simulate an assignment on that variable in the caller's scope. However since the function has access to the same object as the caller (no copy is made), mutations to those objects, if the objects are mutable, within the function are visible to the caller, which may appear to differ from call-by-value semantics. For immutable objects, there is no real difference between call-by-sharing and call-by-value, except for the object identity. Although this term has widespread usage in the Python community, identical semantics in other languages such as Java and Visual Basic are often described as call-by-value, where the value is implied to be a reference to the object.
こいつくらいは訳つけといたほうが良いのかしらん。
ついでに。 これも英語版だと(ry
Evaluation strategy - Wikipedia, the free encyclopedia Call by name In call-by-name evaluation, the arguments to a function are not evaluated before the function is called — rather, they are substituted directly into the function body (using capture-avoiding substitution) and then left to be evaluated whenever they appear in the function. If an argument is not used in the function body, the argument is neverevaluated; if it is used several times, it is re-evaluated each time it appears. (See Jensen's Device.) (以下略)
Jensen's Device ってのがわからなかったのですが、リンクがあるので折角だから辿ってみる。
Jensen's Device - Wikipedia, the free encyclopedia Jensen's Device is a computer programming technique devised by Danish computer scientist Jørn Jensen, who worked with Peter Naur at Regnecentralen, particularly on the GIER Algol compiler, one of the earliest correct implementations of ALGOL 60.[1] The following program was proposed to illustrate the technique. It computes the 100th harmonic number by the formula H_{100}=\sum_{i=1}^{100} \frac{1}{i}: begin integer i; real procedure sum (i, lo, hi, term); value lo, hi; integer i, lo, hi; real term; comment term is passed by-name, and so is i; begin real temp; temp := 0; for i := lo step 1 until hi do temp := temp + term; sum := temp end; comment note the correspondence between the mathematical notation and the call to sum; print (sum (i, 1, 100, 1/i)) end The above exploits call by name to produce the correct answer (5.187...). It depends on the assumption that an expression passed as an actual parameter to a procedure would be re-evaluated every time the corresponding formal parameter's value was required. Thus, assignment of a value to i in the sum routine as a part of the for statement changes the value of the original i variable, and when the code of the for loop requires the value of term, the expression 1/i is evaluated and with the new value of i. If the last parameter to sum had been passed by value, and assuming the initial value of i were 1, the result would have been 100 × 1/1 = 100, though actually, it is not initialised. So, the first parameter to sum, representing the "bound" variable of the summation, must also be passed by name, otherwise it would not be possible to compute the values to be added. On the other hand, the global variable does not have to use the same identifier, in this case i, as the formal parameter. ですから、summation で“束縛された”変数を表す sum の第一パラメーターは by name で渡されな ければなりません。さもなければ加算のための値を計算することができないでしょう。 他方、大域変数では formal parameter と同じ識別子、この例では i を使ってはいけません。 Usage The Sum function can be employed for arbitrary functions merely by employing the appropriate expressions. If a sum of integers were desired the expression would be just sum(i,1,100,i);, if a sum of squares of integers, then sum(i,1,100,i*i);, and so on. A slight variation would be suitable for initiating a numerical integration of an expression by a method very similar to that of sum. In the absence of this pass-by-name facility, it would be necessary to define functions embodying those expressions to be passed according to the protocols of the computer language, or to create a compendium function along with some arrangement to select the desired expression for each usage. Because every mention of term within the procedure re-evaluates the original expression, making a local copy of the value of term as appropriate may be worthwhile, as when the procedure might compute the product of the terms as well as their sum.
例の、Smalltalk 特集号の BYTE の記事をPDFにしたものが公開されている とかいう情報を知ってさっそくダウンロードしてみました。 最初のところだけちょっと読んだのですが、APL という名前が登場していて ちとびっくり。ってまあ名前が出てただけなんですけどね。 他には Lisp とか FORTHとか。
F# と Scala。 TechNeilogy: F# vs. Scala, My Take at Year Two
競争相手を以下略
ちまちまと訳を加えてます
C++11 Makes Competitors Go Rusty | Nerds Central C++11 Makes Competitors Go Rusty Rust is breaking free, but does it have any real world value? C++11 is out (has been for a while) and brings many things from Tr1 into the standard. Things like managed memory (shared_ptr) and lambdas and template meta programming (TMP) bring new paradigms to the beating heart of C++. So much so, I would argue, that C++11 makes some of the 'new kids on the block' (think Go and Rust) look pretty pointless. 少し前に C++11 は正式なものとなり、Tr1 の多くの事柄が標準となりました。メモリー管理 (shared_ptr) やラムダのようなもの、それにテンプレートメタプログラミング(template meta programming, TMP) は C++ の beating heart に新しいパラダイムを持ち込みました。それはと ても大きなものなので、C++11 は 'new kids on the block' の一部 (think Go and Rust) を ほとんど意味のないものにしてしまったのだとわたしは主張します。 'Go Rusty' as in go old, look old, corrode and otherwise become less good. This is really just a play on words because both Google and Mozilla have been playing the 'new object oriented native language' game recently. I can really see the motivation, especially from organisations which want to create highly stable, performant, cross-platform systems like browsers. The issue I see with both Go and Rust is that they are solving yesterday's problems. C++/Tr1 has also solved many of the same problems without needing a new compiler, for teams to learn a new language and introducing all those compatibility issues with existing code. 'Go Rusty' as in go old, look old, corrode and otherwise become less good. これは実際には単なる言葉遊びに過ぎません。なぜなら Google と Mozilla の両方ともが最近 になって 'new object oriented native language' ゲームをプレイしているからです。わたし は動機、とりわけ highly stable で高性能でブラウザーのようにクロスプラットフォームなも のを望む組織からの同期をわたしは理解できます。わたしが Go と Rust の両方で見つけた問題 は、これら二つの言語が過去の問題を解決しようとしていることです。C++/Tr1 はすでに同じ問 題の多くを、新しいコンパイラーや新しい言語のチームへの教育、既存のコードに対する互換性 問題すべての introducing を必要とすることなしに解決してしまっています So Boost and Tr1 are cool, but not part of the standard... Well, no longer, a large proportion (if not all) of what Go and Rust are trying to do with a complete new language C++ has done by adding to an existing one via the 2011 standard. ですから Boost や Tr1 は cool だけど標準のものではないという意見はもはや当てはまりませんし、 Go と Rust が完全に新しい言語でもって試みたことの大部分は C++ が2011年の標準を通じて追加された既存のものによって成し遂げました。 From Wikipedia: " Rust is an experimental, concurrent, multi-paradigm,compiled programming language developed by Mozilla Labs.[1] It is designed to be practical, supporting pure-functional, concurrent-actor,imperative-procedural, and object-oriented styles. The main developer is Graydon Hoare, who began work on the system in 2006; Mozilla became involved in 2009.[2] In 2010, work shifted from the initial compiler, written in OCaml, to the self-hosted compiler written in Rust itself.[3] It successfully compiled itself the following year.[4] The self-hosted compiler uses LLVM as its backend. Version 0.1 of the Rust compiler was completed in January 2012.[5] Mozilla described it as an alpha release, suitable for early adopters and language enthusiasts. " Go is a compiled, garbage-collected, concurrentprogramming language developed by Google Inc.[6] The syntax of Go is broadly similar to that of C: blocks of code are surrounded with curly braces; common control flow structures include for, switch, and if. Unlike C, line-ending semicolons are optional; variable declarations are written differently and are usually optional; type conversions must be made explicit; and new go and select control keywords have been introduced to support concurrent programming. New built-in types include maps, Unicode strings, array slices, and channels for inter-thread communication. " I can totally get why people want to write new programming languages. Sometimes it becomes very annoying dealing with some seemingly stupid, repetitious and just plain awkward aspects of many main stream languages. However, I learned from Robert Sales and Micro Focus that a much more productive solution to annoying syntax is to make the compiler able to work out what you mean with better syntax and leave in the old syntax as well. Why is this better? Here are some (but not all) the issues created by introducing a new language into an existing echo-system (which all projects are these days): わたしはようやく、なぜ皆が新しいプログラミング言語を使いたがるのかを理解できました。 Sometimes it becomes very annoying dealing with some seemingly stupid, repetitious and just plain awkward aspects of many main stream languages. しかしながらわたしは、 Robert Sales と Micro Focus から、 annoying syntax に対するより一層 productive な solution は コンパイラーがあなたがより良いと考えている構文を cut したり 古い構文をそのままにしておくようにできるようにすることであると学びました なぜこれが better なのでしょうか? Here are some (but not all) the issues created by introducing a new language into an existing echo-system (which all projects are these days): Massive but ineffective - lots of engineering does not make something worth while or work well. Normally the reverse is the case! Compatibility: The new language will have to talk with older languages. Types will have to be translated; memory models will need to be aligned and compilers will need to 'play nice' together. This is not just as the compiled object level but at the ABI level during linking etc. 互換性: 新しい言語は古い言語と対話をしなければなりません、型は変換されなければならないし、メモ リーモデルをそろえる必要があってコンパイラーは 'play nice' together しなければならな いでしょう。これはコンパイルされたオブジェクトのレベルの話ではなく、リンクの際の ABI レベルでの話です。 Performance: This new language is super fast. Great, but it will have to work with existing systems. The interface between the two will slow stuff down a lot. Either that interface will have to be messy (see Compatibility above and/or JNI) or via a marshalling system (Protocol Buffers, Avro etc). The problem with marshalling between dissimilar systems is that it is really slow. It might seem like a good idea (just like the steam gun right) but it is a stupidly expensive and complex way to solve a problem of one's own invention. Such protocols are great for clustering, cloud processing and client-server work; they are just wrong headed for gluing systems together to work around using different languages in one system. Keep it simple. 性能: この新しい言語は super fast で Great ですが、既存のシステムと動作しなければなりません。 それら二つの間のインターフェースは大幅にスローダウンさせる要素となるでしょう Either that interface will have to be messy (see Compatibility above and/or JNI) or via a marshalling system (Protocol Buffers, Avro etc). dissimilar systems 間でのマーシャリングの問題はそれが本当に遅いということです。 It might seem like a good idea (just like the steam gun right) but it is a stupidly expensive and complex way to solve a problem of one's own invention. Such protocols are great for clustering, cloud processing and client-server work; they are just wrong headed for gluing systems together to work around using different languages in one system. Keep it simple. Build: Build system complexity has been one of the biggest headaches in all the major projects I have seen over the last few years. Build systems are getting more and more complex as the demands of heterogeneous programming and dependency management push technology beyond the sane. Frameworks like maven, msbuild and even good old make work fine if a project uses one language; they generally degenerate into a big ball of mud otherwise. ビルド: ビルドシステムの複雑さは過去数年わたしが見てきたすべての主要なプロジェクトにおいて biggest headaches のひとつとなりました。heterogeneous programming に対する要求や dependency management push technology beyond the sane に伴ってビルドシステムはますます複雑になってきています。 maven や msbuild のようなフレームワークであるとか、あるいはgood old な make でさえも ひとつのプロジェクトでひとつの言語しか使っていないのであれば問題なく働きます。 they generally degenerate into a big ball of mud otherwise. Debugging: Debugging across languages is really tricky. I should know, I have spent a lot of time doing it over the last few years. For example, even debugging from COBOL into Java and back on the same JVM is tricky because a Java debugger does not understand COBOL and the same is the case in reverse. Jumping between native languages can be even harder when their internal data structures, interpretations of indirections (pointers etc) and (shudder) interpretations of thread state are completely different. デバッグ: 複数の言語をまたがってのデバッグは本当に tricky です。I should know, 過去数年間にわたり、わたしはそういったことのために多くの時間を費やしました たとえば even debugging from COBOL into Java and back on the same JVM is tricky なぜならJava のデバッガーはCOBOLを理解しないし その逆にCOBOLのデバッガーはJavaを理解しないからです Jumping between native languages can be even harder when their internal data structures, interpretations of indirections (pointers etc) and (shudder) interpretations of thread state are completely different. Team Training: Assembling a team of people who know one language well is hard enough; doing so across multiple languages is extremely challenging. Some people will be prepared to learn new stuff but not all will. Time pressure, as we all know and love it now, generally does not leave time to learn a language up front in a project. チームのトレーニング: ひとつの言語をよく知る人たちでチームを組むことはとても困難なことです。 複数に言語にまたがってそういったチームを編成するのは extermely challenging です。 Some people will be prepared to learn new stuff but not all will. Time pressure, as we all know and love it now, generally does not leave time to learn a language up front in a project. Team Embedded Knowledge: It is very hard to keep the knowledge of a multi-language project spread throughout a team. It is even harder to keep that knowledge 'live' as team members leave and join. Because language interoperation patterns are less well known and less standardised that intraoperation patterns, unique embedded knowledge tends to build up in teams. Version Management (language/runtime): Different languages frequently have slightly different life-cycles and dependency management issues. These accumulate to cause challenges in revision control. (言語とランタイムの) バージョン管理: 別々の言語はしばしば大きく異なるライフサイクルと dependency management を持っています。 These accumulate to cause challenges in revision control. Tooling Costs: Good tooling can be expensive. Tools like profilers, code complexity analysis systems and test coverage checkers can all be pretty costly to buy. Whilst some have good open source alternatives, these have the embedded cost of maintenance and installation. Again, multiple languages usually means that a team needs more tools and hence more cost. Licensing Of Runtimes And Libraries: We often get complacent thinking all libraries and runtimes will be free. This in not the case. Even if they are 'free' as in they cost no money, their licensing requirements might complicate commercial arrangements. If they are commercial and have enforced licensing this introduces a whole new level of complexity. One really nasty situation is when two completely different forms of code hardening in the licensing systems do not play nicely together. I have seen it happen and it is not pretty. ランタイムやライブラリーの Licensing: Lifespan And Sundown: All things come to an end. Support for a language or, more often, a version of a language will come to an end. Managing these life cycle events can be challenging in a single language environment. When more than one language enters the picture, the cycles will almost certainly not coincide. The less common a language is, the more likely that is will be sundowned whilst the products using it are still current. It is fairly easy to get into a situation when one can never actually release on a completely stable, current set of components. Lifespan And Sundown: すべてのものごとには終りがあります。ある言語に対するサポートもそうですし、もっと頻繁に あるのが言語のあるバージョンのサポートが終了することです。これらの life cycle events を管理することはsingle language environment において challengig となる可能性があります。 二つ以上の言語が視野に入ってきた場合、そのサイクルは almost certainly not coincide となるでしょう。 The less common a language is, the more likely that is will be sundowned whilst the products using it are still current. It is fairly easy to get into a situation when one can never actually release on a completely stable, コンポーネントの current set Startup And Shut-down Sub-Systems: A programming language is just the code right? Wrong - generally there is a lot more to it than that. It can be tricky even to mate up C with C++ projects because C++ has to initialize statically referenced objects before main is called. Many other languages have even more complex issues to do with threading, signals and loaders which all get in each other's way when building a mixed language system. サブシステムのスタートアップとシャットダウン: A programming language is just the code right? Wrong - generally there is a lot more to it than that. C++ では main が呼び出されるよりも先に静的に参照されているオブジェクトの初期化を行わなけ ればならないのでC++を含むCプロジェクトでさえ混乱を招くほどtrickyとなる可能性があります。 他の多くの言語では、スレッドやシグナル、 mixed language system を構築するときに all get in each other's way するローダーを扱うときに もっと複雑な問題を抱えさせします。 Paradigm Contamination: Seeing Java written in the in style of COBOL is quite an eye opener. I am not a COBOL bigot either way; it is a solid language that is really good for some things. Java is also a solid language, but it really should not be programmed in the style of COBOL. However, where the two languages touch the chances are the COBOL will look like Java and the Java look like COBOL. I have seen exactly the same thing with C# and C. If a programmer is working in C and writing a bit of Java, the chances are the Java will be C like. Equally, the natural paradigm of a cross language API tends to be a hybrid of both languages. Whilst these things are to be expected, they are horrid. The code looks bad, smells bad and is hard to test or maintain. パラダイムの汚染: COBOL のスタイルで書かれた Java を見ることはかなり衝撃的なことです。わたしはいずれにし ても COBOL bigot ではありませんが、COBOL は soolid な言語で、一部の事柄に対してはとて も優れた代物です。Java もまた solid な言語ですが、COBOL スタイルでプログラムされるべき ものではありません。わたしは C# と C とでのこれとまったく同じことを見たことがあります。 あるプログラマーがCを使っていて、ちょっとだけJavaで書くことをしたら その Javaコード は C で書いたもののようになることでしょう。 同じく、cross language API の自然なパラダイムは両方の言語の hybrid となる傾向があります。 Whilst these things are to be expected, they are horrid. そのコードは見た目も悪く、悪臭を放ち、テストや保守が困難です。 Brain Strain (the bilingual problem): Children which are brought up from babyhood as bilingual usually learn to speak more slowly than their monoglot contemporaries. Can the analogy be brought over to programming? In the absence of hard evidence from psychologists, it seems at least likely and reasonable to assume that coding progress will be slowed down by the extra cognitive burden of working in more than one language. ... and so on ... So what am I saying? I hope I have established that in modern environments, introducing new languages carries with it a lot of down sides. To put it another way - there has to be an overwhelming need before there is an overall benefit in introducing a new language rather than using a well established general purpose language. Go and Rust are compiled straight to native and so the existing candidate as an alternative is C++. C++ has huge pre-existing libraries and is (with the possible exception of C) the most likely language in which other native code will be written. Even if there is a large legacy C library set, C++ to C is a well know interoperation with some issues from the list above but not too bad. So, is there an overwhelming need to replace C++ with Rust or Go? I would definitely say NO! Simple paradigm following within the pantheon of C++ allows this language to behave just as well as Rust or Go - or at least that is what I fully expect. Let us think about the big ideas behind Go: It is simple, clean and has garbage collection. Well, one can write simple clean C++ and use share_ptr. Just because C++ can be super complex does not mean it has to be. Let us think about the big ideas behind Rust: Type inference, static assertions (checks), simple constant rules to facilitate reasoning about multi-threaded execution. These are nice things indeed. However, using lambda's correctly along with other templating techniques makes C++ straightforward for multi-threaded reasoning. Template Meta Programming should be able to perform most of the type reasoning which the compile time checks are performing in Rust. C++11 has type inference. It does not use clever code branch analysis like Rust, but it is there (auto and decltype). The ideas in Rust are definitely more tricky to implement in C++ than those in Go; however, the effort required to do so is , IMHO, trivial compared to creating, using and maintaining a new language. Further, the effort to replicate Rust's good features in a C++ paradigm is much less than the effort of dealing with a new language (as described above). Rust におけるこのアイデアは C++ で実装するには Go よりも格段にトリッキーなものです。し かし、わたしの見るところでは実装するのに要求される労力は新しい言語を作って、それを使っ て、メンテナンスをすることに比べればたいしたことがないものです。加えて、C++ のパラダイ ムで Rust の good features を replicate するための労力は新しい言語を扱うための労力と大 差ありません。 Here is a very trivial bit of C++ with which I was playing this morning: // VSPL.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include <boost/spirit/include/qi.hpp> #include <iostream> #include <iterator> #include <algorithm> namespace client { namespace qi = boost::spirit::qi; namespace ascii = boost::spirit::ascii; template <typename Iterator> bool parse_numbers(Iterator first, Iterator last) { using qi::double_; using qi::phrase_parse; using ascii::space; bool r = phrase_parse( first, last, double_ >> *(',' >> double_), space ); return first == last; } } int main() { typedef std::istream_iterator<int> in; std::string code = "1,2,3,4,5,6"; std::cout << (client::parse_numbers(code.begin(), code.end())?"All is well":"It barfed") << std::endl; auto exiter = [] (const int v) { if(v==123)exit(0); } ; for_each(in(std::cin),in(),exiter); } Here we can see a lambda being used as an immutable first order entity. The for_each could be parallel or serial, it really does not matter. We can also see type inference where the type of the lambda is inferred from its internal code (in this case void). Here we can see a lambda being used as an immutable first order entity. The for_each could be parallel or serial, it really does not matter. We can also see type inference where the type of the lambda is inferred from its internal code (in this case void). I did not include this here because it is a clever bit of code; Indeed, my motivation is quite the opposite! I am working on a parser for my research language VSPL using the Spirit library in Boost. The above was just a play thing to make sure the project was set up correctly. However, easy features like type inference, lambdas, name spaces and internal DSLs are so accessible in C++ now that they are just natural in the most trivial coding example. I just don't see a strong enough argument for new languages to replace C++. I did not include this here because it is a clever bit of code; わたしはここではこれを含みません。 なぜならこれは clever bit of code だからです。 Indeed, my motivation is quite the opposite! I am working on a parser for my research language VSPL using the Spirit library in Boost. The above was just a play thing to make sure the project was set up correctly. However, easy features like type inference, lambdas, name spaces and internal DSLs are so accessible in C++ now that they are just natural in the most trivial coding example. I just don't see a strong enough argument for new languages to replace C++.
↑に対する反応から。
C++11 Makes Competitors Go Rusty | Hacker News Compatibility: The new language will have to talk with older languages. Types will have to be translated; memory models will need to be aligned and compilers will need to 'play nice' together. This is not just as the compiled object level but at the ABI level during linking etc. I've spent more time solving issues with memory models in C++ than I have in any other language because C++ has no ABI - I've had patches to MSVC change the memory layout of objects and cause breakage which is just as bad as you get with any sort of language interop scenario. (略) Let us think about the big ideas behind Go: [snip] Well, one can write simple clean C++ and use share_ptr. Just because C++ can be super complex does not mean it has to be. Unless, say, you're writing a DLL (another fun fact: not only can your API not have STL, exceptions also can't cross DLL boundaries), or you're using DLLs written by other poor souls who were consigned to writing DLLs with a C++ API. As a finishing note, one of my favorite articles on the subject of complexity in programming: http://www.joelonsoftware.com/items/2009/09/23.htmlStroustrup is right, but that doesn't prove your point. Every language will have detractors, but not every language will be the target of every particular complaint. Lua, for example, is a useful language and it has largely avoided being a ball of mud. Naturally, that minimalism brings its own set of issues and complaints. But the point is, you don't need to be as much of a ball of mud as C++ in order to be useful or successful. I think a lot of language partisans, and C++ partisans in particular, point to Stroustrup's quote as an excuse for their language's warts. It's true that no language can ever be perfect, but that doesn't mean that all complaints are without merit and unworthy of attention and consideration.
アワーズの連載でネイが登場したのでこういうやりとりが
【ナポレオン】長谷川哲也34【陣借り平助】 619 名無しんぼ＠お腹いっぱい [sage] 2012/02/02(木) 14:52:56.43 ID:VFCbwGB30 Be: まあネイの真骨頂はロシア退却戦なわけで マリー・テレーズ(マリー・アントワネットの娘)すら感動させて死刑に1票投じた事を後悔するぐらいだからな。 620 名無しんぼ＠お腹いっぱい [] 2012/02/02(木) 14:58:32.01 ID:6GToE1QU0 Be: 退き佐久間みたいなもんか 621 名無しんぼ＠お腹いっぱい [sage] 2012/02/02(木) 22:07:23.49 ID:hLc7fcfT0 Be: かかれマッセナに退きミシェル。米ベルティエに木綿ダブーってとこかい？ 622 名無しんぼ＠お腹いっぱい [sage] 2012/02/02(木) 22:17:08.83 ID:zh2ELWM40 Be: 鬼武蔵は、誰なんですか
時間のない人に、本書の中で読むべき章を選べと言われたら、第6章を挙げます。
同書では、過去デブサミに登壇した開発者を中心としたIT業界に関わる100名の執筆陣が、ソフトウェア技術者に贈りたい書籍を選定、その内容を紹介する。
ところで、ゲーム史に関する本格的な研究や記録は日本ではほぼない。これは世界のゲーム史から見たとき、恐ろしく不幸なことだ。
あー毒吐きてえ
その1
Wikipedia:Wikipedia Signpost/2012-01-30/Technology report - Wikipedia, the free encyclopedia Why "Lua" is on everybody's lips, and when to expect MediaWiki 1.19 By Jarry1250, January 30, 2012 Lua chosen as new template scripting language Reducing the inefficient complexity of complicated templates has long been on the wishlists of those who design and maintain them. It is a complexity that can put a significant drain on server resources, not to mention one that makes accurate duplication of templates between wikis incredibly time consuming and error prone. This complexity is caused by a number of factors, but it has long been recognised that the introduction of certain constructions found in full programming languages (among them loops, arrays and a full range of string functions) would drastically simplify matters. 複雑なテンプレートの非効率的な複雑さを軽減することは、それらを設計したり保守している人 たちによるウィッシュリストに長いこと載っていました。その複雑さはサーバーのリソースを目 だって食いつぶしてしまう可能性のあるもので、 not to mention one that makes accurate duplication of templates between wikis incredibly time consuming and error prone. この複雑さは数多くの要因によるものですが、full programming languges にある いくつかの constructions (ループや配列、full range の文字列関数といったもの) の導入によって劇的に事態が単純になるであろうと認識されていました。 Of course, the introduction of a programming language would bring with it a number of other problems, particularly with regards to privacy, security and memory footprint. As a result, the long term consensus was that the introduction of a programming language would be a major undertaking, including time for discussing which languages would work best in a heavily sanitised environment. The project as a whole has been discussed at regular intervals, but it was only this week that a consensus seemed to emerge in favour of Lua, a lightweight but relatively unheard-of language generally regarded as being "easy to learn" (wikitech-l mailing list). もちろん、プログラミング言語の導入は、特にプライバシーやセキュリティ、メモリーの使用量 に関して別の問題を数多く持ち込むことでしょう。結果として、long term での consensus は プログラミング言語の導入は major undertaking でした。 including time for discussing which languages would work best in a heavily sanitised environment. プロジェクト全体としては通常のインターバルで議論されていましたが、 a lightweight but relatively unheard-of language generally regarded as being "easy to learn" である Lua を推すという合意は今週だけの議論でした #違うよなあ、正直わからん The preferred implementation at this time is via a separate namespace for scripts, perhaps augmented by the overloading of the double-curly-brace notation to incorporate both Script and Template namespaces. Work is expected to start after the release of 1.19 and could well centre around the Berlin Hackathon, held annually in May. 今回好ましい実装はスクリプトのための名前空間の分割を通したものです。 それはおそらく、二重カーリーブレース記法のオーバーロードによって
その2 ↑に対する reddit での反応
Wikipedia chooses *Lua* as its new template/macro language : programming A language with no baked-in unicode or I8N support at all. For an international wiki. That's gonna be interesting.Internationalization ("i18n") is the design and development of a product, application or document content that enables easy localization ("L10n" = the adaptation of software for a specific locale).Indeed. I doubt JavaScript's UTF-16 surrogates would be handled properly in practice though, had they gone w/ JS.JS has really broken Unicode support http://98.245.80.27/tcpc/OSCON2011/gbu/gbu.htmlHonestly, most languages and platforms have broken Unicode support.Yeah but really, does Lua have support for anything "baked-in"? I mean I figure that's kind of the point. It and TCL have this thing going on of being like, language templates. You get an interpreter and the absolute core syntax to make procedural programming usable, batteries are your problem.Heh - a whole thread of replies promoting languages with half-baked i18n support and no mention of Tcl.Please, do tell.Tcl was designed to be a lightweight scriptable layer on top of any C library for scripting purposes also. It has had real i18n support since about 2005 or so. I don't think Tcl could compete with the size or speed of Lua though. Then again, does Lua have a standard GUI library (ala tk) currently? You can whip out stuff wicked fast in Tcl/Tk once you are even halfway proficient. I'm seeing Lua not just mentioned everywhere but implemented in things I use, time to start from lesson 1 on projecteuler with a fresh language!Then again, does Lua have a standard GUI library (ala tk) currently? Lua doesn't really have a standard anything, that's kinda the point of it; it's brilliant for writing complex configuration/glue stuff (think AI state machines for video games, etc) that needs too hook into a bunch of custom APIs. Very little Lua code would need to define a GUI, and if it did, the host application probably already has a framework to do so. That said, there's a ton of bindings to GUI frameworks on the wiki page.Tcl has had full unicode support since 8.1, released in 1999 (!). It's a very stable, simple yet powerful language. EIAS (actually, everything has a string representation) seems to make it particularly suited as a templating language. You can create safe interps and extend the language with new control constructs or even syntax. There are other reasons to like it.
訳をつけていく余裕がない。
その3
The Data Mules Blog Why Lua January 30, 2012 at 12:19 PM | 32 Comments Posted by: ktr Disclaimer: this article is intended for those familiar with programming languages (Lua in particular). In this article, I would like to discuss why you should use Lua. This all started with a message that recently popped up on the Lua mailing list regarding why isn't Lua more widely used? The answers went from randomness to lack of libraries to a variety of other things, but the one that resonated with me most was that there are fewer people who enjoy the do it yourself approach, which Lua fully embraces. I've come to think of Lua as the Arch Linux of programming languages. Which, almost by definition, means fewer people will enjoy Lua rather than more. So then why would you want to use Lua? In no particular order, here are some of the reasons why we use Lua to develop our product: 本 article では、なぜあなたはLuaを使うべきなのかについて論じます。 This all started with a message that recently popped up on the Lua mailing list regarding why isn't Lua more widely used? The answers went from randomness to lack of libraries to a variety of other things, but the one that resonated with me most was that there are fewer people who enjoy the do it yourself approach, which Lua fully embraces. わたしは Lua を Arch Linux of programming languages と考えるようになりました。 Which, almost by definition, means fewer people will enjoy Lua rather than more. So then why would you want to use Lua? わたしたちの product を開発するためにLua を使う理由をいくつか順不同で挙げます。 1. Integration with C (and C++ for that matter) C (と C++) との統合 I have used a lot of languages during my short career as a programmer. Lisp, Scheme, Python, Perl, Bash, VBA, SQL, etc. etc. etc. There is no other language that I have ever used that even comes close to Lua when trying to commingle C code. The C API is so clean and so intuitive that I would argue that you could get up to speed on its use in an afternoon. Check out PIL's section on the C API if you are interested in learning more. 短いプログラマーとしてのキャリアにおいてわたしは多くの言語を使ってきました。Lisp、Scheme、 Python、Perl、Bash、VBA、SQL、などなど。C のコードをコンパイルしようと試みたときに、Lua ほど密着するほど使った言語は他にはありませんでした。Lua の C API はとてもきれいなもので、 また intuitive で、半日あれば使えるほどのものといえるでしょう。 もしもっとこれについて知りたいと思うのなら、C API の PIL セクションを読んでみてください。 Why is this important? Well, for one this means that if you have an existing C (or C++) library, it is usually not very difficult to expose the API to Lua. Nor is it difficult to write a script in Lua and get something running on the C side. This also means that speed problems are rarely an issue in Lua programs. You can write something in Lua and truly rewrite it in C if it is a speed problem. It is always possible to rewrite something in C in other languages, but Lua is the only language in which I have found it easy to do so. なぜそれが重要なのでしょうか? Well, for one this means that if you have an existing C (or C++) library, it is usually not very difficult to expose the API to Lua. Nor is it difficult to write a script in Lua and get something running on the C side. このことは Lua のプログラムにおいてはスピードが問題になることはほとんどないことも意味します。 あなたは Lua で何かしら書くことができるし、それでスピードに問題があれば C で丸ごと書き直すこともできるのです。 これは他の言語で書かれたものをCで書き直すときには常にいえることではありますが、 わたしがこれまで見てきた中で Lua はそれがとても簡単にできる唯一の言語なのです。 2. Speed and Simplicity 速度と単純さ The standard Lua implementation performs extremely well compared to most other languages, even without writing anything in C. Perhaps this is because Lua uses a register based virtual machine rather than a stack based machine. Or it could simply be due to the fact that the programmers behind Lua are just very talented. Whatever the reason, you are rarely going to be overly concerned with performance when writing Lua code. 標準の Lua の実装は、Cで一切書かなかった場合でさえ他のほとんどの言語と比較できるような 性能を発揮します。これはおそらく、Lua がスタックベースの virtual machine ではなくレジ スターベースの virtual machine を使っているからでしょう。あるいは Lua の背後にいるプロ グラマーたちがとても才能豊かな人たちだからかもしれません。いずれにしても、Lua でプログ ラムを書いているときに性能を気にしなければならないことはほとんどないでしょう。 But, if you are not getting the results you would hope or expect, you can get an almost drop in replacement for the standard Lua implementation with LuaJIT. From the overview page: But, if you are not getting the results you would hope or expect, you can get an almost drop in replacement for the standard Lua implementation with LuaJIT. From the overview page: LuaJIT is widely considered to be one of the fastest dynamic language implementations in existence ... with an unmatched low memory footprint: less than 125K for the VM plus less than 85K for the JIT compiler (on x86). LuaJIT speeds can rival code written in C. And if you are still not getting the speed you want, see my 1st point above. LuaJIT のスピードは C で書かれたコードに匹敵するものです。 And if you are still not getting the speed you want, see my 1st point above. 3. Education 教育 While not necessarily a language feature, I have found that using Lua has improved my general computer science knowledge over time. For example, this writeup on the implementation of Lua 5.0 gave me a very good overview of how virtual machines are implemented. Reading the very accessible source code, while following the recommended reading order suggested by Mike Pall (author of LuaJIT) has been eye opening as well. I don't think any of this would be possible except for the methodical manner in which Lua has evolved over time. This has allowed Lua to remain "Clean C" which means that it is easier for you to understand as a user of the language. 4. Functional Lua provides you with functional programming constructs that make programming more enjoyable. Examples include anonymous functions, higher order functions, lexical closures, proper tail calls, etc. And this is not some superficial gloss applied on top of the language - it represents some of the fundamental underpinnings of the language itself. For example, all functions in Lua are values (like the number 2 or the string "ktr") - and this means that every function in Lua is anonymous. You simply attach a name to it so that you can reference it later. Thus, like Roberto describes in his book, you can reassign print with: print = math.sin This type of functionality also enables you to build sandboxes if you need them. If printing were a dangerous operation, you could replace it with your own print function or simply remove it from the global environment. 5. Everything is a Table すべてがテーブルである Everything in Lua is a table. Arrays, hashes, "modules", the global environment, etc. They are all tables. This means that you can require some module (similar to Python's import statement) and treat the resulting value just like you would any other table. In Python, you might __import__('...')' some module and then the variables of the return value would be accessed like vars(module). Not very difficult, but also not very Pythonic. In Lua, you would access the variables in that module just like any other table (module[var]). I only mention Python to highlight differences - simply showing that it may be easier to "hold Lua in your head" due to such consistencies. Lua におけるすべてがテーブルです。配列、ハッシュ、“モジュール”、グローバル環境等々 これらすべてがテーブルです。 これは、いくつかのモジュールを (Python の import 文と同様) require して その結果を別のテーブルのように扱うことができるということです。 Python では、いくつかのモジュールを __import__('...') とすると そのモジュールにある変数に vars(module) のようにアクセスできます。 これはとても難しいというものではありませんが、とても Python 的であるとも言えません。 Lua ではそういったモジュールにある変数にアクセスすることは 別のテーブルを module[var] とアクセスするようなものです。 I only mention Python to highlight differences - simply showing that it may be easier to "hold Lua in your head" due to such consistencies. This has the added benefit of allowing you to learn the full Lua syntax faster than you could in most other languages. Without needing to worry about how lists are written versus how dictionaries, packages, etc. are written, you can "assume" you already know how they are written because you only need to know the one construct. このことは大部分の他言語の場合よりも短い時間で Lua の構文全体を学習できるという benefit を付加しました。 リストや辞書、パッケージといったものがどのように記述されているかを心配する必要はなく 一つの construct を知っていればよいので、 それらがどのように記述されているのかすでに知っていると “仮定”できるのです。 6. Consistent 一貫している If you haven't figured it out already, Lua is a very consistent language. A lot of time has gone into each and every feature to make sure that it was done "just right". For example, Lua didn't have a for loop until Lua 4.0 - 7 years after the first release. This was because If you haven't figured it out already, Lua は非常に一貫性のある言語です。 A lot of time has gone into each and every feature to make sure that it was done "just right". たとえば最初のリリースから7年、Lua は 4.0 になるまで for ループを持っていませんでした。 なぜならそれはこのような理由があったからです while loops were more general. ... Also, we could not agree on a good syntax. (See page 6 of this document). And since the authors of the language have remained relatively unchanged and rather limited (the Lua team does not like to accept patches), the language has evolved somewhat slowly and quite coherently. So you know features are well planned. (However, this also means you shouldn't expect to have a lot of your pet features implemented anytime soon.) (See page 6 of this document). この言語の author たちは比較的変更を行わないし、変更も限定しさえするので (Lua チームはパッチを受け付けるのを好みません)、 the language has evolved somewhat slowly and quite coherently. So you know features are well planned. (とはいえ、このことは a lot of your pet features がすぐに実装されるようなことは期待すべきでないことも意味します) 7. Portable 移植性 I won't go into a lot of detail, but rest assured that Lua runs on almost everything you can think of. The code is written as "Clean ANSI C", so if you have a compliant C runtime, you will likely be able to get Lua running without much fanfare. 詳細には踏み込みませんが、Lua はあなたが想像できるほぼすべての環境で実行可能です。Lua のソースコードは "クリーンな ANSI C" で記述されているので、あなたが C のランタイムに従 うのなら、大げさな移植作業をしないでもLua を実行できるようにさせられるでしょう。 All in all, a very powerful, yet simple language.
その4．↑に対して
Why Lua? | Hacker News I took some Visual Basic programming courses in high school, some PASCAL courses in college, and then didn't program anything other than basic HTML/CSS for the next eight years. Last year I programmed an iPhone game in Lua (using the Corona SDK) and it was easy as Tau. Sure a better programmer would have finished the programming aspects in a quarter the time it took me, but I started by looking at Objective-C and I'm not sure I ever would have picked it up without some kind of formal training. Contrast with Corona/Lua, where I watched a few eight minute videos on YouTube and could turn around and make simple but complete programs, and more importantly completely understand what was going on within them. Reading the Lua documentation was a revelation, reading Apple's was a headache. Why Lua? http://itunes.apple.com/us/app/beat-boxes/id460798042Doesn't Apple forbid applications built using things like this?As long as you are not running code that is downloaded after app install (e.g. either embedded in the app itself or entered by the user from the keyboard) you are good to go. This mod to the previously ominous app store policies is used by quite a lot of applications.The more I learn about Lua's design and implementation, the more impressed I am. It's very rare to see software that does so much with so little code. The design is extremely clean and the code is extremely fast. The C API is easy to use and gives good performance, and yet encapsulates enough of the VM's implementation that C modules are source and binary compatible with both Lua and LuaJIT, two very different implementations of Lua. Note that the C API was designed before LuaJIT was even written, so this API was designed without the benefit of seeing how different implementations of Lua might vary. The source is very readable for the most part; my only stumbling block is that their naming of types and variables is extremely terse at the cost of readability sometimes, and the extensive use of macros can sometimes can require a lot of jumping around. But Lua is an impressive achievement that I frequently refer to for design inspiration.Lua has great C integration, but LuaJIT's is even better. You can natively interface with C code without a recompile, just by defining the C function prototype in Lua, and using it like you would any normal lua function. Better still, LuaJIT can frequently inline the calls to C code, so there's no cross-language marshaling penalty. Check out http://luajit.org/ext_ffi_tutorial.htmlNot criicizing lua, but worth comparing to guile. > Integration with C (and C++ for that matter) Guile does it better. You can use shared memory threads in guile without any penalty. Atmost you have to allow for the garbage collector to run when inside FFI functions. But that is a small price to pay in case you need to use multiple parallel-concurrent threads with a single heap. Guile was built with FFI in mind and has an impressive history. Just take a look at guile gnome bindings. > Speed and Simplicity Guile 2 is extremely fast. Not as fast as LuaJIT, but it no reason it won't get there. As for simplicity, take a look at the partial evaluator in trunk of guile 2. > Education Guile is good old scheme. > Functional Can't get more functional than scheme :) > Everything is a Table Well, almost everything is a pair in guile. Vectors and hash-tables are trivially available. Though I recommend to sticking to functional programming in scheme style. > Consistent As before, can't get more consistent than scheme. > Portable Guile is available on n900. So there. To continue, guile has continuations (delimited or otherwise), and macros (hygienic or otherwise), both of which are effectively missing in lua. And guile offers all of this while supporting native threading with a single heap. Sweeet.Not sure if I'd agree that Guile's FFI bindings are better than LuaJIT's FFI. It's certainly easier to declare a function in LuaJIT - you can take the definition directly from the header file, rather than transcoding it into s-exps. Compare: (define memcpy (let ((this (dynamic-link))) (pointer->procedure '* (dynamic-func "memcpy" this) (list '* '* size_t)))) vs. ffi.cdef [[ void * memcpy ( void * destination, const void * source, size_t num ); ]] You also get the ability to add metamethods and finalizers to returned C objects (so you can use Lua's built-in GC to clean up after, for example, your FILE*). As for the speed, there's no reason that a lot of dynamic languages couldn't be as fast as LuaJIT. But none of them are even close. I wish LuaJIT was still up in the computer language shootout. The LuaJIT interpreter (with JIT turned off) is 3x faster than V8 on the PC, and faster than Java on Android. And that's the interpreter - the JITed code is way faster. Of course, macros are awesome, and a huge point in Guile's favor. On the plus side, Lua is very easy to understand, especially if you're coming from Javascript.
なんでこう盛り上がるんだろう。
同じ元記事に対して reddit では
Why Lua : programming Lua is amazing for embedding. You can even easily overload its memory allocator or default data type. I needed to do this for a project where we were running on a processor without native support for double or without a standard C library. That is just amazing stuff.When I first started playing with Lua, I found myself repeatedly saying of its features "You can't do that! That sounds like a great idea but you can't do that because it will, well because... I'm pretty sure this is a design mistake in the long run because... ", and then failing to come up with compelling arguments against them. Take for example the "..." syntax for variadic functions. You can't do that, right? I distinctly recall being frustrated with C's clunky va_list and va_start etc., and the fact that you can't easily wrap variadic functions, and it's just a whole mess. I distinctly remember justifying that to myself and thinking that it couldn't be any other way. But Lua comes along with its "...", like it just doesn't give a fuck. So things like that certainly have had an effect on how I think about programming. I'm not a big fan of some of the ways I've seen people use Lua. For example, people want classical inheritance, so you have all these libraries out there that either roll their own classes, or rely on other libraries for classes. So now if you want to use four third-party libraries, you're liable to find yourself juggling four slightly different inheritance models from class libraries with overlapping namespaces – suddenly JavaScript's choice of having class as an unused reserved word seems extremely wise. Then of course there's the commonly-seen-as-brilliant practice of serialization by emitting Lua code. It's just like JSON but without any regard for security!Python's variable length arguments syntax is probably the best out of any language.This article is just what I have been looking for. I have started with Lua two weeks ago but there still were so many questions. Good article with good links in it. I am sure it will help me alot in the future. Thanks for sharing!Check out my language, http://moonscript.org It compiles into Lua, but does a lot of what CoffeeScript did for JavaScript and more. Classes, comprehensions, cleaner syntax, etc. Here's the reference manual: http://moonscript.org/reference
我が師匠の有難い教えに、「技術書と、思想本と、経営者の考えが分かる本、この3種類をバランス良く読むべし」というものがあります。
いつにも増して日本語の部分が少ないものになってしまったw
一つ前へ
2012年1月(下旬)
一つ後へ
2012年2月(中旬)
リンクはご自由にどうぞ
メールの宛先はこちら