この文章みてください。 オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、オブジェクト指向なんてものは、理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばGUIのコンポーネントとかはオブジェクト指向に基づいて作られているようだから、そういうツールとかを作る人には必要なものなのかもしれない。しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。どうもこの業界、オブジェクト指向でなければダメ、というような風潮がまかりとおっているけどな、オブジェクト指向なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、カプセル化とかポリ何とかとか、どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな…… 「またお前、オブジェクト指向の話をしてるのか」と思ったかもしれませんが、2010年

コミュニティノート、案の定暴走している。 どんな改悪、利用制限よりも大きくTwitter*1を壊してるんじゃなかろうか。 ※ 2024/3/12追記 コミュニティノートの、「追加の背景情報が必要ない理由を説明するノート」がうまくまわって、初期に見られた正義の暴走のようなノートは表示されないようになってきています。 コミュニティノートは、多数派に有利な仕組みです。 「コミュニティノートでは、さまざまな視点を持つユーザーにとって役に立つノートが特定されます」 となっていますが、多数派であればさまざまな視点を持つユーザーが確保しやすく、逆に少数派は視点が収束する傾向があるので不利になります。 そのため、なんらかの不満をもっているけどその不満を表明して言葉にするとだいたい間違っているという層には非常に居づらくなっています。 「間違ったツイートをしなければいい」のような発言をみかけるけど、裏を返せば

前のブログでも紹介したのだけど、ChatGPTプラグインのローリングアウトが始まって使えるようになっていて、結局みんな使うのはこの3つくらいかなーとなったので、まとめておきます。 前のブログはこれ。 Bardも世の中のサービスぜんぶGoogle製と思ってるらしい - きしだのHatena 同時に使えるのは3つまでのようだけど、他のプラグインはアメリカの不動産情報など日本からは使いづらかったり、作ってみたレベルだったりなので、結局この３つに落ち着くかなーという気がします。 WebPilot これは手放せなくなります。Web記事を読み込んでくれるプラグイン。 ChatGPTには「この記事を要約して」しか入力しなくなりそう。 このエントリを要約してもらっています。 大規模言語モデルの「脳波」が反応してる部分を壊すとどうなるか試した - きしだのHatena ※ 追記 15:21 ぼくのところには

ChatGPTが思いがけずいろいろなことを人間より賢くやっているのを見てシンギュラリティという言葉を使う人が増えたように思いますが、逆に、シンギュラリティは来ないのではという思いを強くしています。 まず、この文章でのシンギュラリティがなにかという話ですが、レイ・カーツワイルが「シンギュラリティは近い」の1章の終わりで「さあ、これが特異点だ」といっている特異点、そのシンギュラリティです。 シンギュラリティは近い―人類が生命を超越するとき 作者:レイ・カーツワイルNHK出版Amazon この特異点は単にAIが人間より賢くなるというだけではありません。人間より賢くなるだけだと、便利な道具が増えるだけなので、大騒ぎするほどの変化は起きません。人の仕事を奪うといっても、蒸気機関ほどでもないですね。印刷機などと並んで、人の生活を変える転換点にすぎず、ただひとつの点をあらわすシンギュラリティには なりま

基礎と低レイヤーは混同しがちという現象をみかけたのでメモ よくあるのが、「IDEを使うと基礎が勉強できない、メモ帳でコードを書いてコマンドラインでjavac / javaするところから始めるべき」みたいな話。 ツールを使わずツールが隠してる部分を自分でやって勉強せよ、フレームワークを使わずフレームワークが隠してる部分を自分でやって勉強せよ、という話は、これ自体は間違いではないのだけど、これを「基礎」と言ってしまうと違った方向に行ってしまう。 これは基礎ではなくて低レイヤーではなかろうか。 そして、低レイヤーは「ツールを使わずにやれ」と言ってる人の想定する「ツールを使わず」というのもすでにツールを使っていたりする。ほんとに低レイヤー知りたいなら、javac使わずハンドコンパイルでしょう。Javaバイトコード知っておくべきでしょう。 と、だんだんマニアックなこと知ってる自慢になっていく。 こう

某所でオブジェクト指向についていろいろ書いたのでまとめておく。 問題意識としては初学者がなにかというと「オブジェクト指向できるようになりたい」のようなことを言うけどそこまでの優先順位でがんばるものではないんでは、というところです。 まず前提として、オブジェクト指向は1980-2000年くらいに流行って発達したものの、それ以降は時代にあわせた進歩はしていない20年以上前の技術ってのがあります。 そのころは今だとCPUのキャッシュにも満たないようなメモリをやりくりしてプログラムを書く必要があったので、オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています。 そしてオブジェクト指向にはそこから目だった更新はなく、タイトルに書いたように、カメラがやっとついたくらいのガラケーのような古い技術という感じがします。 オブジェクト指向について、アプリケー

