Parse, don’t validate
Historically, I’ve struggled to find a concise, simple way to explain what it means to practice type-driven design. Too often, when someone asks me “How did you come up with this approach?” I find I can’t give them a satisfying answer. I know it didn’t just come to me in a vision—I have an iterative design process that doesn’t require plucking the “right” approach out of thin air—yet I haven’t bee
スーパー中学生誕生、プログラミング言語わずか数週間で開発、U-22プログラミング・コンテスト2019 - BCN＋R
「もっと人間にとって扱いやすい、自分の言語をつくってみたかった」。10月20日に東京の秋葉原コンベンションホールで開催された第40回「U-22プログラミング・コンテスト2019」の最終審査会で、見事、経済産業大臣賞（総合）を受賞した開成中学校3年の上原直人さん（15歳）は、独自プログラミング言語「Blawn」を発表した。IT業界の経営者など、並みいる審査員を驚かせたのは、完成度の高さはもちろんのこと、今年8月からわずか数週間で完成させたスピードだった。一次審査の応募期間7月1日～9月2日に着想から開発、完成まで一人で仕上げたという。 C言語を使ったのは今年7月 それまでPythonを使っていたという上原さんは発表の中で、「今年の7月か8月にC++を始めたが、扱いにくかった。もっと可読性の高い構文とメモリの安全性や速度を高めたいと思った」と、開発のきっかけについて語った。 質疑応答で審査員か
開発イテレーション偏重 - 兼雑記
開発イテレーションを早くすれば、かなりの問題が勝手に解決される、と信じています。なんか最近、他の要素を軽視しすぎていたり、特にイテレーション速度に影響しなさそうなことすらしている気がしていて、信仰とかのレベルかもしれない、という気がしてきたので、ちょっと書いてみようかなと。主に C++ の話です。 仕事とかしてると良い判断力が求められたりしますが、判断というのは結構難しいですよね。アプローチ A と B で悩んだ時に、手が速ければ両方できたりします。開発イテレーションを無限に速くすると、必要とされる判断力はゼロに漸近していきます。やったね。 2手で変更の正当性を高速に確認できるようにする make (かその他のビルドコマンド)てやったらビルドができて、 make check (かその他のテストスクリプト)てやったら遅くないテストが全部走る、という体勢が好きです。試すためにはあっちのディレク
Succinctness is Power
簡潔さは力なり---Succinctness is Power--- Paul Graham, May 2002. Copyright 2002 by Paul Graham. これは、Paul Graham：Succinctness is Power を、原著者の許可を得て翻訳・公開するものです。 プロジェクト杉田玄白正式参加テキスト。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2002 by Paul Graham 原文: http://www.paulgraham.com/power.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめ
The Law of Leaky Abstractions
I’m Joel Spolsky, a software developer in New York City. More about me. Read the archives in dead-tree format! Many of these articles have been collected into four books, available at your favorite bookstore. It’s an excellent way to read the site in the bath, or throw it at your boss. Ready to level up? Stack Overflow Jobs is the job site that puts the needs of developers first. Whether you want
プログラミングとは ― 最強のカレーレシピ ― - golden-luckyの日記
「うちの学校でもついにプログラミングの授業が始まったよ」 「それは興味深いね。どんなふうに教えてるの？ やっぱりScratchとか？」 「Scratch？ ああ、プログラミング言語のことか。プログラミング言語は使わなくていいんだよ」 「え？」 「小学校で学ぶプログラミングっていうのは、プログラミング言語を覚えさせることが目的じゃないからね。システム思考力とかロジカルシンキングって聞いたことあるだろ？」 「あるかないかでいったら、あるよ」 「プログラミング言語みたいなのは、単なる技術だ。それは仕事で必要な人だけが覚えればいい。子どもたちに教えるべきことは、プログラミング言語みたいな技術じゃなくて、システム思考やロジカルシンキングの延長といえるプログラミング的思考なんだよ」 「プログラミング的思考っていうのが、システム思考やロジカルシンキングとどう違うのか、いまいちよくわからないんだけど…」
プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな
プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか？」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自
技術的負債への後悔と返済｜Seiji Takahashi@ベースマキナ
反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの１つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負
プログラミングを目的にしてもいいと思う | κeenのHappy Hacκing Blog
文系でプログラマーになったけど色々失敗して３年半で会社を辞めた話｜denkigai｜noteという記事を読みました。 この記事に書かれていることが私の身にも覚えがあります。特に私と同い年の方のようなので自分に重ねてしまうところもあります。 ですが多少似たところはあってもやっぱり他人なので全然違う体験もしています。そういう体験を書いてみようと思います。もし該当記事を読んで絶望した人がいるなら別の例もあるよということで参考にしてください。 私は「パソコンの中身が知りたい。多分プログラミングとかいうやつを勉強したら分かる気がする。」くらいのモチベーションでプログラミングをはじめました。 ゴールがあやふやですし、結局のところ「プログラミングをする」が目標になってるので迷子になるのは必至ですね。実際そういう時期がありました。 そんな私でも今はプログラマとして生きています。以下に、私が遭遇した課題とそ
Cコンパイラ制作の夏期集中コースが思っていた以上にうまくいった話｜Rui Ueyama
2018年の夏に僕はセキュリティキャンプ（以下「セキュキャン」）というイベントでCコンパイラ作成コースの授業を行いました。授業はとてもうまくいったといってよいと思います。参加者は6人だったのですが、6人全員プログラミング技術がかなり飛躍的に向上したようですし、そのうち3人は期間中にセルフホスト（自分の書いているコンパイラで自分のコンパイラ自身をコンパイルできること）まで漕ぎ着けることができました。 この文章では、その授業をどのように僕が教えたのかということと、生徒にできるだけ多くのことを学んでもらって自信をつけてもらうために僕が何を気をつけていたのかという2つの点について説明します。 セキュキャンとはセキュキャンは5日間の合宿イベントで、学生を対象としてコンピュータセキュリティやプログラミングについて教えるというものです。いくつものコースが用意されているのですが、僕が受け持ったのは「集中コ
A page about call/cc
A page about call/cc [ENS] [ENS students] [David Madore] [Mathematics] [Computer science] [Programs] [Linux] [Literature] [What's new?] [What's cool?] [Site map] Table of contents What is call/cc? What is this page? A first introduction Who invented call/cc? What does call/cc stand for? Which programming languages have a call/cc function? Outgoing-only continuations: exceptions Exceptions in C: se
世の中にはプログラミングを理解できない人間が存在する
現在、C++によるプログラミングの入門書を書いているので、初心者のプログラミングの学習過程にとても興味がある。私自身も初心者の気持ちを取り戻すためにHaskellを学んでみた。最初の数日は頭が痛くなるほど難しかったが、そこを過ぎてみれば後は楽になってしまった。結局、初心者の気持ちはあまりわからなかった。結局、プログラミングの基礎はすでに学んでしまっているので、 先日、FizzBuzzがわからないから教えてくれという知人がいたので、これは初心者の気持ちを知るいい機会と話を聞いてみたところ、想像を絶する世界が見えてきた。 まずこれが動かないと悩んでいたコードだ。 for ( int i = 0 ; i <= 100 ; i++ ) { } else if ( i % 15 == 0 ) { Debug.log("FizzBuzz") ; } else if ( i % 3 == 0 ) { D
2016年、C言語はどう書くべきか (後編) | POSTD
(前編はこちら： 2016年、C言語はどう書くべきか (前編) ) (編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) システム依存の型 まだ「32 bitのプラットフォームでは32 bitのlong型、64 bitのプラットフォームでは64 bitのlong型がいい」という不満があるようですね。 プラットフォームに依存する2つの異なるサイズを使うため、 故意に コードを難しくすることを考えたくなければ、システム依存の型のために long を使おうとは思わないでしょう。 この状況では、プラットフォームのためにポインタ値を保持する整数型、 intptr_t を使うべきです。 モダン32-bitプラットフォームでは、 intptr_t は int32_t です。 モダン64-bitプラットフォームでは、 intptr_t は int64_t です。 int
2016年、C言語はどう書くべきか (前編) | POSTD
(訳注：2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注：著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例： 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり
ラムダ計算の勉強のしかた、プログラム意味論 - きしだのHatena
先日のエントリで手続きを記述するという側面と、式を記述するという2つの側面があるということを書きました。 プログラムの理論とはなにか そして、手続きの性質として代表的な、アルゴリズムについての勉強のしかたについてまとめてみました。 アルゴリズムの勉強のしかた そこで、今回は、式を記述するという側面の勉強のしかたと、あとこの分野は自分でもまだ全然勉強してなかったので、これからどういう本を読もうと思っているかをまとめてみます。 プログラム意味論 プログラムは必ずプログラム言語、少なくとも記号で記述します。*1 そこで、プログラムの勉強という点では、どのように動くかというアルゴリズムの勉強だけではなく、どのように書けるか、書いたものにどのような性質があるのかということも知る必要があります。 例えば、2005年あたりからRubyのような動的型付け言語が流行りだし、Javaなどの静的型付けの言語との
「プログラミングの宝箱 アルゴリズムとデータ構造」を読んでプログラミングについて考えたりした - razokulover publog
この年末休みはずっとCを勉強してた。 なんでCかというと、実は自分はCをやったことがなかったから。 情報系もとい理系全般の学部卒以上であればCは必修科目でやってると思うんだけど、自分の場合は文系だったのもあり触れてこなかった。 webエンジニアの人の中にはCなんてやらなくても大丈夫だよという先輩方がいると思うが、個人的にはあれは嘘だと思ってる。 普段使ってるツール(自分はRubyとかImagemagickとか)でCで書かれてるコードはクソたくさんあるがそれらの内部が読めないの本当に機会損失だと思う。 そうした事情があり、Cをやりはじめたわけ。 そんで、基本的なシンタックスとポインタの考え方とかがわかってくると最低限のコードは書けるようになった。 そこで次はCSの基本学習でもやるかとなり、ここやここで紹介されてたプログラミングの宝箱 アルゴリズムとデータ構造 第2版をやることにした。 この本
「車輪の再発明」を単純に否定することで失なっているもの - nobkzのブログ
anond.hatelabo.jp ソフトウェアの世界では、基本的には「車輪の再発明」は否定されている。しかしながら、本当にそうなのだろうか?と思うことが、最近、いや、ここやってきてずっと思っていることがある。そして、この匿名の記事を読んで、またなんとなく思うことをがんばってかいてみる。 車輪の再発明はなぜ否定されているのか?って、既にそれがあるのに、自分で開発したり発明したりするのが無駄だからだ。ここで、「無駄」って考えてみれば、社会全体として無駄であるだけで、個人の主観ではないのだ。既にある製品だったり、機能だったり、それを、再び開発するって行為は、その全体としては無益だが、もしかしたら、個人では、有益なものかもしれない。その製品の使い方が分からなかったり、そもそも知らなければ、その個人にとって「もう既にあるよ」は、まったく意味が無いのかもしれない。だって、その問題にあたったときにはそ
絵文字がある種のUnicodeバグを世界から一掃しつつある件について｜Rui Ueyama
UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Reddit - Dive into anything
Jens Gustedt, Modern C (PDF)