【追記あり】ChatGPTじゃなくて人力でモナドが発明された経緯を適当に調べた（ソース付き）。 - Qiita
動機 最近、chatGPTにいろいろ尋ねるのが流行っているらしい。Haskellで有名なモナドの概念がなぜ導入されたか尋ねている人を見かけて、そういやそういう記事見たことないなと思ったので適当に調べた。 一次ソース 元ネタは以下のマイナーだと思われる文献 An abstract view of programming languages Eugenio Moggi教授のあんま読まれてない方の論文 Denotational Semantics Peter D. Mosses教授のこの論文（2部あって後半の方） 邦訳があり邦訳で読んだ。 プログラミングのモナド発見の経緯 プログラミングのモナドはなんか包んだり抜き出したり見たいな感じの概念で知られてますが、プログラミングの概念をモジュール化する機構云々の開発の前段階がある。そもそもリストだかIOだか例外処理だかの概念をそれぞれ一つのモジュールに
例外安全と例外中立 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 現代のC++で例外安全問題を抜きにして、障害に強い強固なコードを書くことはほとんど不可能に近い。以上。 Hurb Sutter [1] 例外処理における目的は、例外の回復と例外の通知の大きく2つあります。残念ながら例外の回復はとても難しく、場合によってはそもそも不可能だったりします。その場合、例外が発生したことをより上位のレイヤーに通知する事で例外処理を託します。この時、例外の通知を受け取った側は何を前提に例外の回復を行えばよいでしょうか。例外の発生によってデータ整合性は崩れてしまっているかもしれません。通知を受け取った上位レイヤーはあ
「この位置にｐｒｉｎｔｆが無いとなぜか動かないんだ。」 - Qiita
#include <stdio.h> void fizzbuzz(int n) { int next; int i = 1; do { printf(i % 15 ? i % 5 ? i % 3 ? "%d\n" : "Fizz\n" : "Buzz\n" : "FizzBuzz\n", i); if (i++ >= n) next = 0; } while (next); } int main(void) { printf((char[]){""}); // この位置にprintfが無いとなぜか動かない fizzbuzz(100); } gcc 10.1.0 を使用し、コンパイラが感知したミスには警告を出力してくれる様 -Wall -Wextra を指定し、最適化指示なしでコンパイル、動作させたところ動作するが Wandboxで実行 main() の中の何も出力していない printf(
DI (依存性注入) って何のためにするのかわからない人向けに頑張って説明してみる - Qiita
追記 2022/11/12 追記 この記事読んで、DI 便利だなって思ったらこちらも併せて読んでみてください。クリーンアーキテクチャーの開設の中で依存性逆転の説明が出てきます。難しいかもしれませんが、一度理解すればつぶしが効く考え方なので腰を据えて読んでみてください。 本文 ここでは、最近のそこそこの規模のアプリだと大体使われてる（と私は思ってる）Dependency Injection（DI）について、何故使ってるのか？というのを私の理解で書いていきたいと思います。 今回の対象言語は C# ですが、DI 使ってる言語であれば大体同じ事情なのかなと思います。 単体テストしたいよね アプリケーションを作るとうまく動いているかテストをすると思います。 たとえ、そのアプリがハローワールドだとしても動かして目視で確認してると思います。 もうちょっとアプリの規模が大きくなってくるとクラス単位やクラス
正しさとGo - Qiita
はじめに Goの良いところは、最低限の文法を知っていればコードを上から順番に読むことで詳細を容易に理解できることです。 文法の中にシンタックスシュガーや特別な省略が許されていないため多様な表現になることはありません。 そのためGoを書ければGoの本体と標準ライブラリを読むことができます。 しかし以下の原因により、これらの利点を守ることが難しくなることがあります。 DSL フレームワーク 抽象化 これらは設計として新たな制約を課すことで品質向上や実装を容易にするためのものです。 またこれらを採用する論理立てた 正しい 理由が存在します。 DSL DSLを提供するツールとして、DIのための wire があります。 GoでDIを実現するためには多くの実装を必要とするため、実装量を減らすためにもDIツールが求められてきました。 これは 正しい です。 しかし一方でDSLはコードを読む人間に言語以上
プログラミング言語の習得に必要なもの - Qiita
はじめに 先日、エンジニアの能力と今どきの難しさというタイトルの記事（2018年）を読んで、「これはほんとにその通り」と思う一方で、具体例がないためにピンと来ない人や、マウント取りではという意見も多数見られた。というわけで、自分が比較的得意な、プログラミング言語の構文解析といった分野に関して、この記事の言わんとしていることを補足するような記事を書こうと思い至った。 記事中では、エンジニアに必要な知識や経験を、「ベース」「カテゴリ」「実行環境」という形（以下）に分けて論じている。 ①ベース コンピュータサイエンス(CS)などの理論的なもの 低レイヤー ②カテゴリ フロントエンド / バックエンド / クライアントアプリなど ③実行環境 特定のプログラミング言語や開発環境やツール、フレームワークやライブラリなど この中で、特に印象的であり、かつ「よくわかる」と思ったのは以下の記述だ。 ③は比較
全言語で気をつけるべき、ファイル書き込み時のお作法 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 言いたいこと 重要なファイルを書くときは、予期しないOSシャットダウンなどを考慮した書き方にする必要があるというお話。 お作法を知らないと、中途半端なファイルや空ファイルが生成され、システム起動時や連携システムで致命的なことになる。 例としてC言語/Java/Python/JavaScript(node.js)を挙げるが、ほぼすべての言語で対策する必要あり。 背景 本番運用されているソフトウェアが起動しなくなるという致命的な不具合が発生した。 ログやコンフィグファイルを収集・解析したところ、コンフィグファイルがぶっ壊れていた。 コンフィ
規格書で比較するプログラミング言語の複雑さ - Qiita
言語仕様が一番複雑なプログラミング言語は何だろうか？主観的な意見として、○○の機能があるとか、ないとか、そういう話になるだろう。しかし、客観的に判断するとしたら、どうするべきだろうか？ 一つはBNFを用いた比較だろう。しかし、BNFは文法の複雑さの指標になっても、それらが意味するところの解釈の複雑さについては指標にならない。そこで、解釈を含めたその言語仕様を全てカバーしたもの、つまり、規格書を比較すればいいのではないかと考えた。 プログラミング言語によっては国際的な規格書が存在しないものもある。特にオープンソースで開発されている言語では、コミュニティーの合意によって作成された複数の文献によって仕様が形作られているというのもある。なかには、実装がそのまま仕様であり、明文化されていないものもあるだろう。また、仕様自体がHTMLである場合、それがどれぐらいの量であるかを把握するには難しい(各ペー
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
