To be a better programmer, write little proofs in your head
This is a brief write-up of a trick I learned that helps me write code faster and more accurately. I say "trick", but it's really something I started to do without noticing as I moved further into my career. When you're working on something difficult, sketch a proof in your head as you go that your code will actually do what you want it to do. A simple idea, but easier said than done: doing this "
Programming Languages: Application and Interpretation
Programming Languages:Application and InterpretationThis is the Web site for Programming Languages: Application and Interpretation, often referred to by its initials as PLAI (pronounce it like “play”). Over the years well over fifty academic institutions (that I know of) have used PLAI. PLAI is designed for upper-level courses that introduce the main ideas of programming languages. In the US, it i
Writing Toy Software Is A Joy
I am a huge fan of Richard Feyman’s famous quote: “What I cannot create, I do not understand” I think it’s brilliant, and it remains true across many fields (if you’re willing to be a little creative with the definition of ‘create’). It is to this principle that I believe I owe everything I’m truly good at. Some will tell you to avoid reinventing the wheel, but they’re wrong: you should build your
Reinvent the Wheel | Matthias Endler
One of the most harmful pieces of advice is to not reinvent the wheel. It usually comes from a good place, but is typically given by two groups of people: those who tried to invent a wheel themselves and know how hard it is those who never tried to invent a wheel and blindly follow the advice Either way, both positions lead to a climate where curiosity and exploration gets discouraged. I’m glad th
Enlightenmentware
Enlightenmentware ✏ 2024-05-20 ✂ 2024-05-20 UNIX Git Emacs Boost.Graph Bazel Conclusion As programmers, we interact with software tools daily. Most of them can barely get the job done. But occasionally, we discover a piece of software that transcends mere utility. These tools capture our imagination, open new possibilities, and affect how we design our own systems. I call such software enlightenme
状態の広がりと憑依 - 解釈をするために手を動かす
近年の実用に耐えるプログラミング言語には、構造体、クラスや ADT などのデータの塊（以後、単に「オブジェクト」と言う）を定義する機能が備わっています。 そういった言語でオブジェクトの構造を設計するとき、出来上がってきた設計について僕が真っ先に行う（おそらく最も、もっと言うなら唯一の）重要な sanity-check として、「その構造を持つオブジェクトoに仮に認識主体を認めた場合、oのどのプロパティがoの意思によって動きうる（生得的でない）のか1？そもそもoに認識主体を考えられるほどにoが『モノ』の形をしているか？o単体の意思によってプロパティが動きうる空間はどのような形をしているか？その一連の事情は設計・命名・コメントに反映できているか？」というものがあります。 ここで、「oに仮に認識主体を認めた場合」というのは、「もし、あなたがoそのものだったら」と読み替えて貰って構いません。頑張っ
「読みやすいコード」を依存グラフで考える
はじめに こんにちは、ダイニーの ogino です。 この記事では、コードの読みやすさを比較判断するために役立つメンタルモデルを紹介します。 本記事を読むと、「このコードは良い / 悪い」という感覚が身につき、その理由を自信を持って説明できるようになるはずです。 コードの読みやすさとは何か コードを読む時には大抵、何か特定の目的があります。例えば、 API /foo にリクエストした時の動作を知りたい、ある画面で発生しているバグの原因を知りたい、などです。 この時、コードベースの隅から隅まで読み尽くすのではなく、特定のポイントから出発して関連する箇所を芋蔓式に辿りながら読むはずです。 人が一度に理解して覚えておける情報量には限界があるので、辿らなければいけないコード量が少ないほど当然読みやすくなります。 つまり、ある目的に関連するコードの箇所が局所的かつ明示的であるほどコードは読みやすいと
Beautiful Code | IIJ Engineers Blog
2002年から約10年 IIJ技術研究所長. 年を取ってからは古い計算機や昔の計算法に興味が増し, シミュレーターを作ってそのプログラムを書いたり. 近頃はKnuthのTAOCPにあった問題のプログラムなどに挑戦したりしている. 【IIJ 2024 TECHアドベントカレンダー 12/3の記事です】 人生の長い間に亘ってプログラムを書いてきた. 最初は大学院生の時, 記憶装置のない加減乗算だけの計算機を作り, 紙テープから数値と計算の命令を読み入れ, 中間結果は一旦紙テープに書き出し, それをまた読み入れて計算を続けるという代物だったが, 初期のプログラミングの楽しさはあった. やがて研究室で, 今から見るとままごとのような小規模の計算機を組立てると, 私はライブラリプログラムの整備に熱中した. 大学で講義する身分になると, 次々と多くの計算機, 多くのプログラミング言語と付き合うことにな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
'Make invalid states unrepresentable' considered harmful | Lobsters
Lobsters Interview with Matklad | Lobsters
A programmer's field guide to assertions
Python!
Casey Muratori – The Big OOPs: Anatomy of a Thirty-five-year Mistake – BSC 2025
Stepanov’s biggest blunder
A break from programming languages
README.pdf)
Coding Isn't Programming
aposd-vs-clean-code/README.md at main · johnousterhout/aposd-vs-clean-code
How types make hard problems easy
Quantus Finance: Learn Financial Modeling for a New Career in Finance