はじめに 先日、エンジニアの能力と今どきの難しさというタイトルの記事（2018年）を読んで、「これはほんとにその通り」と思う一方で、具体例がないためにピンと来ない人や、マウント取りではという意見も多数見られた。というわけで、自分が比較的得意な、プログラミング言語の構文解析といった分野に関して、この記事の言わんとしていることを補足するような記事を書こうと思い至った。 記事中では、エンジニアに必要な知識や経験を、「ベース」「カテゴリ」「実行環境」という形（以下）に分けて論じている。 ①ベース コンピュータサイエンス(CS)などの理論的なもの 低レイヤー ②カテゴリ フロントエンド / バックエンド / クライアントアプリなど ③実行環境 特定のプログラミング言語や開発環境やツール、フレームワークやライブラリなど この中で、特に印象的であり、かつ「よくわかる」と思ったのは以下の記述だ。 ③は比較
Scalaの型システムには興味深い型が存在します。Scalaの型で述語論理を表現できないか、表現できるとしたら集合論をScalaで書けてしまわないだろうか、という興味から、Scala-proofsというプロジェクトを立ち上げて実験をしています。この記事は、Scala-proofsの中で使用する論理体系の表現手法について解説します。 Scalaのバージョン間で細かい話が変わってくるようですが、この記事はScala 2.12を前提とします。また、後述する理由から、Dotty/Scala3への移植性をできるだけ高めるために、Dottyで廃止される(予定?)の以下の機能を極力縛ることにします： 抽象HKT1へのワイルドカード_の適用 例えば、F: * -> *の実装が具体的に与えられていない場合、F[_]は型として違法 存在型 F[A] forSome { type A } 抽象型Tからの型投影T
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く