Cの宣言は英語順で読もう、という話 - K.Maebashi's はてなブログ
Cでのポインタの読み方 上記のページ、現時点ではてなブックマークが1241ついています。同趣旨のことを私は1998年に以下のページに書きました。 配列とポインタの完全制覇 こちらのはてブ数は212…… きいいっ! 悔しい!! などという話はさておき。 上記ページに関連してだと思うのですが、Twitterで@kinabaさんが以下のようにつぶやかれておりました。 『という方針のCの入門記事』ということであれば、WebではないのでURLは貼れませんが、たとえば柴田望洋先生の「秘伝 C言語問答 ポインタ編」*1には以下の記述があります(p.22)。 ここで、下のように考えると、int x;の部分が*ptrに相当すると考えられますね。 int x ; int *ptr ;――*ptrはint型変数であると言っているように解釈できますね。 で、実のところこれを意識した上で、私は「C言語 ポインタ完全
プログラミング言語の力における限界生産力逓減の法則とライブラリと - K.Maebashi's はてなブログ
ひがやすをさんのブログより。 俺からみると、PHPでさくっとできることは、たいていのLLで、同じようにさくっとできる気がする。デフォルトで用意されている呪文を一発唱えればいいという話も、そんな呪文を移植すればいいだけの話。移植もそんなに難しくはないでしょう。 PHPを叩く人にガツンと申し上げたい - yvsu pron. yas いやあ、その、「移植もそんなに難しくはない」呪文が最初からお仕着せで備わっているのがPHPのよいところなのではないでしょうか。たとえそれが 山のような、しかし相互に関連しない関数。そして一貫性のない関数名。後のことを考えない、つぎはぎだらけの仕様 404 Blog Not Found:教科書はいらない - 書評 - PHP逆引きレシピ だったとしても。 書籍プログラミング言語を作るにも書きましたけど、言語の力ってのは結局のところほとんどライブラリの力で決まってしま
書籍「プログラミング言語を作る」が発売されます(amazonアソシエイトリンク追加) - K.Maebashi's はてなブログ
下記のとおり、書籍「プログラミング言語を作る」が発売されます(宣伝のため、この記事はしばらく一番上に表示します)。 http://kmaebashi.com/programmer/devlang/book/index.html 6/19 22:11 amazonのリンクを追加(関連記事)。 本書のテーマは「オリジナルのプログラミング言語を作る」ことです。 世の中には、現在広く使われているものだけでも、C, C++, Java, C#, Perl, Python, Ruby, PHP, Lisp, JavaScript……等々、すでに多くのプログラミング言語が存在します。これほど多くの言語が乱立している中で、なぜわざわざ新しい言語なんか作らなければならないのか、と思う人も多いことでしょう。 しかし、プログラムに関しては何でもそうだと思いますが、何かを深く知りたかったら、一番いいのはそれを自分
業務アプリの業務部分で、オブジェクト指向なんか使わないよね - K.Maebashi's はてなブログ
久々の更新なのでちょっとは刺激的なことを書いてみる。 今時のプログラマにはオブジェクト指向は必須、常識、みたいな言説はよく聞きます。 しかし、煽りでもなんでもなく、実のところ現場ではあまり使わない、というのも事実だったりします。 そりゃ、ライブラリやフレームワークでは使いますよ。しかし、多くのプロのプログラマが会社で作るような「業務アプリ」の世界において、プログラム全体の中でライブラリやフレームワークの占める割合は大きくはない。10万行のシステムを書いて、5万行が(自社開発の)共通ライブラリやフレームワークだというのなら、それはおそらく設計が間違っています。まず8割以上は「業務ロジック」のプログラムになるんじゃなかろうか。 そして、たいがいの「業務アプリ」は、フロントエンドがWebであろうがクライアントアプリであろうが、データの本体はRDBMSにあり、それを操作するのはSQLです。よって、
それ、C関係ないのでは - K.Maebashi's はてなブログ
ずいぶん前の記事に反応しますが。 Cはワンマン向け - 神様なんて信じない僕らのために ■[misc]Cはワンマン向けだと考えるようになった。 いや、あくまで自分の中ではです。 今、Cで作られたものを参考にしてC++に移す作業をしていたりするんだけれども、 至る所に出現する、 void* コールバック 謎フラグ hoge->foo->bar->ptr Cが、他の言語(JavaとかC#とか?)に比べてとにかくもう圧倒的にダメなところは、 実行時のチェックがない。よって、配列のオーバーラン、不正なキャスト、開放されたメモリを参照する、といった理由でのバグが発生し、原因追及が非常に困難。 GCがない。 の2点でしょう(特に前者)。C++ではこの2点(特に前者)については、書き方次第でマシになるとはいえ、完全に解決されてはいません。 で、Isoparametricさんの言うところの問題点ですが、
K.Maebashi's はてなブログ
いやさ、こんなのごちゃごちゃいうほどのもんでもない。 kmaebashi.comJavaScriptでカレンダーを作るのは別に難しい話でもないんですが、どうもカレンダーとかWebページに貼るとなると、すぐこうあれやこれやと外部ライブラリを使おうという話が出てくる。外部ライブラリを拾ってきたって使い方を覚えたり評価したりカスタマイズしたりが必要なので、こんなの自分で作る方がたぶん誰にとっても早いですよ。20年近く前、仕事でカレンダーパーツを作る必要があって、ASP.NETにカレンダーのパーツがあったので若いのがそれ使って作ろうとして、要件の一部が実装できなくて苦労していたので「そんなもん自分で作れ」と言ったらあっさりできた、ということがあったのを思い出した。 ライセンスは私の知る限りもっとも緩いライセンスであるNYSL(煮るなり焼くなり好きにしろライセンス)なので、よければ使ってやってくださ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
