「インタプリタ」を含む日記 RSS

はてなキーワード: インタプリタとは

2019-12-27

anond:20191227192853

C++メリットC++にくわえてC++Pythonインタプリタを作れる

PythonメリットPythonにくわえてCUDAJITC++みたいなもん)を呼んだりできる

 

Pythonのほうが環境ごとの差がすくないから楽に組める

C++のほうが環境ごとの特長を生かしたプログラムが楽に組める

anond:20191227192853

実行に時間制限がある場合インタプリタよりバイナリを直接実行できる方が有利なので。

C++は低レイヤーも扱える(人の手でゴリゴリチューニングできる)し。

2019-12-04

C#コンパイルといわれてそういやJavaコンパイルっていうなとおもっていたんだが

VMに対して中間言語を吐き出すことをコンパイルと呼んでいるのかと、そりゃPythonコンパイルって言いだすなと

CPUに対して中間コードを吐き出す

VMに対して中間コードを吐き出す(JIT含む)

インタプリタに対して中間コードを吐き出す

それぞれ何コンパイルといって区別してるの?

2019-11-18

オープンソースだとインタプリタ独自コマンドを追加したりする関係

中身の構造ある程度知ってるから

そういう動作原理を知っているっていうのは強みでもあるんだが

ほとんどいらないし、

困ったときだけ知っている人に聞くのほうがはるかに徳

 

オープンソースコード動作原理がわかるまで読み込むって

時間の浪費で苦痛な上に、知ってる人にききゃぁいいの方がはるかに得だから

2019-10-23

anond:20191023190834

Pythonインタプリタがあるならこれだな

import random

import string

''.join(random.SystemRandom().choice(string.ascii_letters) for _ in range(8))

パスワードも許されている文字範囲を気にしつつこんな感じで作ってる。

C++17が使えるならこんな感じかなぁ...

#include <algorithm>

#include <iostream>

#include <random>

#include <string>

int main(void)

{

std::string input = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";

std::random_device rnd;

std::string result;

std::sample(input.begin(),

input.end(),

std::back_inserter(result),

8,

rnd);

std::cout << result << std::endl;

return 0;

}

2018-12-14

anond:20181213125829

小学校必須化されるプログラミング教育は激しく誤解されている。

小学校段階において学習活動としてプログラミングに取り組むねら いは、『プログラミング言語を覚えたり、プログラミング技能習得 したりといったことではなく』、論理的思考力を育むとともに、プログ ラムの働きやよさ、情報社会コンピュータをはじめとする情報技 術によって支えられていることなどに気付き、身近な問題解決主体的に取り組む態度やコンピュータ等を上手に活用してよりよい 社会を築いていこうとする態度などを育むこと、さらに、教科等で学 ぶ知識及び技能等をより確実に身に付けさせることにある。

プログラミング基礎資料

これが学習指導要領になり、教科書になり、現場に降りてくると……

児童コンピュータプログラム作成させるのはダメ!と忖度されて、アンプラグド実践花盛り。

http://www.mext.go.jp/component/a_menu/education/micro_detail/__icsFiles/afieldfile/2018/11/06/1403162_01_1.pdf

改訂第二版の例示では、スクラッチで作った「仮想プラグラミング炊飯器」が登場。ドリル教材なんだけどねぇ。

現場先生に「プログラマブル○○シミュレーター」を製作しろってのも無理があるしなぁ。

文句があるならお前が作れとか言われそうなので……スクラッチでなんか作るのは無理でしたorz

インタプリタBASICインタプリタで開発してみるテスト

お子様が大好きなカードプログラミングして、EXCEED MODEL ZAKU HEAD のモノアイを こいつ動くぞ! にするぞ。

でも、これ現場で使ったら「誰にでもできる授業でなくてはやってはいけない」って怒られちゃうんだよね。

2018-06-21

anond:20180620193354

ここでは「こいつ頭おかしい」ってなってるけど

最近ブクマはこのレベルの頭おかしいやつゴロゴロいるよね

インタプリタ式に観念記号をラディカルに振り回してスター集めまくってるクズ

2017-03-12

書き換える必要なくね?

大企業銀行で、昔から動いている基幹システムは、大抵メインフレームCOBOLの組み合わせである

それをここ十年くらい、リプレースx86サーバJavaという構成に変更することが多い。

しかし、ハード汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。

ぶっちゃけCOBOLCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは?と思うのだ。

その理由はこうだ。


COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。

勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOL文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである

そういうモノが既にある企業銀行文化において、当然発注側は担当者からお偉いさんまでCOBOLerフローチャート脳だし、新しいシステム設計でもそれを踏襲しようとする。

というか踏襲すること前提じゃないと設計書をレビューできない。

UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。

というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法設計書で処理を組み上げざるを得なくなる。


そうなると、実装フローチャート設計を基にコードを書くわけだが、こういう設計ハッカー文化で発展してきた言語(FortranC/C++Javaという流れと、PerlからPythonPHPというインタプリタ系の諸言語)との相性が最悪である

設計とは実装を楽にするために書くのに、これらの言語において、フローチャート設計は役に立たないどころか、邪魔しかない。

からFortranしかなかった頃から、本物のプログラマ達はフローチャートdisってきたわけである

ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である

しかし、「普通人達普通思考からはかけ離れ過ぎているという意味で、「普通人達普通仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。

…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLアセンブラ選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。


というわけで、自分COBOLからリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。

COBOLリプレースするのでない限りは。

2017-01-18

プログラミングって「得体がしれない」よな

プログラミングって、これから始めてみようっていうとき、なんだか「得体のしれない行為」っていう感覚がありませんか?

ぼく自身は、プログラムを書いてる側の人間で、いまでこそ少しはプログラミング本質的な難しさをわかってる気になってます。でもつい数年前までは、プログラミングは難しくはないけど得体がわからない、という感じでした。

そのへんのコードを組み合わせて動くものはできるけど、何がどうなっているのかは知らんし、ググって分からないものはできない、という方向で、「プログラミングは難しい」と思ってました。

最近になって、プログラミング義務教育必修化の話題とか、コピペプログラマー話題とかを目にするたびに、かつて自分プログラミングに対して抱いていた「得体のしれない行為」という感覚が思い出されてしまい、少しざわざわした気持ちになったので、ちょっとここに書きなぐらせてください。

だいたいが個人的な話なので、そういうのがうっとうしい人は無視してください。

ぼくが世の中にパソコンという道具があることを知ったのは、たぶん中学生ときです。30年くらい前。当時、電気屋の売り場ではけっこうな床面積を使ってワープロ文章入力する専用マシン)が陳列されてました。文章を書くのは好きだったけど、字を書くのが死ぬほどめんどくさかった自分は、ワープロさえあれば自分小説とか書くのになあと思いながら指をくわえて電気屋の店内をうろうろしてました。しかし、ファミコンすら買ってもらえなかった家計ではワープロなんぞ買ってもらえるわけもありません。そのうち巡回してた電気からワープロが消え、それに代わってパソコンのコーナーが広がっていきました。このパソコンというのは、よくわからないけどワープロとして使えるっぽいし、どうやらファミコンを持っていない僕にもゲームができるらしい、おれに必要なのはこれだ、というわけで、中学生だった自分パソコンという存在に興味を抱くようになったのでした。

はいえ、だからといってパソコンを買ってもらえるような家計ではなかったわけなので、カタログを熱心に眺めるだけの毎日が続きました。その当時の自分にとって、パソコンが欲しいといったら、それはNECを買うかエプソンを買うかという選択でした。冨士通からパソコンが出ていることは知りませんでした。マッキントッシュっていうやつもあって、このPerformaっていうやつはなぜか安いとか、よくわからないけどシャープとかソニー独自パソコンを作っているぞとか、そういう情報パソコンに対する認識のすべてでした。当時の自分にとってのパソコンは、電気メーカーから発売されている商品一種であり、ラジカセとかテレビと同列の存在でした。

なんでこんな話がプログラミングにつながるかというと、ひょっとして自分プログラミングにずっと感じていた「得体のしれなさ」の源泉の一つは、こんなふうにパソコン電化製品として見ていた当時の感覚の延長だったのかもなあと思ってるからです。

ラジカセなら、CDだのテープだのを入れて再生タンを押せば、そのハードウェア機能物理的に体感できます。それに対してパソコンは、プログラミングちょっとやってみても、その行為と、そのハードウェアとが、感覚的に結びつきません。もちろん、プログラミングというのは、物理的なデバイスに結びつけて考えなければできない行為ではありません。しかし、パソコンを「カタログ商品」として見るところから入ってるばかりに、そこでやるプログラミングという行為ハードウェアとの結びつきが見えにくい状態に、なんとなく居心地の悪さを感じていたように思うのです。

もし自分スタート地点が、パソコンを使って文筆やゲームをするところだったら、パソコンは文筆やゲームのための箱だったでしょう。その後でプログラミングを始めていたなら、プログラミングという行為を、文筆やゲームに関連した創造的な活動として学べたかもしれません。

ところが実際には、自分はつい数年前まで、パソコンという電化製品に対する漠然とした行為としてプログラミングを捉えてた気がします。

プログラミングを始めたのは、高校生になって誰も使わないFM77が部室に置いてあったので立ち上げてみたらF-BASICインタプリタが起動したからでした。とくに何をプログラミングすればいいかもわからなかったので、教科書雑誌コードを転記したり、ループで線画を書いたりして遊んでいました。大学に入ってからも、授業でFORTRANとかLispをやらされたけど、基本的自分目的をもってプログラミングするのは数値計算くらいのものでした。そのころになると、本で情報を探して(まだインターネット検索は使い物にならなかった)適当コードをつなぎ合わせるのがプログラミングだと思ってました。そんなん面白くないなあ、とも思ってました。

この感覚、完全に、いま揶揄されているコピペプログラマーのそれだったと思いますちょっと話はそれますが、ブロック遊びとか砂場遊びって、ほとんどの人はわりとコピペプログラミングと似たような感覚でやってるんじゃないでしょうか。パーツを勘で組み合わせたり、とにかく砂を盛っていったりすれば、家みたいなのができるよね、という感覚プログラミングは、自分にとってそれに近い作業でした。学生のころは、内心、自分にもパソコンサンプルコードさえあれば何かすごいものを作れるかもなあ、くらいに思っていたふしもあります

自分バカでした。パソコンがあるとかないとか、関係ないのです。パソコンさえあれば、なんて思う者に、本当のプログラミングがわかるはずがありません。

そんなこんなで、自分はまともにプログラミング経験しないまま社会人になったわけですが、幸いにもプログラミングに対するこの感覚は、仕事パソコンを日々使うようになってから徐々に変わっていきました。

具体的には、パソコンが、自分の中で「カタログ商品から武器」へと変わりました。それと同時に、プログラミングという行為が、武器開発という位置づけになりました。