SICPは、よい内容について書かれた本であり、最良の本だった時期もあった。 けれども、今となっては、理解が難しく内容の割には時間がかかる、時間の無駄ともいえる本といってもいいかもしれない。 もちろん、Schemeの可能性、数値計算、プログラミング、コンピュータ教育の歴史、そしてSICP自体のすべてに興味があれば、効率がいい本かもしれない。 けれども、コンピュータ教育の歴史、SICP自体に興味がないのなら、あまり効率のいい本とはいえない。特に、Scheme、数値計算に当面の興味はなく、プログラミングについてだけを学びたいのであれば、時間の無駄でしかないと思えるし、今となっては足りない部分もある。 SICPの欠点として、まず、次の点が挙げられる。 日本語がよみにくい サンプルに数学の知識が必要 プログラムがよみにくい 日本語がよみにくいというのはよく指摘される。ただこれは翻訳だけが悪いのではな

前回、簡単なDIコンテナを作ってみたので、次はこれを使ってWebフレームワークを作ってみたいと思います。 Webサーバーをつくる まず、WebフレームワークなのでHTTPサーバーが必要ですね。なので簡単なものを作ります。 とりあえずブラウザからリクエストを受け取ったら200 OKとHTMLを返すだけのサーバーです。 今回は、そこらのブラウザからアクセスできればいいや、ということで、RFCとかの仕様に準拠することは考えません。 public class Server { public static void main(String[] args) throws IOException { ServerSocket serverSoc = new ServerSocket(8989); for (;;) { Socket s = serverSoc.accept(); new Thread((

子どもへのプログラミング教育は早ければ早いほどいいというものではない。 最近子どもへのプログラミング教育が話題になることが多いけど、恐らく小学３年生までの子どもへの効果はほとんどなく、小学４年生でもほとんどの子どもには難しいと思う。 人間の知能の発達には段階があって、必要な段階に達していないうちにそれが必要な教育を行っても効果は望めない。 まず、なんでこのエントリを書いたかというと、プログラミングには適した発達段階があるということを知らないと、その発達段階に達する前にプログラミング教育を行って、もちろんプログラミングは出来なくて、その子には適性がないという判断をしてしまうとうことが起きてしまうんじゃないかと思ったからだ。 まだ適した段階まで来てないだけなのにプログラミング教育をして失敗して「この子にはプログラミングができなかった/興味をもたなかった」という実績を作ってしまうことによって、将

おととい、渋谷JVMというイベントがあって登壇させてもらったんですが、そのあとビール飲んでるときに、ぼくが「コード書く前にコメントだけ書くのいいよね」と言ったあとの返答としてきょんくん(kyon_mm)が言った言葉。 全体としては 「コード先に書いてそのコードに対してテストを書くと実装に対するテストになるし、コードを先に書いてそのコードに対してコメントを書くと実装に対するコメントになる」 という感じ。 ここに至るまでの話もおもしろかったんだけど、ここでは、コメントについて書いてみます。 まず、実装に対するコメントってどういうのかというと、こういうの。 id = findId(name); if(id == -1){ // idが-1だったとき登録 register(name); } いやそれはコード見ればわかるから、ってやつですね。 これは、こうやるとより適切です。 id = findId

2005年くらいから、コンピュータの性能には余裕があるので、プログラムの効率が多少わるくなってもプログラムが組みやすく人間の能力が発揮できるほうがいいという傾向が強くなりました。 プログラムはサーバーで動かすものであり、サーバーの制約はネットワークとストレージでCPUやメモリには余裕があったためです。 また、世の中は、ITのない世界からITのある世界への変化の中にあって、サーバーでの情報処理やネットワークをサービスとして提供することで、世の中が変わっていきました。 そういった状況であれば、プログラムが組みやすく、思ったとおりのサービスを思った時期に提供できるということが大切になっていました。どんなに未完成でも、新しいアイデアをいち早く見て触ってもらうということが大切だったからです。 しかし、もうすでに世の中は、ITがある世界に変わりました。 もちろん、より便利な情報処理サービスも今後でてく

今日やってきた話 職業人講和20140403 from なおき きしだ あらすじ ・技術力の格差がでかくなってる ・会社は教育してくれない ・勉強するとちょっと自由になる ・勉強することはたくさんある ・10年とか20年とか勉強する必要がある ・モチベーションが必要 ・Twitterに情報もモチベーションもある ・Facebookにローカルな情報がある ・勉強会とかでモチベーションをたもつのがいい コミュニティ 福岡IT関連勉強会 福岡の水曜飲み会コミュニティ「水どう」の代表になりました - きしだのはてな 本 ソフトウェア工学 論理学 作者: 野矢茂樹出版社/メーカー: 東京大学出版会発売日: 1994/02/18メディア: 単行本購入: 24人 クリック: 175回この商品を含むブログ (80件) を見る統計学が最強の学問である 作者: 西内啓出版社/メーカー: ダイヤモンド社発売日:

よくありますよね。 「93%の人が間違える計算問題」みたいなタイトルで、開いてみたら この計算問題解けますか？ 27+83=? 簡単に見えるこの問題、なんと93%の人が間違えるのです！ みたいな。 ここで「バカにすんな！」みたいなコメントと一緒にTwitterに投稿しそうになりますが、ここでぐっとこらえるほうが良いという理由を３つあげてみます。 ひどい記事のリンクをガマンすればインターネッツから消えてくれる ひどい記事、この世から、インターネッツから消えてほしかったりしますよね。 もう見たくない。 でも、「こんな記事載せるなや！ http://example.com/easy_problem」みたいにリンク貼っちゃうと、その記事の生存どころか増殖に加担してしまいます。 コンテンツにとって、インターネッツ上に存在するというのは、リンクがどこかから貼られていることと等価です。そして、リンクが多

用語は形式的なものではなく感覚的なものであることをお断りしておきます。 言語・フレームワーク・プラットフォーム まず最初に触れるものでとっつきやすい。何か使えないことには話になりません。多くの人が、勉強というとまずここ。 何かすでにつかえる人が新しく勉強することは、生産性をあげない。そのプラットフォームを初めて採用するときの準備が減らせる。どちらかというと仕事の選択肢を増やす感じですね。 深く知ることは、最適なコードを書きトラブルを減らしトラブルが起こったときの対策も早くなるので、生産性があがります。ただ、ある程度の深さ以降は生産性への寄与度がさがるので、その点では深くまで勉強する必要はありません。 プロダクトの使い方なので、プロダクトの寿命が勉強成果の寿命です。実際に使わないものの勉強は無駄になるし、使われなくなったら無駄になる。寿命もそう長くないです。 「プログラマは勉強してもすぐ使わ

どうも、FizzBuzzがどうこうという話題を目にするなと思ったら、こういうエントリがあったらしい。 職業プログラマがFizzBuzz書けない理由 - muo-notes 趣旨としては「FizzBuzz書けなくてもプログラマとしてメシくえてるんだから、FizzBuzz書けない人をバカにするのはおかしい」ということだと思う。 ここで、このように書いてある。 彼らがFizzBuzzを書けないのは、おそらく彼ら自身が社会的価値を生む上で必要ないからであって彼らが無能だからではないということ。 とはいえ、次の記事にもあるように、受託開発の終わりが叫ばれるような時代に、FizzBuzzを書けない人が、今後もこれまでと同様な社会的価値を生んで行けるようには思えない。 受託ソフト開発会社は、もう終わり！ | 日経 xTECH（クロステック） 市場環境としては、このように書いてある。 国内中心に事業を展開

どうも、テストを書きたくない人という認識がされているのだけど、ぼくが書きたくないのは退屈で割にあわないテストで、品質が求められる部分のテストを書くのは、楽しいし、かなり好きです。 それは、たとえば品質について理解してないお客さんのプロダクトだとしても、やっぱり間違ってちゃいけない部分は、せかされても待たせて時間とってテスト書くわけです。金額計算とか。 そのかわり、商品一覧に削除済み商品がでちゃったとか、そういうところは見つかったら直せばいいかーとかで、機能見せれる早さ優先でやったりするわけです。品質対策にかかるコストのほとんどはバグの発見のためのコストで、見つかったバグを直すのは時間かからないし。そもそもそういうのは「言ってなかったけどそこは対応するメーカーがない商品も削除扱いだから」みたいなことをあとから言われることが多いわけで。 でも、まあ、結局１年間は見つかったバグを直しますよってい

さて、アルゴリズムの勉強のしかたと、ラムダ計算の勉強のしかたの目星をつけました。 アルゴリズムの勉強のしかた - きしだのはてな ラムダ計算の勉強のしかた、プログラム意味論 - きしだのはてな これでここで書いたプログラムの理論の基礎は勉強できたことになるんじゃないかと思います。 プログラムの理論とはなにか - きしだのはてな ところで、プログラムの勉強地図としてこういう図を書きました。 で、ハードウェアまわりについても、プロセッサを支える技術やネットワークはなぜつながるのかでひととおり勉強したとしましょう。 じゃあ次は、アジャイルか？テストか？UIデザインか？となるわけですが、やはりプログラマなら、プログラムの作り方や使いやすさの前に、作るプログラムの機能や性能で勝負したいじゃないですか。 いい感じに関数が分割できるよとか、読みやすい名前がつけれるよとか、効率よく仕事して定時に帰れるよと