武器というのは言い過ぎだとしても、ちょっとしたプログラミングは確かに業務上課題を打開しました。それなりに計算機科学教科書を読んで勉強をしたこともあって、いつのまにかプログラミングに対する「得体のしれなさ」も解消してました。

結局のところ、自分にとっては、プログラミングという行為の「得体のしれなさ」から解放されるまでにずいぶん長い時間必要だったことになります自分がそうだったからといって他人もそうだとは限らないですが、たとえば小学校で形だけプログラミングを教わっても、分かるとかわからないとか、好きとか嫌いとか以前に、なんかモヤモヤした気持ちになるだけの子もも少なくないんだろうなあ。それは不憫だなあ。

かといって、自分がいまプログラミングで少しは戦えてるのは、そのむかしパソコンに憧れがあって、得体がしれないなりにプログラミングをする機会が若いときたまたまあったからでもあるので、そういう機会になるなら小学校で形だけでも教えるほうがいいのかなあとも思います

オチがないので、このへんで。

2016-09-03

http://anond.hatelabo.jp/20160902031012

http://anond.hatelabo.jp/20160902031012

はてブ批判してる人たちよりよほど志のある学生さんだと思うので、いろいろ書いてみますおっさんのたわ言ではありますが、元記事の人にすこしでもヒントになればと思って。

大学に行っても実用的なソフトウェアを書けるようにはならない

実務の話!! 実際に「IT系のおしごと」というのがやってるような話で、特にコーディングに直接絡んでくるようなもの

技術実態みたいなやつ。そういうのは学校で教わらないんですよね。

まず、日本大学勉強しても実用的なソフトウェアが書けるようにはなりません。どういうことかというと、「情報系の大学に行けば○○が作れるようになる!」という世間一般の期待と、実際に大学で教えている内容には大きなギャップがあるということです。

これは大学が悪いのではなく、大学はそもそもそういうものであって、それが世間認知されてないというだけです。

具体的に挙げてみましょう。

大学で教えてる内容ってこんな感じなので、ゲームアプリサービスを作ることが目的の人から見ると、役に立たない内容にしか見えませんし、実際たいして役に立ちません。その証拠に、大学情報学科を出ていないのにゲームiOSアプリWebサービスを作っている人はゴマンといるし、逆に日本大学先生ゲームiOSアプリWebサービスを作れる人はほとんどいません。

日本大学先生実用的なアプリサービスを作った経験がない

これは重要ことなのでもう一度書きますが、日本大学先生ゲームアプリサービスを作れる人はほとんどいません。大学先生が得意なのはプログラムを書くことではなく論文を書くことです。論文のためにプログラムを書くことはありますが、あくまでおまけです。

そのため、大学勉強してもゲームアプリサービスが作れるようにはなりません。だって教えている側の先生が、ゲームアプリサービスを作ったこともなければ、作り方も知らないんだから

そういう経験のない人たちばかりですよ、日本大学先生って。そんな人たちの授業を受けて、アプリサービスが作れるようになると思うほうがおかしいでしょう。

ためしに、先生方のTwitterアカウント名でGithub検索してみてください。いまどきGithubアカウントがないとか、あったとしてもTestCaseすらないコードとか、そんなものばかりです。「研究内容をライバルに知られるわけにはいかないかGithubは使わない」という言い訳する人がいそう。けど、本当はGitが使えないだけでしょ?

あるいは、先生方の個人ページや研究室の紹介ページを開いて、HTMLソースを見てみてください。doctype宣言がないとか、viewportの指定がないとか、Pタグの中にULタグを使ってるとか、そんなのばかりです。HTMLすらろくに書けない人が、Webアプリを作れると思いますか?きっとXSSCSRFも知らないですよ。

ですので、そういうことを勉強したいなら、ベンチャーIT系企業に入るべきです。大学でそういうことを勉強しようとしても、教えられる人がいないから無理。
(「大学はそんなことを教える場所ではない!」と怒る人いると思うけど、教えられる先生がいないという事実ごまかすために怒ってるだけだから。)

ジャンルが違う

はいっても、大学先生プログラムがいっさい書けないというわけではないです。彼らが得意なのはコンパイラインタプリタOSやソルバを作ることです。これらも実用的なソフトウェアと言えなくはありませんが、ゲームアプリサービスとはジャンルが大きく違います

そのため、大学情報学科に進めばコンパイラOS機械学習ライブラリを書けるようにはなるかもしれませんが、それはゲームアプリサービスではないので、繰り返しになりますがそれらを作りたい人には大学は向きません。

大学で教えている内容ってムダなのか

じゃあ大学で授業を受けるのってムダなのかというと、必ずしもそうではないです。

大学で教えている内容って、ゲームiOSアプリWebサービスが一通り作れるようになってから、その先を目指すときになって初めて必要になることが多いです。たとえば、

こういうときになって、初めて大学で教わった内容が生きてきます。逆にいうと、そういう状況にならないと、大学で教わった内容は生きてこないと言えます。(情報系の学科で学んでいるなら、ライブラリ言語OSを「使う人」ではなく「作る人」にぜひともなってほしいですね。)

元増田に進めたい進路

元増田は、社会に役立つ実用的なソフトウェアを作りたいようです。しかし残念なことに、大学が教えている内容はその目的には合致していないことを説明しました。

こういう事情なので、元増田には大学ドロップアウトしてIT系会社入社することをお勧めします。ドロップアウトが難しいなら、インターンバイトでなんとしても入り込むことです。

入るべき会社は、教育に力を入れている会社です。20人未満の小さな会社では教育に力を入れている余裕はないので、小さな会社はやめたほうがいいです。簡単にぐぐってみたところ、はてなPixivクックパッドDeNAドワンゴ教育制度確立しているようです(違ってたらごめん)。そういった会社に入ったほうが、大学の授業を受けるよりも、元増田目的にかなうのは間違いありません。

そして何年か働いて、iOSアプリWebサービスが一通り作れるようになったら、大学に入り直すことです。これはとても効果的なので、元増田には強くお勧めします。

上で説明したように、大学というところは、ゲームアプリサービスの作り方は教えてくれず、それらが作れるようになって初めて役に立つことを教えてくれます。そのため、元増田IT系会社に入ってアプリサービスの作り方を勉強し、それらが作れるようになってから再度大学の門をたたくのが、いちばん効率的です。

なお繰り返しますが、入るべき会社は「教育に力を入れている会社」です。今のIT系企業では、インターン生を「格安で使えるバイト君」としか見なしていない会社が多すぎます。そういう会社は、コストが掛かることはいやがるので、教育もろくにはしてくれません。逆に教育に力を入れている会社では、インターン制度を「将来の戦力を選別する期間」と見なしています

残念ながら、そういう会社東京に集中しているようです。例外京都はてなくらいでしょうか。地方大学生にとってはつらい現実なので、はてなPixivドワンゴ地方でのインターン開催をお願いします。あとレベル5は九大と九工大学生を鍛えてあげてください。

余談ですが、学生さんにひとこと:

インターンバイトで潜り込む先の会社を選ぶときは、就活と同じような時間をかけて選んでください。バイトからとかインターンからという軽い気持ち会社を選ぶ大学生が多いから、それを食い物にしている悪質経営者があとを立ちません。インターン生が「格安学生バイト」として使われている現状を是正するために、学生のほうでも注意してください。

大学で授業を受けなくても独学で効率的勉強する方法

ドロップアウトを進めた手前、書こうと思ったけど、長すぎるのでやめた。

リツイートが100超えたら書く。

2016-07-01

http://anond.hatelabo.jp/20160701171425

CPUは数値の機械語しか実行できんのだからインタプリタだろうがJITだろうが最終的には全部機械語だろ。

そのインタプリタJITを書くのも人間なんだから腕がよければ実行される機械語は早いし駄目なら遅いだけだろ。

エキスパートアセンブリ言語で書く場合はCより速くなることはママあります

って、科学技術計算用なんかの一部処理をゴリゴリやるならまあそうだろうけど、どっちが早いか比べるとか中二か。

2015-06-16

文科省プログラミング教育に関する報告書は何が間違っているのか

概念

二種類のレイヤが混ざってる。あと、スクリプト言語レイヤは要らない。例は突っ込みどころが多すぎるので触れない。

アプリケーション

コンピュータ上で動作するもの全て、システム周りの低レベルプログラムを含めてアプリケーションとして括るのはちょっと乱暴。

何をアプリケーションと呼ぶかはコンテキストによる。

OSを書いてる人間から見ればユーザープロセスは全部アプリケーションだし、twitterから見たらAPIを叩くものは全てアプリケーションだろう。

基本的には外から持ってきたソフトウェア基盤の上に作るもの総称してアプリケーションと呼ぶのがより実態に近いと思う。

スクリプト言語

だいたい合ってる。ただ、高級言語より上にあるのは変。スクリプト言語高級言語に含まれる。

高級言語

だいたい合ってるが、自然言語云々は余計。例えばS式自然言語アナロジーではない。単に比較問題抽象度が高いかどうかだけの区別しかない。

ミドルウェアライブラリー

OS云々は関係ない。OSミドルウェアライブラリーは使う。一般には自分が書いてないソフトウェアコードライブラリと呼び、何かと比較してより低いレイヤにあるライブラリミドルウェアと呼ぶ。

機械語

問題ない

コンパイラインタプリタ

ここが一番まずい。まず、中間コードコンパイラが内部的に処理の段階を分ける仕組みであって、出力ではない。

また、インタプリタソース言語逐次実行するのではなく、正確には中間コード抽象構文木そのもを含む)を逐次実行するものだ。

他のプログラムで実行するコードを生成するものコンパイラ自分自身コードを実行するのがインタプリタ、という区分けがわかりやすいと思う。

ただ、現実的にはインタプリタは内部的にコンパイラを持つし、コンパイラ最適化過程では内部的にインタプリタを使う。

昨今はLLVMみたいに、コンパイラなのかインタプリタなのかコンテキストによって変わるものもあるので、正直区別しても意味がないと思うけど。

結論

この文書には問題がある。そうだな、直るのを待とうか。そんなことより自分コード心配をするんだ!

2014-12-02

僕はもうプログラミングしなくていいんだ

大学回生の夏、下宿の扉に「出入禁止」とチョークで大書し、親を呼ばれて精神病院に連れて行かれた。

 

パソコンを買ってもらったのは小学三年生の冬だった。今でも覚えている。1996年12月2日のことだ。Windows95発売で世間は揺れていた。インターネット回線がうちに来たのは翌97年の1月、これはそこそこ早い導入だったと思う。さらに翌々年の99年にはケーブルテレビ常時接続になった。親には先見の明があったが、しかしパソコンには詳しくなかった。PC-8001も確かそうだ。親はこれが次世代の必需品になると確信して買っていたが、買った一方で使い道が分からなくてオブジェとして放置していた。親はPC-8001パソコンだと言っていたけれど、僕にとってパソコンはおっきなテレビが標準で付属しているものだったし、マウスもなかったので、それがパソコンだとは到底思えなかった。でも親は言った。今度来るのは違うんだ、オフィスも入っているパソコンなんだ。僕は聞いた。一太郎っていうやつは入ってないの?テレビで言ってたよ、と。親は答えた。オフィスってのは一太郎より機能がスゴイんだよ。僕はへぇ、とだけ言った。どちらにせよペイントは入っているだろう。ペイントなら親戚の家で使わせてもらったことがある。パソコンお絵かきができるのだ。マウスをカチカチして、キーボードをカチャカチャするのだけが楽しみで、納品の日を一週間ひたすら待った。その頃、漢字宿題提出が滞っていて、そのままでは居残りでさせられることになっていた。僕は久々に奮起した。いつもは踏み倒していた宿題を、全部一気に終わらせた。家に帰るとパソコン電気屋さんの手で設置されつつあった。今は亡き、ニノミヤで買われたパソコンであった。

 

97年にインターネットを始めた。一日一時間まで。実のところ電話代の問題ではなく、一時間ほど使うとブルースクリーンが発生するからだった。一日一時間以上動かすと壊れるから。PC-8001キッチリ買った親なのに、それぐらいの(?)ITリテラシーであった。ただ別にそれを責めるつもりはない。僕はすぐにアングラサイトに入り浸った。人に飢えていたのだ。普通のチャットには人がいない。テレホタイムにならないと、誰一人ログイン氏亡いのだ。でも、アングラサイトなら四六時中書き込みがある。僕は思う存分厨房行為を楽しんだ。煽り騙りなんかは、小学生がやっても大人がやっても大して変わらないものだ。You is a big fool manという文句をリアルタイムで目にした人は、多くても数百人だっただろう。何千、何万のツイッタラーが押し寄せ、ブクマが1000以上付くような今の炎上とはほど遠い暢気さだ。当時の匿名掲示板とはそういうものだった。誰一人本気で投稿しなかったし、しかし誰一人面白くない書き込みをしようとはしなかった。トイレでもネタを考え、思いつけばすぐに投稿し、ワラタが付くのを待ち続ける。あやしいあめぞうあやしい、2ch。人の多いところから人の多いところへ。ワラタが多くもらえる場所へ。気づいたらインパクが終わっていた。

 

その一方で僕は中高一貫私立校入学していた。高校受験がないことから、ネット依存さらに加速した。しかし2000年を境にアングラ掲示板は衰退の一途をたどり、2ch一強時代を迎えていた。1ch.tvボコったりするなど楽しいネタがないわけではなかったが、匿名掲示板ネタの宝庫と言うより、本気でちゃんと議論することもできる場所になり始めていた。ちゃんと議論しようとしたらすぐさま崩しにかかるのが2ch隆盛以前の匿名掲示板文化であったが、2003年頃を境にはっきりと潮目が変わっていったように思う。まあその辺はどうでもいい。アングラと非アングラの境目は消え始めていた。

 

その狭間に、僕は生きていた。

 

自分掲示板を設置することにした。けれども何をして良いのか分からない。CGIレスキューに救援要請をして本も買った。Perlだ。Perlしかない。しかしPerlがどうして動いているのかは、全く分からなかった。何十行、何百行もの文字の羅列が、どこでどうなって、掲示板になるのか。インタプリタコンパイラ?訳が分からない。そもそもCPUがどうやって動いているのかも分からない。僕にとってプログラムとは、セットアップウィザードCD-ROMをギュンギュン言わせながらインストールするものであって、掲示板というものは、Teacupで借りるものだったからだ。でもどうやらそうじゃないらしい。コンピューター翻訳するのがコンパイラです。さっそくコンパイラを使ってみましょう……

 

お手上げだった。

 

コンパイラがないのだ。コマンドプロンプトにはない。Linuxを入れる?使い方が分からない。Vine Linux初心者お勧めだった頃の話だ。ボケッとしててもGNomeぐらいは動かせる程度には簡単になっていたが、そこからターミナルを開いてgccでコンパイルするなんて想像も付かないことだった。Hello, Worldはなんとか表示できても、それをGUIで動かす方法が分からない。僕はデスクトップに「Hello, World」のポップアップウインドウを表示させたかったのに。全然訳が分からなかった。

 

プログラムが動いている方法を知らなければならない。プログラミングを学ばなければいけない。しかし全体像を把握するにはあまりにもほど遠い……。絶望感が支配し始めていた。Hello, Worldはできたけれど、その先が全くわからない。どの参考書を読んでも分からない。ググってもググっても分からない。ポインタで躓く初心者が多いです!……どの本にも書いてあったけれど、僕はポインタどころか、変数の種類がたくさんあるところでお手上げだった。int?char?long???意味不明文字列が並び続ける。メモリメモリって、挿したらいいんじゃないの?確保?fopen????どんなプログラミング言語も、何一つ分からなかった。その頃インターネットは加速し始めていた。切るのが当たり前だったJavascriptが復権し、Ajaxと名を変えてやってきた。掲示板スクリプトもどんどん高機能化し、もはやPerlを知るだけでは何一つできないようになってしまった。苦痛の日々が始まった。どの言語も、全く分からなかった。分からなければならないという焦りが募っていった。

 

あるとき、一年間ほど、とりあえずお手上げのままにしておくことにした。大学受験が迫ってきたからだった。そして案外あっけなくそれは終わった。僕は某大学情報科学科に入った。

 

教授ガイダンスで説明したとおり、情報科学科のプログラミング演習はそれほど多いものではなかった。一回生の時なんか、キーボードを目で追って人差し指で打っている人もいるぐらいだった。学校の授業はアテにならない。そして大学受験でいったん引っ込んだ、とにかく十代でなにかしないと、という焦りが復活してきた。

 

大学キャンパスは広すぎた。何をして良いのか全く分からなかった。授業内容はひどくつまらなく、何が役に立つのかも分からず、ただただ苦痛で、キャンパスサークル活動に打ち込んで楽しく過ごせるほど社交的ではなく、かといってオタク集団に混じる勇気も無く、とにかく、とにかくここで四年間、四年間で何かしないと、何かしないと就職に間に合わない、大学院進学に間に合わない、十代のうちに何か大きな事を成し遂げなければならない。日々研鑽に励み、日々プログラミングスキルを磨き、日々勉強会に参加し、日々コードを書き、日々環境設定をし、日々本を読み、そして日々コードを美しく書かなければならない、そういう焦りだけがどんどん加速していった。大学生協で片っ端からプログラミングの本を買った。ド初心者向けのPerl本から、美しいコードは何か、みたいな本まで。でも、どれ一つ、僕のスキル向上には役に立たなかった。プログラミングスキルの向上=自分自身の地位=生活の保障、と思っていた自分には、悪夢のような現実だった。

 

とにかくインターネットと一緒に歩んできた僕にとって、ITスキルはすなわち力であり、むしろITスキル以外は何の価値も持たないもの、と思えるほど脅迫的な観念にとらわれていた。入ってくる情報さらに増えていった。Cができるのは当たり前、Ruby on Railsがアツい、Java、PHPはもちろんできるよね、MySQLは当然使えるよね、もちろんHaskellSchemeObjective-Cもやらなきゃね……何一つできないのに、習得すべき言語だけがどんどん増えていく。加えて美しいコードを書け!という文句が飛んでくる。クソッタレが。何が美しいコードじゃ。goto使ってもいいだろ。好きなだけ使わせろクソッタレが。全部getsで書いてやる。クソが。アルゴリズムアルゴリズム勉強会勉強会ビューティフルコードMacMacMacジョブズジョブズジョブズ……???????????????

 

それでもなんとか、そう、なんとかなった。友達が優秀だったのだ。僕には到底できないような、きれいに整理されたコードを書く人だった。聞けば在学中から外注プログラマをやっていて、それなりに稼いでいたのだという。性格ちょっとアレで、風俗に勇気を出して行こうかどうしようか迷ったけどその金でオナホ買ってシコってオナホを床に叩きつけたみたいなヤツだったけれど、そいつからもらったコードを、わざと汚く成形し、変数名も汚らしくし、提出し、なんとかなった。結局自分最初から最後までプログラムを作ることはできなかった。丸々コピペはしなかったけれど、コピペがなければ卒業は無理だっただろう。

そうして三回生の終わり、試験がどっと押し寄せてきた。一月のことだった。機械学習と……なんだっけ?そういう感じの試験が、2月の初日、行われることになった。三回生はただでさえ試験が多かったが、その大トリこそが機械学習だったのだ。

 

僕は試験放棄した。

 

まるで意味が分からなかった。推論、それは分かる、機械学習機械学習??やっていることは数式だしベイズがどうの……まるで分からない。泣きそうだった。三年間必死こいて勉強したり勉強会に行ったりプログラミングスキルを上げようとしたり本を読んだり色々したのに、何一つ得るものは無かったのだ。僕はあやしいわーるどオマンコ連呼していた頃から、何一つ成長出来なかったのだ。そしてそれは、間違いなく、疑いようがなく、自分のせいだった。自分頭が悪いせいで。自分の勉強不足のせいで。自分のせいで……コンピュータとともに、十何年も育っていた僕にとって、コンピュータに関するスキルこそが、全ての力の基準だったのに、その全てを否定されたような気持ちだった。プログラミングができなければ、死ぬだって友達はみんな就職して、SEになったりSIerで働いたりネットワーク管理者になったりしてるのに、僕はなんで、こんなところに。そいつらに取り残されるのに。みんな勉強会に出てMacを持ち寄ってハッカソンしてるのに。泊まり込みでプログラミングしたりしてるのに。なんで僕は、fgetsすらマトモに使えず、getsとscanfだけであなた名前を入力してください オマンコ オマンコさん、こんにちは!みたいなプログラムしか書けないんだ。

 

大学回生になった。研究室を選択する必要があったがしなかった。しないでは困るとのことで、適当に書いたらその一番上に配属された。でも一切研究せず、下宿に引きこもって何もしないをした。今日輪講はここまで進みました!という報告が毎週回ってくるが、まるで研究室では日本語でなくアラビア語公用語になっているのではないかと思えるぐらいの光景だった。この頃、近所の人の証言によれば、言動がおかしく、訪ねてきた人に暴言で返し、殺す殺すなどの声が聞こえ、時折モノを投げつける音が聞こえたりしたそうだ。まあよく知らない。僕は普通に何もせずぼんやりネットを見ていただけのような気がするけど。

 

それからしばらく経った。

 

結局僕は中退した。そして別の大学に入り直した。今度は、工学じゃない別の場所に。みんなキーボードの文字を読みながら指先でキーを叩いている。安心する光景だった。僕らはプログラミングを習わなくてもいい。これから習う必要も無い。タッチタイピングだって、できるに超したことはないだろうけど、できなくてもいい。ただ、そこにある便利なモノを使えば良いだけなのだChromeを使っていて、うっかり開発者向けコンソールを開いてしまっても、何も分からなかったことにして閉じて良いのだ。きっとマクロを書けば、楽ちんに勝手にやってくれるような作業を、人の手で何度もやる。それでいいんだ。マクロを考えるために必死になる必要なんか無い。マウス右クリックコピーペースト。それでいいのだ。キーバインドすら覚えなくて良い。メモ帳を使ってもいい。viやEmacsキーバインドを覚えなくてもいい。マウスも使えないようなエディタと格闘する必要は無い。Macを買っても、XCodeportsを入れる必要は無い。iTunesiPhoneを同期させて、音楽を聴くだけでいいんだ。

 

僕はもうプログラミングしないでいいんだ。

 

それが分かったとき、全てから解放されたような気がした。僕を苦しめ続けたプログラミングというものは消えてなくなった。パソコンでやる作業は、昔と一緒、匿名掲示板オマンコと書き込むだけだ。それ以上のことをしなくてもいいんだ。勉強会に出てハッカソンする必要は無いんだ。プログラミングスキルを錬磨しないと死ぬなんてのはウソだったんだ。美しいコードを書かないと天罰が下るというのはウソだったんだ。毎日毎日はてブホッテントリを見てると、プログラミングマスターしなければならないこと、何何する方法開発者必須スキル、便利ツール、Macでのアプリ開発、セキュリティ、通信、データベース勉強会ハッカソン、そういうもので溢れている。苦しくないのか不思議で仕方ない。もちろんプログラミングをしていて楽しい人もいるんだろう。けれど、僕みたいに、プログラミングという行為が苦痛で苦痛で苦痛でしかない人もいる。たとえ1000回の同じ操作でも、人力でやる方がマクロを書くよりも楽だという人も、ここに存在するのだ。そしてそのような人の存在も当たり前に肯定されるのだ。みんな苦しまなくて良いんだ。誰かが勝手にやってくれればいい。できる人にお金を渡して、僕らはそれを享受するだけで良いのだ。ここでプログラミングという言葉を連呼したけれど、コーディングという言葉との違いとか、そういうのを気にするような人とおつきあいする必要は無いのだ。いずれプログラミング必須スキルになるとか言われて何年も何年も苦しみ続けてきた。けれど、そんなことをする必要は無いんだ。

 

さようなら。僕はもうプログラミングしません。

 

 

 

 

それでぶっちゃけここからが本番なんだが、十代でなんとかしないと、という焦りはこないだの青木君の小四なりすましの話に似ている。僕もそうだった。僕らの世代だと登大遊氏なんかが結構輝いてて、ああいう感じにならなきゃ、と思っていた節はある。十代の時になにか成し遂げないといけない、そのためには誰かに認めてもらわなければならないという焦りは、どれくらいの「大人」に理解してもらえることなのだろうか?誰かの承認を得たいという承認欲求を、同じ世代の誰かを使って満たすことができず、むしろ同じ世代の誰かを一緒に引き連れて、承認欲求を満たしてくれる「教祖」にすがりつく。NPOの大学生が「承認」を欲し、政治家が「承認」を与えているのだ。AO入試用の作文?図?みたいなものも見かけたが、「私はリーダーシップがあります!」とか実にくだらないことしか書いていない。しかしそういうものでさえ、学生団体とやらは「承認」してくれる。結局、オウム真理教が丸ごと開けたポジションに、バラックが建ち並び闇市が行われていて、コミュニケーションで自然と得られるはずの承認欲求が、法外な札束で取引されている、そんな感じのような気がする。

 

意外にブクマが増えていた。PC-8001は俺が産まれる前に買われたもので、ずっとオブジェだったのだ。動くかどうかもわからない。テレビに接続するコードがなかったから。

2014-01-23

http://anond.hatelabo.jp/20140123142229

エディタで括弧の対応とらないとろくに読めない記号の羅列。

プログラミング言語」なんて笑わせるわ。

使ってるのは頭ん中にインタプリタ内蔵されてる変態

2013-05-21

http://anond.hatelabo.jp/20130521211635

俺の例で言えば、親が使ってるパソコンが転がっていて、プログラムコマンドレファレンスが転がっていて

当時はインタプリタだったから、コマンド打ち込んだらそのとおり動いて

後は勝手にいろんなプログラム組んで遊んでたよ。

初歩のプログラム組むのに、マニュアル以外読んでない。

つか、俺の当時はプログラムはまだマイナーで今みたいに、ネットもなかったし、それ以外無かった。

小学生だったから、プログラムの本も買ってもらえなかったからな。

 

教えるも何も、教えてくれる人がいないし、今みたいに使いやすくもないパソコンプログラム組めたし

そもそも、こども科学館とかでのルートパスワードも、普通に 子供から安心して目の前で打つから覚えて知ってたし。

そんなもんだよ。デジタルネイティブというのは。

 

たとえば、テトリス作るのに、テトリスの作り方を教えて貰う必要がない。自分アルゴリズムを考えて作り出せる。それが、デジタルネイティブ

生まれた時からデジタルがあったというより、生まれた時にあったデジタルに、母国語と同じレベルで理解して使えるネイティブな才能の事だと思ってる。

 

言いたいことはわかるけど、教えられないとパソコンが使えないというのは、わかるけど。もう、そこに壁がある。

使いやすいから使えるのではなく、自分の腕と同じような感覚で使えるのがデジタルネイティブ。 ネイティブなんだから

全員がデジタルネイティブじゃないという主張はその通りで、飛び級しろ わけないともはや無理なのは周知の事実では有ると思うよ。

お互い 混ぜられると どっちも苦労すると思う。

2013-05-14

プログラミング大好き男に「どの言語が好き?」と訊ねられたとき、女はどう答えたらいいの?

あ、まず前提として、

貴女プログラミング大好き男を夢中にさせることが、

はたして貴女幸福にするかどうか、それはまた別問題だけれど。

はいえ、プログラミング大好き男たちは玉石混交ながら、

IT系の超かしこい男なども多く、

多くっつーかIT系でないのにプログラミング大好き男っていうのは超かしこ学生まぁこれは有望株)か研究者系なんか、

あとはまったくかしこくもないクセに頭いいつもりして「Lispやってます(キリッ ハローワールドくらいですが」とか言っちゃうアホしかいないわけで、

したがって、釣り師たる女たちにとっては、

なかなかあなどれない釣り場です。

では、プログラミング大好き男に「どの言語が好き?」と訊ねられたとき

貴女は、どう答えれば理想的でしょう?

まず最初に、その男COBOLのようなタイプレガシーコード

あとはC/C++、そして(TechEdに参加するほどではないけれど)VisualBasicが大好きな、

そんなタイプ場合は、

貴女はかれの目を見て、微笑みとともに質問など無視して、こう言いましょう、

「わたしが、仕様書を作ってあげる♪」

これこそまさに必殺の答えです。

そこでプログラミング大好き男が、えへへ、とやにさがったならば、

貴女は、ひそかに、「コピペ量産しやすい技術的ポイントを抑えた仕様書」あたりを

ひそかに練習しておきましょう。これで成功まちがいなしです。

しかし、ここでは、もう少しハイブロウな(?)いわゆるプログラミング好きの男の

落とし方をお伝えしましょう。

この場合貴女は、こう答えましょう、

「わたしは、JVM上のScalaが好き。

型推論もあるしラムダ式クロージャスクリプト言語みたいに書けるの、豊富組み込みのコレクションメソッドはいつも便利だし、

XMLリテラルCaseクラスによるパターンマッチもTraitベースMixi-inも、大好き♪」

もしも貴女がそう答えたならば、

その瞬間、プログラミング大好き男の目はきらりと輝き、

かれの貴女への恋心は、

20%増量になるでしょう。

なぜって、Scalaは、

ちょっぴりお洒落Ruby風味に記述できて、

Maybeモナド差し込んで、

コンパイルは遅いながらも、そこがまた

ちょっぴりメモリを多く積めばいい富豪プログラミングみたいなふんいきをかもしだしていて。

しか関数型言語としての不変変数・不変Listを実装して

質高くふるまっていて、なおかつ、

JVM上で動くくせにJavaが「やるやる」と言ったまま実装してなかったラムダ式と仮想拡張メソッド型推論を実装した功績もあって。

したがってScalaこそは、

本来なんの接点もないまったく縁もゆかりもない別々の世界に生きている、

インタプリタ言語大好きな綺麗系OLと、玉もあれば石も混じっている、そんなプログラミング大好き男たちが、

この世界で唯一(いいえ、JVM系列のJRubyClojure と並んで唯三)遭遇しうる場所です。


では、参考までに、危険な回答を挙げておきましょう。

プログラミング大好き男に「どの言語が好き?」と訊ねられたとき

貴女がこう答えたとしましょう、

MicrosoftVisual Basic for Applicationが好き♪ 週3回は Excelコーディングするの。」

その瞬間、プログラミング大好き男の貴女への恋心は消えます、

なるほどMicrosoftは、世界最大のOS供給メーカー

特にOfficeは平凡ながら、ま、無難にまとめてあるものの、

しかし、「新UIのリボンUI!」「メトロUI対応!」とかなんとか無意味な自慢を吹聴し、

VBAはさらプログラミングについての謬見を撒き散らした罪がありますからプログラミング大好き男にとっては天敵なんです。

ティーガー戦車乗りのオットー・カリウスは「ティーガー乗りなら誰でも片側の履帯がはずれ僚車に牽引されて帰ってきた経験を持つはずだ」 って言ったけど

社内SESIerなら誰でもクソみたいな前任者が書いたクソみたいなExcel-VBAコードを直した経験があるはずなんです。

また、もしも貴女が「PHPが大好き♪ あたしが書いたPHPのWebサイトが、さくらサーバに7件あるよ♪」

と答えたとしても、同様の効果をもたらすでしょう、

なぜって、PHPは、1990年代にはWeb系を目指す人にとっては簡単で要件を満たすWebサイトが簡単に作れる輝きの道だったものの、

しかし2000年代うそうからセキュリティ関係の問題で転落し、

いまや、あの貧弱な言語能力では、Rubyの魅力に遥かに及びません。

(注1)

またもしもたとえあなたプログラミング言語が大好きで、

「わたし、.NET FrameworkのC#が好き、フォームアプリでも書くけど、

最高に好きなのはASP.net♪ SQLServer連携も、ajax control toolkitもすっごくおいしいの。」

と、答えたとしたらどうでしょう

なるほど、貴女の趣味は高く、

しか.NET Frameworkは、C# が cool であるのみならず、

.NET Framework上で動く F# や IronPythonIronRubyマネーJScriptも最高においしいんですけれど、

しかし、貴女の答えを聞いて、プログラミング大好き男はきっとおもうでしょう、

(なんだよ、MS信者な女だな、カネかかりそう)って。

(注2)

貴女が、プログラミングが大好きで、言語の名を挙げるにしても、

たとえば、JavaScript(node.js)ならば安心でしょう、

なぜならば、JavaScriptは、かけだしのプログラミング初心者にもマニアにもともに愛されるめずらしい言語で、

貴女がその名前を挙げても必ずしも、(jQueryがやっとの初心者と思われることはあっても)あなたプログラミング言語おた宣言をしているとは受け取られないでしょう。

しろへぇ。ちゃんとprototypeは使ってる?」と聞かれたら「当たり前じゃない。むしろnode.jsでいいMVCフレームワークが分からないんだけど…」と話を振ってみましょう。

男は嬉々として、30個くらいのnode.jsフレームワークを教えてくれることでしょう。(まぁどれもどれで帯に短し襷に長しなんですが)

あるいはRighno上で動かしたコードをnodeへ移植する話とか、CoffeeScript、甚だしきはClojureScriptを振ってみてもいいかもしれません。

しかし、たとえば、世界が(つーか竹内先生ポール・グレアムが)誇る超絶関数型言語の名作、Common Lispにせよ、

selfと書きまくることと海外で使われてることに定評のあるPythonにせよ、

バージョンアップごとに言語仕様が変わり、かなり素敵なものではあるもののobsolatedな罠にはまりやすRubyにせよ、

まったく読めない$_だらけで頭悪い仕様リセットしてPerl6にする(そしてまた全く読めない)Perlにせよ、

気さくなクジラ飛行机さんがふるまう素敵においしい日本語プログラミング言語ひまわりなでしこにせよ、

基地外トリッキー言語の代表BrainFxck・Glass・Missa・WhiteSpaceにせよ、

そういう言語名前をいきなり挙げるのは、ちょっぴり微妙。

ましてや貴女が、「Haskellが大好き♪ わたし、プロジェクトオイラーの問題もうほとんどHaskellで、解いちゃった♪」

と答えたならば、どうでしょう

これはかなり博打な答え方で、

なるほど、Haskellは、純粋関数型でありつつも副作用のある操作が行える超絶名言語ゆえ、

あなたがそう答えた瞬間、プログラミング大好き男がいきなり超笑顔になって、

へぇ、やっぱりHaskellなら大抵の問題は4行以内くらいで解いちゃった?」とか言いながら

鼻の下がだら~んと伸びちゃう可能性もあるにはありますが、

しかし、逆に、(なんだよ、この女、プログラミングおたくかよ)とおもわれて、どん引きされる可能性もまた大です、

なぜって、必ずしもプログラミング大好き男がプログラミング大好き女を好きになるとは、限らないですから

しかも、この答えには、もうひとつ問題があって、

男たちは、女を導き高みへ引き上げてあげることが大好きゆえ、

もしも貴女が、「Haskellが大好き♪」なんて言ってしまうと、

そこにはもはや、男が貴女圏論モナド教育する余地がまったく残されていません、

したがって貴女のその答えは、

プログラミング大好き男の貴女への夢を潰してしまうことに他なりません。

ま、ざっとそんな感じです、貴女の目にはプログラマーたちはバカでスケベで鈍感に見えるでしょうが

しかし、ああ見せて、プログラマープログラマーで繊細で、おざなりに扱われると傷つきやすく、ローカル変数名前一つにも気を使い、女と自分の将来に夢を持っています、

貴女の答え方ひとつで、プログラマー貴女への夢は大きくふくらみもすれば、

一瞬で、しぼんでしまいもするでしょう。


では、スキットを繰り返しましょう。

「わたしは、JVM上のScalaが好き。

型推論もあるしラムダ式クロージャスクリプト言語みたいに書けるの、豊富組み込みのコレクションメソッドはいつも便利だし、

XMLリテラルCaseクラスによるパターンマッチもTraitベースMixi-inも、大好き♪」

そして、その瞬間、プログラミング大好き男の目がらんらんと輝いたなら、

貴女はこう重ねましょう、

それからね、いま、わたしが使ってみたいWebアーキテクチャは、

Play Framework、素敵なリアルタイム嗜好のアーキテクチャって噂を聞いたから。

あなたのお暇なときがあったら、わたしをPlayへ連れてって♪」

これでもう完璧です。

PlayFrameworkと、Play(遊ぶ・じゃれる)のダブルミーニングでかれの股間も刺激しちゃえます。

そうなったらこっちのもの

デートの日には、ペアプロ用に Happy Hacking Keyboard をばっちり決めて、かわいい下着をつけて(注3)、

github.comの通販で売ってるoctcatのTシャツか、facebookの「いいね!ボタンがムネのところにあるTシャツ、 あるいは初音ミク(ないし彼のお気に入りアニメキャラ。北米ならMyLittlePonyで鉄板なんだけど)のコスプレを着てゆきましょう。

その日からプログラミング大好き男は貴女の虜になるでしょう。

では、釣り師としての貴女の、愛の幸運幸福をお祈りします!

注1:

(と、書いたもののPHPの現状をよく知りません。グローバル変数だらけになるのとか旧ASPみたいなもんなのかなぁ。count($array); とか書くのアホと思うがpythonも同じだった)

(あと、マジで機能とかTwitter連携とか診断メーカー的なのでもPHPで7つも作ってる女子居たら付き合いたい)

注2:

もっとも。objective-Cなんていう言語をやることに比べれば個人で行う程度なら金のかからない手法もなくはないのですが。

注3:

プログラマーにとっての「かわいい下着」と、女性にとっての「かわいい下着」の定義にずれがあるので注意。

半数くらいのプログラマーしましまぱんつが可愛いと思ってる気がするので、妙齢の女性が着用するには抵抗あると思うが、ボーダー柄のコットンショーツ(ただしキャラ絵のは除く)とか、

過度でないていどにフリルがついたものオススメ。また、色は、レッドだとプログラミング大好き男は引いてしまう(だってそれはコンパイルエラーときの色だ)ので、薄ピンクホワイト、薄ブルー、せめて黒(に差し色でピンクとか)あたりに留めたい。

補記:

 元ネタhttp://tabelog.com/tokyo/A1301/A130101/13002457/dtlrvwlst/3464106/

補記2:

  「プログラマー」か「プログラマ」かの問題については、特に意味は無いが前者を採用した。

補記3:

 言うまでも無いけど、ネタです。 

 また、COBOLとVB、C++ではまったくもって難易度が違うことも分かっています。後者になるほど圧倒的に難しい。

2012-01-22

凍ったニシキヘビと凍えた番人

言語disりが流行ってるようなので一つ

Pythonをかれこれ5年ほど使っているけれど、いい加減頭にきた。

大体頭に来るような内容というのは限られていて大体は

http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm

に書かれている事に近い。大事なところを引用すると

本当にPythonを殺し、メインのスクリプト言語となる望みを、あるいは何であれメインの言語となる望みを絶ったのは、永久凍土の問題なのだ。人々はいまだ埋め込みインタプリタにTclを使っている。どのような面から見てもTclよりPythonの方が遥かに優れているというのに——ただし永久凍土の問題を別にすれば。

これに尽きる。

よく言われるが、インデントに縛りがあるのもselfが付くのも慣れてしまえばさほど気にならないし、むしろ魅力的とも感じる。

しかし、Pythonを本当の意味で糞たらしめて居るのはその言語を使っているコミュニティがあまりにも思考停止しているからだ。

インデントやselfが気に入らないなんて些細な問題を他の言語使いから散々文句を言われたがために、本当の意味言語の弱点になっている部分が指摘された時にも「それは言語仕様が悪いんじゃない。言語仕様に沿って考えられないお前の頭が悪いだけだ」と言ってくる。

実際のところ、Python仕様には言い逃れのできない仕様の穴は幾つもある。もちろんよく引き合いに出されるRubyPerlにも仕様の落とし穴は山ほどある。仕様の穴そのものは実はそんなに深刻な問題ではない。

真に問題なのはPythonコミュニティはその仕様の穴を断じて穴と認めない事だ。

言語同士でdisり合いになったとき、何かその穴をつつかれた場合の各人の反応はおよそこんな感じだ。

仕様カオスになり続けるPerlだと

Perl使い「そうだよね、そこの仕様は頭悪いよね。でもPerl6のこの機能使えばこんなに短く綺麗に書けるんだぜ(と全く読めないコードを出す)」

比較的柔軟な仕様コミュニティのあるRuby

Ruby使い「うんうん、仕様の話題でもそこは殺人現場とか呼ばれてるね。コミュニティ的にはこっちの機能を使うことを推奨しててそっちはobsolatedだね」

酷い言語仕様調教されつくしたPHP

PHP使い「それ言い出したらこっちにこんなに大きな地雷あるし、この地雷なんてもっと大きいぜ。ほんとPHP地獄だぜ」

永久凍土Python

Python使い「お前の思考通りに言語が動くんじゃなくてお前の思考を言語に添わせるんだよ、言語挙動すら理解せずに使おうとするんじゃねえ」

こんな感じに、まず最初質問者人格攻撃を行う。インデント言語であることやselfの問題について未熟なプログラマからのどうでもいい指摘を散々受け流してきたPythonコミュニティは、言語仕様について文句を言われる事に慣れているためまず相手を攻撃する。初心者寒波洗礼するのだ。

言語仕様が汚くなっている事まではどの言語も一緒なのだけれど、Pythonコミュニティだけは欠点を認めず必死に(∩ ゚д゚)アーアーきこえないという態度を取る。

これこそがPythonを糞言語たらしめる最大の弱点である永久凍土の問題。コミュニティが凍れば言語進歩も凍る。

Pythonそのものは一人で使う分には手軽な言語なだけに、使用者思考停止しているが故の機会損失の多さが残念である

2011-12-12

コンピュータプログラミング概念技法モデル」の目次

第1章 プログラミング概念入門
	1.1 計算器
	1.2 変数
	1.3 関数
	1.4 リスト
	1.5 リストについての関数
	1.6 プログラムの正しさ
	1.7 計算量
	1.8 遅延計算
	1.9 高階プログラミング
	1.10 並列性
	1.11 データフロー
	1.12 明示的状態
	1.13 オブジェクト
	1.14 クラス
	1.15 非決定性と時間
	1.16 原子性
	1.17 ここからどこへ行くのか?
	1.18 練習問題

第1部 一般的計算モデル

第2章 宣言的計算モデル
	2.1 実用プログラミング言語定義
		2.1.1 言語の構文
		2.1.2 言語意味
	2.2 単一代入格納域
		2.2.1 宣言的変数
		2.2.2 値格納域
		2.2.3 値生成
		2.2.4 変数識別子
		2.2.5 識別子を使う値生成
		2.2.6 部分値
		2.2.7 変数の,変数への束縛
		2.2.8 データフロー変数
	2.3 核言語
		2.3.1 構文
		2.3.2 値と型
		2.3.3 基本型
		2.3.4 レコード手続き
		2.3.5 基本操作
	2.4 核言語意味
		2.4.1 基本概念
		2.4.2 抽象マシン
		2.4.3 待機不能な文
		2.4.4 待機可能な文
		2.4.5 基本概念再訪
	2.5 メモリ管理
		2.5.1 末尾呼び出し最適化
		2.5.2 メモリライフサイクル
		2.5.3 ガーベッジコレクション
		2.5.4 ガーベッジコレクションは魔術ではない
		2.5.5 Mozartのガーベッジコレクタ
	2.6 核言語から実用言語へ
		2.6.1 構文上の便宜
		2.6.2 関数(fun文)
		2.6.3 対話的インターフェース(declare文)
	2.7 例外
		2.7.1 動機と基本概念
		2.7.2 例外を持つ宣言的モデル
		2.7.3 親言語の構文
		2.7.4 システム例外
	2.8 進んだ話題
		2.8.1 関数型プログラミング言語
		2.8.2 単一化と内含(entailment)
		2.8.3 動的型付けと静的型付け
	2.9 練習問題

第3章 宣言的プログラミング技法
	3.1 宣言的とはどういうことか?
		3.1.1 宣言的プログラムの分類
		3.1.2 仕様記述言語
		3.1.3 宣言的モデルにおいてコンポーネントを実装すること
	3.2 反復計算
		3.2.1 一般的図式
		3.2.2 数についての反復
		3.2.3 局所的手続きを使うこと
		3.2.4 一般的図式から制御抽象へ
	3.3 再帰計算
		3.3.1 スタックの大きさの増加
		3.3.2 代入ベース抽象マシン
		3.3.3 再帰計算を反復計算に変換すること
	3.4 再帰を用いるプログラミング
		3.4.1 型の記法
		3.4.2 リストについてのプログラミング
		3.4.3 アキュムレータ
		3.4.4 差分リスト
		3.4.5 キュー
		3.4.6 木
		3.4.7 木を描画すること
		3.4.8 構文解析
	3.5 時間効率空間効率
		3.5.1 実行時間
		3.5.2 メモリ使用量
		3.5.3 償却的計算量
		3.5.4 性能についての考察
	3.6 高階プログラミング
		3.6.1 基本操作
		3.6.2 ループ抽象
		3.6.3 ループ言語的支援
		3.6.4 データ駆動技法
		3.6.5 明示的遅延計算
		3.6.6 カリー化
	3.7 抽象データ型
		3.7.1 宣言的スタック
		3.7.2 宣言的辞書
		3.7.3 単語出現頻度アプリケーション
		3.7.4 安全抽象データ型
		3.7.5 安全な型を備えた宣言的モデル
		3.7.6 安全な宣言的辞書
		3.7.7 資格セキュリティ
	3.8 宣言的でない必要物
		3.8.1 ファイルを伴うテキスト入出力
		3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力
		3.8.3 ファイルとの状態なしデータI/O
	3.9 小規模プログラム設計
		3.9.1 設計方法
		3.9.2 プログラム設計の例
		3.9.3 ソフトウェアコンポーネント
		3.9.4 スタンドアロンプログラムの例
	3.10 練習問題

第4章 宣言的並列性
	4.1 データ駆動並列モデル
		4.1.1 基本概念
		4.1.2 スレッド意味
		4.1.3 実行列
		4.1.4 宣言的並列性とは何か?
	4.2 スレッドプログラミングの基本的技法
		4.2.1 スレッドを生成すること
		4.2.2 スレッドブラウザ
		4.2.3 スレッドを使うデータフロー計算
		4.2.4 スレッドスケジューリング
		4.2.5 協調的並列性と競合的並列性
		4.2.6 スレッド操作
	4.3 ストリーム
		4.3.1 基本的生産者消費者
		4.3.2 変換器とパイプライン
		4.3.3 資源管理し,処理能力改善すること
		4.3.4 ストリームオブジェクト
		4.3.5 ディジタル論理シミュレーション
	4.4 宣言的並列モデルを直接使うこと
		4.4.1 順序決定並列性
		4.4.2 コルーチン
		4.4.3 並列的合成
	4.5 遅延実行
		4.5.1 要求駆動並列モデル
		4.5.2 宣言的計算モデル
		4.5.3 遅延ストリーム
		4.5.4 有界バッファ
		4.5.5 ファイルを遅延的に読み込むこと
		4.5.6 ハミング問題
		4.5.7 遅延リスト操作
		4.5.8 永続的キューアルゴリズム設計
		4.5.9 リスト内包表記
	4.6 甘いリアルタイムプログラミング
		4.6.1 基本操作
		4.6.2 ティッキング(ticking)
	4.7 Haskell言語
		4.7.1 計算モデル
		4.7.2 遅延計算
		4.7.3 カリー化
		4.7.4 多態型
		4.7.5 型クラス
	4.8 宣言的プログラム限界拡張
		4.8.1 効率性
		4.8.2 モジュラ性
		4.8.3 非決定性
		4.8.4 現実世界
		4.8.5 正しいモデルを選ぶこと
		4.8.6 拡張されたモデル
		4.8.7 異なるモデルを一緒に使うこと
	4.9 進んだ話題
		4.9.1 例外を持つ宣言的並列モデル
		4.9.2 さらに遅延実行について
		4.9.3 通信チャンネルとしてのデータフロー変数
		4.9.4 さらに同期について
		4.9.5 データフロー変数有用性
	4.10 歴史に関する注記
	4.11 練習問題

第5章 メッセージ伝達並列性
	5.1 メッセージ伝達並列モデル
		5.1.1 ポート
		5.1.2 ポート意味
	5.2 ポートオブジェクト
		5.2.1 NewPortObject抽象
		5.2.2 例
		5.2.3 ポートオブジェクトに関する議論
	5.3 簡単なメッセージプロトコル
		5.3.1 RMI(遠隔メソッド起動)
		5.3.2 非同期RMI
		5.3.3 コールバックのあるRMI(スレッド使用)
		5.3.4 コールバックのあるRMI(継続のためのレコード使用)
		5.3.5 コールバックのあるRMI(継続のための手続き使用)
		5.3.6 エラー報告
		5.3.7 コールバックのある非同期RMI
		5.3.8 二重コールバック
	5.4 並列性のためのプログラム設計
		5.4.1 並列コンポーネントを使うプログラミング
		5.4.2 設計方法
		5.4.3 並列性パターンとしての機能的構成要素
	5.5 リフト制御システム
		5.5.1 状態遷移図
		5.5.2 実装
		5.5.3 リフト制御システムの改良
	5.6 メソッド伝達モデルを直接使用すること
		5.6.1 1つのスレッドを共有する複数のポートオブジェクト
		5.6.2 ポートを使う並列キュー
		5.6.3 終点検出を行うスレッド抽象
		5.6.4 直列依存関係の除去
	5.7 Erlang言語
		5.7.1 計算モデル
		5.7.2 Erlangプログラミング入門
		5.7.3 receive操作
	5.8 進んだ話題
		5.8.1 非決定性並列モデル
	5.9 練習問題

第6章 明示的状態
	6.1 状態とは何か?
		6.1.1 暗黙的(宣言的)状態
		6.1.2 明示的状態
	6.2 状態とシステム構築
		6.2.1 システムの性質
		6.2.2 コンポーネントベースプログラミング
		6.2.3 オブジェクト指向プログラミング
	6.3 明示的状態を持つ宣言的モデル
		6.3.1 セル
		6.3.2 セル意味
		6.3.3 宣言的プログラミングとの関係
		6.3.4 共有と同等
	6.4 データ抽象
		6.4.1 データ抽象組織する8つの方法
		6.4.2 スタックの変種
		6.4.3 多態性
		6.4.4 引数受け渡し
		6.4.5 取り消し可能資格
	6.5 状態ありコレクション
		6.5.1 インデックス付きコレクション
		6.5.2 インデックス付きコレクションを選ぶこと
		6.5.3 その他のコレクション
	6.6 状態に関する推論
		6.6.1 不変表明
		6.6.2 例
		6.6.3 表明
		6.6.4 証明規則
		6.6.5 正常終了
	6.7 大規模プログラム設計
		6.7.1 設計方法
		6.7.2 階層システム構造
		6.7.3 保守性
		6.7.4 将来の発展
		6.7.5 さらに深く知るために
	6.8 ケーススタディ
		6.8.1 遷移的閉包
		6.8.2 単語出現頻度(状態あり辞書を使用する)
		6.8.3 乱数を生成すること
		6.8.4 口コミシミュレーション
	6.9 進んだ話題
		6.9.1 状態ありプログラミング限界
		6.9.2 メモリ管理と外部参照
	6.10 練習問題

第7章 オブジェクト指向プログラミング
	7.1 継承
	7.2 完全なデータ抽象としてのクラス
		7.2.1 例
		7.2.2 この例の意味
		7.2.3 クラスオブジェクト定義すること
		7.2.4 クラスメンバ
		7.2.5 属性初期化すること
		7.2.6 第1級メッセージ
		7.2.7 第1級の属性
		7.2.8 プログラミング技法
	7.3 漸増的データ抽象としてのクラス
		7.3.1 継承グラフ
		7.3.2 メソッドアクセス制御(静的束縛と動的束縛)
		7.3.3 カプセル化制御
		7.3.4 転嫁委任
		7.3.5 内省
	7.4 継承を使うプログラミング
		7.4.1 継承の正しい使い方
		7.4.2 型に従って階層を構成すること
		7.4.3 汎用クラス
		7.4.4 多重継承
		7.4.5 多重継承に関するおおざっぱな指針
		7.4.6 クラス図の目的
		7.4.7 デザインパターン
	7.5 他の計算モデルとの関係
		7.5.1 オブジェクトベースプログラミングコンポーネントベースプログラミング
		7.5.2 高階プログラミング
		7.5.3 関数分解と型分解
		7.5.4 すべてをオブジェクトにすべきか?
	7.6 オブジェクトシステムを実装すること
		7.6.1 抽象図
		7.6.2 クラスを実装すること
		7.6.3 オブジェクトの実装
		7.6.4 継承の実装
	7.7 Java言語(直列部分)
		7.7.1 計算モデル
		7.7.2 Javaプログラミング入門
	7.8 能動オブジェクト
		7.8.1 例
		7.8.2 NewActive抽象
		7.8.3 フラウィウス・ヨセフスの問題
		7.8.4 その他の能動オブジェクト抽象
		7.8.5 能動オブジェクトを使うイベントマネージャ
	7.9 練習問題

第8章 状態共有並列性
	8.1 状態共有並列モデル
	8.2 並列性を持つプログラミング
		8.2.1 さまざまな手法概観
		8.2.2 状態共有並列モデルを直接使うこと
		8.2.3 原子アクションを使うプログラミング
		8.2.4 さらに読むべき本
	8.3 ロック
		8.3.1 状態あり並列データ抽象を構築すること
		8.3.2 タプル空間(Linda)
		8.3.3 ロックを実装すること
	8.4 モニタ
		8.4.1 定義
		8.4.2 有界バッファ
		8.4.3 モニタを使うプログラミング
		8.4.4 モニタを実装すること
		8.4.5 モニタの別の意味
	8.5 トランザクション
		8.5.1 並列性制御
		8.5.2 簡易トランザクションマネージャ
		8.5.3 セルについてのトランザクション
		8.5.4 セルについてのトランザクションを実装すること
		8.5.5 トランザクションについてさらに
	8.6 Java言語(並列部分)
		8.6.1 ロック
		8.6.2 モニタ
	8.7 練習問題

第9章 関係プログラミング
	9.1 関係計算モデル
		9.1.1 choice文とfail文
		9.1.2 探索木
		9.1.3 カプセル化された
		9.1.4 Solve関数
	9.2 別の例
		9.2.1 数値例
		9.2.2 パズルとnクイーン問題
	9.3 論理プログラミングとの関係
		9.3.1 論理論理プログラミング
		9.3.2 操作意味論理意味
		9.3.3 非決定性論理プログラミング
		9.3.4 純粋Prologとの関係
		9.3.5 他のモデルにおける論理プログラミング
	9.4 自然言語構文解析
		9.4.1 簡単な文法
		9.4.2 この文法に従う構文解析
		9.4.3 構文木を生成すること
		9.4.4 限定記号を生成すること
		9.4.5 パーサを走らせること
		9.4.6 パーサを「逆向きに(backward)」走らせること
		9.4.7 単一化文法
	9.5 文法インタプリタ
		9.5.1 簡単な文法
		9.5.2 文法のコード化
		9.5.3 文法インタプリタを走らせること
		9.5.4 文法インタプリタを実装すること
	9.6 データベース
		9.6.1 関係を定義すること
		9.6.2 関係を使って計算すること
		9.6.3 関係を実装すること
	9.7 Prolog言語
		9.7.1 計算モデル
		9.7.2 Prologプログラミング入門
		9.7.3 Prologプログラムを関係プログラム翻訳すること
	9.8 練習問題

第2部 特殊化された計算モデル10グラフィカルユーザインタフェースプログラミング
	10.1 宣言的/手続き的方法
	10.2 宣言的/手続き的方法を使うこと
		10.2.1 基本的ユーザインタフェースの要素
		10.2.2 GUIを構築すること
		10.2.3 宣言的座標
		10.2.4 リサイズ時の宣言的振る舞い
		10.2.5 ウィジェットの動的振る舞い
	10.3 対話的学習ツールPrototyper
	10.4 ケーススタディ
		10.4.1 簡単なプログレモニタ
		10.4.2 簡単なカレンダウィジェット
		10.4.3 ユーザインタフェースの動的生成
		10.4.4 状況順応時計
	10.5 GUIツールを実装すること
	10.6 練習問題

第11章 分散プログラミング
	11.1 分散システムの分類
	11.2 分散モデル
	11.3 宣言的データの分散
		11.3.1 オープン分散と大域的ネーミング
		11.3.2 宣言的データを共有すること
		11.3.3 チケット配布
		11.3.4 ストリーム通信
	11.4 状態の分散
		11.4.1 単純状態共有
		11.4.2 分散字句的スコープ
	11.5 ネットワークアウェアネス
	11.6 共通分散プログラミングパターン
		11.6.1 静的オブジェクトモバイルオブジェクト
		11.6.2 非同期的オブジェクトデータフロー
		11.6.3 サーバ
		11.6.4 クローズド分散
	11.7 分散プロトコル
		11.7.1 言語実体
		11.7.2 モバイル状態プロトコル
		11.7.3 分散束縛プロトコル
		11.7.4 メモリ管理
	11.8 部分的失敗
		11.8.1 失敗モデル
		11.8.2 失敗処理の簡単な場合
		11.8.3 回復可能サーバ
		11.8.4 アクティブフォールトトレランス
	11.9 セキュリティ
	11.10 アプリケーションを構築すること
		11.10.1 まずは集中,後に分散
		11.10.2 部分的失敗に対処すること
		11.10.3 分散コンポーネント
	11.11 練習問題

第12章 制約プログラミング
	12.1 伝播・探索法
		12.1.1 基本的考え方
		12.1.2 部分情報を使って計算すること
		12.1.3 例
		12.1.4 この例を実行すること
		12.1.5 まとめ
	12.2 プログラミング技法
		12.2.1 覆面算
		12.2.2 回文積再訪
	12.3 制約ベース計算モデル
		12.3.1 基本的制約と伝播子
		12.3.2 計算空間の探索をプログラムすること
	12.4 計算空間定義し,使うこと
		12.4.1 深さ優先探索エンジン
		12.4.2 検索エンジンの実行例
		12.4.3 計算空間の生成
		12.4.4 空間の実行
		12.4.5 制約の登録
		12.4.6 並列的伝播
		12.4.7 分配(探索準備)
		12.4.8 空間の状態
		12.4.9 空間クローン
		12.4.10 選択肢を先に任せること
		12.4.11 空間マージすること
		12.4.12 空間失敗
		12.4.13 空間計算を注入すること
	12.5 関係計算モデルを実装すること
		12.5.1 choice文
		12.5.2 Solve関数
	12.6 練習問題

第3部 意味

第13章 言語意味
	13.1 一般的計算モデル
		13.1.1 格納域
		13.1.2 単一代入(制約)格納域
		13.1.3 抽象構文
		13.1.4 構造的規則
		13.1.5 直列実行と並列実行
		13.1.6 抽象マシン意味との比較
		13.1.7 変数導入
		13.1.8 同等性の強制(tell)
		13.1.9 条件文(ask)
		13.1.10 名前
		13.1.11 手続抽象
		13.1.12 明示的状態
		13.1.13 by-need同期
		13.1.14 読み出し専用変数
		13.1.15 例外処理
		13.1.16 失敗値
		13.1.17 変数置き換え
	13.2 宣言的並列性
		13.2.1 部分停止と全体停止
		13.2.2 論理同値
		13.2.3 宣言的並列性の形式的定義
		13.2.4 合流性
	13.3 8つの計算モデル
	13.4 よくある抽象意味
	13.5 歴史に関する注記
	13.6 練習問題

2011-10-01

プログラム変換」の目次

第1章 プログラム変換入門 佐藤泰介
	1.1 今なぜプログラム変換か?
	1.2 変換あれこれ
	1.3 システム化について

第2章 等式プログラム等価変換 二木厚吉
	2.1 等価変換例
	2.2 等価性
	2.3 等価変換法
	2.4 おわりに

第3章 論理言語におけるプログラム変換 玉木久夫
	3.1 はじめに
	3.2 論理プログラムとその意味論
	3.3 展開/たたみ込み変換:例題
	3.4 展開/たたみ込み変換の正当性
	3.5 他の変換との両立性
	3.6 おわりに

第4章 部分計算 二村良彦
	4.1 はじめに
	4.2 部分計算概要
	4.3 部分計算の応用例
	4.4 部分計算理論
	4.5 実用化のための課題

第5章 メタプログラミングと部分計算 竹内彰一
	5.1 はじめに
	5.2 Prologプログラムの部分計算
	5.3 メタプログラミングへの応用
	5.4 メタインタプリタの段階的特殊化
	5.5 おわりに

第6章 合成問題への新しいアプローチ 佐藤泰介
	6.1 否定技法
	6.2 二重否定技法
	6.3 論理プログラムの合成

第7章 ベクトル化とプログラム変換 安村通晃
	7.1 はじめに
	7.2 プログラム変換
	7.3 ベクトル化
	7.4 主要変換
	7.5 基軸変換
	7.6 その他の変換
	7.7 ベクトル化におけるプログラム変換の特徴
	7.8 おわりに

第8章 GHCでのプログラム変換 吉川康一
	8.1 はじめに
	8.2 簡単な問題
	8.3 フィルタプロセスの融合
	8.4 プログラム変換の手順
	8.5 電子回路シミュレータへの応用
	8.6 おわりに

第9章 実用規模プログラムの変換試行事例 吉田紀彦
	9.1 はじめに
	9.2 コンパイラの変換
	9.3 プログラム変換の実用可能性
	9.4 おわりに

2011-09-23

「続 新しいプログラミングパラダイム」の目次


第1章 並行プログラミングGHC (上田和紀)
	1.1 はじめに
	1.2 ターゲットを明確にしよう
	1.3 はじめが大切
	1.4 GHCが与える並行計算の枠組み
		1.4.1 GHCにおける計算とは,外界との情報のやりとり(通信)である
		1.4.2 計算を行う主体は,互いに,および外界と通信し合うプロセスの集まりである
		1.4.3 プロセスは,停止するとは限らない
		1.4.4 プロセスは,開いた系(open system)をモデル化する
		1.4.5 情報とは変数と値との結付き(結合)のことである
		1.4.6 プロセスは,結合の観測と生成を行う
		1.4.7 プロセスは,書換え規則を用いて定義する
		1.4.8 通信は,プロセス間の共有変数を用いて行う
		1.4.9 外貨も,プロセスとしてモデル化される
		1.4.10 通信は,非同期的である
		1.4.11 プロセスのふるまいは,非決定的でありうる
	1.5 もう少し具体的なパラダイム
		1.5.1 ストリームと双方向通信
		1.5.2 履歴のあるオブジェクト表現
		1.5.3 データ駆動計算と要求駆動計算
		1.5.4 モジュラリティと差分プログラミング
		1.5.5 プロセスによるデータ表現
	1.6 歴史的背景と文献案内
	1.7 並行プログラミング効率
	1.8 まとめ


第2章 様相論理テンポラル・プログラミング (桜川貴司)
	2.1 はじめに
	2.2 様相論理
	2.3 時制論理
	2.4 多世界モデル
	2.5 到達可能性と局所性
	2.6 純論理プログラミングへ向けて
	2.7 Temporal Prolog
	2.8 RACCO
	2.9 実現
	2.10 まとめと参考文献案内


第3章 レコードプログラミング (横田一正)
	3.1 はじめに
	3.2 レコードと述語の表現
	3.3 レコード構造とφ-項
		3.3.1 φ-項の定義
		3.3.2 型の半順序と束
		3.3.3 KBLLOGIN
	3.4 応用――データベース視点から
		3.4.1 演繹データベース
		3.4.2 レコードプログラミングデータベース
		3.4.3 いくつかの例
	3.5 まとめ
	3.6 文献案内


第4章 抽象データ型とOBJ2 (二木厚吉・中川 中)
	4.1 はじめに
	4.2 抽象データ型と代数言語
		4.2.1 抽象データ型
		4.2.2 代数言語
		4.2.3 始代数
		4.2.4 項代数
		4.2.5 項書換えシステム
	4.3 OBJ2
		4.3.1 OBJ2の基本構造
		4.3.2 モジュールの参照方法
		4.3.3 混置関数記号
		4.3.4 モジュールパラメータ化
		4.3.5 パラメータ機構による高階関数記述
		4.3.6 順序ソート
		4.3.7 属性つきパターンマッチング
		4.3.8 評価戦略の指定
		4.3.9 モジュール表現
	4.4 おわりに


第5章 プログラム代数FP (富樫 敦)
	5.1 はじめに
	5.2 プログラミングシステム FP
		5.2.1 オブジェクト
		5.2.2 基本関数
		5.2.3 プログラム構成子
		5.2.4 関数定義
		5.2.5 FPプログラミングスタイル
	5.3 プログラム代数
		5.3.1 プログラム代数則
		5.3.2 代数則の証明
		5.3.3 代数則とプログラム
	5.4 ラムダ計算拡張
		5.4.1 ラムダ式拡張
		5.4.2 拡張されたラムダ計算の簡約規則
		5.4.3 そのほかのリスト操作演算子
		5.4.4 相互再帰定義式
		5.4.5 ストリーム(無限リスト)処理
	5.5 FPプログラム翻訳
		5.5.1 オブジェクト翻訳
		5.5.2 基本関数翻訳
		5.5.3 プログラム構成子の翻訳
		5.5.4 簡約規則を用いた代数則の検証
	5.6 おわりに


第6章 カテゴリカル・プログラミング (横内寛文)
	6.1 はじめに
	6.2 値からルフィズムへ
	6.3 カテゴリカル・コンビネータ
		6.3.1 ラムダ計算意味論
		6.3.2 モルフィズムによる意味論
		6.3.3 カテゴリカル・コンビネータ理論CCL
	6.4 関数型プログラミングへの応用
		6.4.1 関数型プログラミング言語ML/O
		6.4.2 CCLの拡張
		6.4.3 CCLに基づいた処理系
		6.4.4 公理系に基づいた最適化
	6.5 まとめ


第7章 最大公約数――普遍代数多項式イデアル自動証明におけるユークリッドの互除法 (外山芳人)
	7.1 はじめに
	7.2 完備化アルゴリズム
		7.2.1 グラス置換えパズル
		7.2.2 リダクションシステム
		7.2.3 完備なシステム
		7.2.4 完備化
		7.2.5 パズルの答
	7.3 普遍代数における完備化アルゴリズム
		7.3.1 群論の語の問題
		7.3.2 群の公理の完備化
		7.3.3 Knuth-Bendix完備化アルゴリズム
	7.4 多項式イデアル理論における完備化アルゴリズム
		7.4.1 ユークリッドの互除法
		7.4.2 多項式イデアル
		7.4.3 Buchbergerアルゴリズム
	7.5 一階述語論理における完備化アルゴリズム
		7.5.1 レゾリューション法
		7.5.2 Hsiangのアイデア
	7.6 おわりに


第8章 構成的プログラミング (林 晋)
	8.1 構成的プログラミング?
	8.2 型付きラムダ計算
	8.3 論理としての型付きラムダ計算
	8.4 構成的プログラミングとは
	8.5 構成的プログラミングにおける再帰呼び出し
	8.6 おわりに:構成的プログラミング未来はあるか?


第9章 メタプログラミングリフレクション (田中二郎)
	9.1 はじめに
	9.2 計算システム
		9.2.1 因果結合システム
		9.2.2 メタシステム
		9.2.3 リフレクティブシステム
	9.3 3-Lisp
	9.4 リフレクティブタワー
	9.5 GHCにおけるリフレクション
		9.5.1 並列論理言語GHC
		9.5.2 GHC言語仕様
		9.5.3 GHCメタインタプリタ
		9.5.4 リフレクティブ述語のインプリメント
	9.6 まとめ

2011-05-07

モテる情報科学女子力を磨くための4つの心得

1. あえて2~3世代前のインタプリタを使う

あえて2~3世代前のインタプリタを使うようにしましょう。そして飲み会の場で好みの男がいたら話しかけ、わざとらしくパソコンを出していじってみましょう。そして「あ~ん! このインタプリタ本当にマジでチョームカつくんですけどぉぉお~!」と言って、男に「どうしたの?」と言わせましょう。言わせたらもう大成功。「LiLFeSとか詳しくなくてぇ~! ずっとコレ使ってるんですけどぉ~! すぐセグフォるんですぅ~! ぷんぷくり~ん(怒)」と言いましょう。だいたいの男は新しいインタプリタを持ちたがる習性があるので、古かったとしても1世代前のインタプリタを使っているはずです

そこで男が「新しいインタプリタにしないの?」と言ってくるはず(言ってこない空気が読めない男はその時点でガン無視OK)。そう言われたらあなたは「なんかなんかぁ~! 最近LiLFeS1.4.0が人気なんでしょー!? あれってどうなんですかぁ? 新しいの欲しいですけどわかんなぁぁああい!! 私かわいそーなコ★」と返します。すると男は「LiLFeS1.3.9でしょ? 1.4.0はまだ出てないよ。本当に良くわからないみたいだね。どんなコード書いたの?」という話になって、次の休みの日にふたりでLiLFeS課題デートができるというわけですあなた女子力が高ければ、男がデバッグしてくれるかも!?

 

2. Java><を使うとモテる

「大きい!」とか「小さい!」などを表現する「><」をコードに入れると、Java男性ユーザーは「なんかこの子カワイイなぁ」や「Basicっぽいよね」「<>が正しいよね」、「ってか!=だよね」と思ってくれますインターネット上では現実世界よりもイメージが増幅されて相手に伝わるので 「><」 を多用することによって、男性あなた可憐女の子しい勘違いしてくれるのです。そういうコードを書くと絶対にコンパイルエラーになりますが気にしないようにしましょう。

 

3. とりあえず男には「えー! なにそれ!?  知りたい知りたーい♪」と言っておく

飲み会などで男が女性に話すことといえばEmacsvimの話ばかり。よって、女性にとってどうでもいい話ばかりです。でもそこで適当に「へぇーそうなんですかぁ~?」とか「よくわかんないですけどすごいんですねぇ」と返してしまうと、さすがの男も「この女本当に情報屋か?」と気がついてしまいます。ダメ女だとバレたら終わりです。そこは無意味テンションをあげて、「えー! なにそれ!?  知りたい知りたーい♪」と言っておくのが正解。たとえ興味がない話題でも、テンションと積極性でその場を乗り切りましょう。積極的に話を聞いてくれる女性に男は弱いのです

いろいろと話を聞いたあと、「〇〇は〇〇で、〇〇が〇〇なんですね! 覚えたぞぉ! メモメモ!」とコメントすればパーフェクト。続けて頭に指をさしてくるくる回しつつ「キュンキュンキュン! キュンキュンキュン!」と言って、「どうしたの?」と男に言わせるのもアリ。そこで「私のハードディスク記録しているのでありますっ☆」と言えば女子力アップ! そこでまた男は「この子おもしろくてカワイイかも!?」と思ってくれます。私は学歴も知識もありませんしブスですが、こういうテクニックを使えば知識がない私のようなバカ女のほうがモテたりするのです。男は優越感に浸りたいですからね。

 

4. aptitudeではプロプラインストール出来ない女をアピールせよ

男とパソコンを起動したら、真っ先にFlashなどのプロプラソフトを探して「あーん! 私これインストールできないんですよねぇ~(悲)」と言いましょう。するとほぼ100パーセント「どうして? 嫌いなの?」と聞かれるので、「嫌いじゃないしインストールしたいんですけどできないんです><」と返答しましょう。ここでまた100パーセント「嫌いじゃないのにどうしてインストールできないの?」と聞かれるので、うつむいて3~5秒ほど間をおいてからボソッとこう言います。「……だって、……だってプロプラって中で何するか分からないじゃないですかぁっ! 個人情報かわいそうですぅ! まだ流出してないのにぃぃ~(悲)。図書券すらもらえないんですよ……」と身を震わせて言うのです

その瞬間、あなた情報科学女子力がアップします。きっと男は「なんて分かっているコなんだろう! 絶対にゲットしてやるぞ! コイツは俺の女だ!」と心のなかで誓い、あなたに惚れ込むはずです。意中の男と付き合うことになったら、そんなことは忘れて好きなだけインストールして大丈夫です。「インストールできないんじゃなかったっけ?」と言われたら「大丈夫になった」とか「慣れた」、「GPLウザい」と言っておけばOKです

2011-02-26

http://anond.hatelabo.jp/20110226211140

文法が狂ってるプログラムなんて今日日見たことないんだけど、実際あるの?

インタプリタって基本的な知識もないの?

色んな意味で大変そうだね。おたく会社

2010-07-21

やったー俺にぴったりの求人があったよ

募集要項

仕事内容:オンラインゲーム開発

ゲームプログラム全般

ネットワークデータベースシステム設計、開発

認証課金システムの開発

・運営ツールの開発

サーバ環境の構築、運用

求める経験

【必須経験

C/C++perlRubyPythonPHPなどを用いたプログラム開発経験

【歓迎経験

C/C++を用いたゲーム開発経験

Unix系OS管理運用経験

C/C++, Perl, Ruby, Python, PHP全部使ったことあるよ!

PythonPHP仕事では使ったことないから微妙だけど。あとC++言語仕様完璧には把握できてないけど。

でもC/C++は商用のコンパイラを作るプロジェクトに参加してたこともあるしバッチリだよ。

Rubyは1.6の頃にインタプリタソース全部読んだりしたけど最近進化にはついていけてないかも。

ゲーム開発経験Unix系OS管理運用経験もあるよ!

【歓迎スキル

MySQLPostgreSQL等のRDBMSに関する知識

3Dプログラミングに関する知識

このへんも全部あるよバッチリ

そんなものは求められてないだろうけど、

RDBMS3Dも仮に一から自分で全部作れと言われても簡単なものなら作れるレベルだよ。

特に3DLSIを作るプロジェクトに参加してたこともある。

しかし…

年収給与: 300万円以上350万円以下

まあ、そうだよね最近プログラマ給与なんてこんなもんだよね…

2010-07-01

PHPの人がPHPの最新版を使ってなかった件

PHPユーザー会の中の人とたまたま話したんだけど、アプリケーションPHP5.2系からPHP5.3系への移行が滞っているようだ。

「業務でPHP5.3使ってますよー。」って言ったらむしろ驚かれた。どういうこった?

いま移行せずに、PHP5.3ってどうなるのよ?その先にあるPHP6系ってどうなるのよ?不安しかでてこない。

不満&不安
  1. サポート終了したPHP4系はまだレンタルサーバーにはびこっている。
  2. ライブラリPEARPHP4をサポートしつづけてるからヘボくなってきてる。
  3. 将来リリースされる予定のPHP6が不安
    1. 内部文字コードUTF-16の件でロールバック
      1. コアエンジニアの分担なので、ユーザーエンジニアには影響はそんなないけど。
  4. インタプリタが対話的にできない。
    1. 自作しろってことか??
  5. 5系より前からある関数のExceptionが整備されてない。catchでキャッチしにくい。
  6. 4系から入ったクラスのvarが5系のJavaっぽいオブジェクト指向文法によって不要になった点。
期待&満足
  1. 5.3から名前空間無名関数サポートされた。
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん