「メタプログラミング」を含む日記 RSS

はてなキーワード: メタプログラミングとは

2018-06-24

anond:20180624201120

僕が歳をとったのかもしれないけれども、

もうプログラミング言語メタ議論(メタプログラミングということではなく)、

にはすっかり飽きてしまった。

Kotlinは使いやすくてプログラミング言語全部入りJava遺産が使えて

良いと思います

2017-12-31

きれいなコードを書くのはやめた

きれいなコードを書け。コミットは細かく、メッセージをちゃんと書け。

そうずっと教えられてきたし努力してきた。

でも、もうきれいなコードを書くのはやめることにした。


業界2位のミドルウェアが、、1990年代タイムスリップたかのような継承拒否した継承構造で書かれていた。

世界的なOSSで3桁や4桁のスターがついているリポジトリコードは、コピペの嵐。巨大なマージコミットやFワード入りのコミットメッセージ

有名なスタートアップCTOコードは、メタプログラミング黒魔術の塊だった。

リードプログラマの同僚が、素早い機能追加で顧客から高く評価されている。

でも、それはコピペまみれで、巨大のコミットの汚いコードからできる。

自分バグのないきれいなコードを書くように心がけている。

同僚にくらべて、実装は遅い。そのことを叱責ばかりされる。


優秀なプログラマは、自分は quick and dirty なコードをかくくせに、 他人にはきれいなコード要求する。

ダブルスタンダードだ。

他人きれいなコード要求するのは、他人コードを読む時間を短くするためなのだろう。


優秀なプログラマになるために、私もきれいなコードをかくのはやめにすることにした。

2017-11-23

メタナントカ

例えば「AB」という概念があった時, 「ABAB」「ABのAB」「ABに関するAB」という概念も成立しうる場合, その概念は「メタAB」と呼べそうである.

あたりがぱっと思いつくけれど, 身近な例でも応用できないだろうか.

意外と難しい.

2017-04-16

http://anond.hatelabo.jp/20170416182310

私は長い Rubyist でいまも Ruby は愛しているが、最近 Python を使い出してから、これを認めざるを得なくなった。

Rubyメタプログラミングは、過激すぎて利益より弊害の方が多いのかもしれない。

Railsソースコードなんてとても追っかけられなもの

それに比べると Pythonコードのほうがずっと読みやすい。

2015-02-25

プログラマー魔法使い

プログラマー魔法使いウィザード)だ。

からMPを消費して魔法を使う。

MPっていうのはメンタルポイントで、めんどくさいポイントとも言う。

コード書くのめんどくせーという思いがメンタルポイントの消費につながる。

もちろんMPをたくさん使えばより強力な魔法(複雑な成果物)を詠唱コーディング)できる。

凄腕の魔法使いMPの消費効率を上げるスキルマスターしていたりする。DQ6賢者とかそんな感じだったろ。

あと弱い敵に対して、不必要に強力な呪文を唱えないってのもあるな。

メタプログラミングで作ったプログラムってのは、少ないMPで多いMPと同等の威力を出すアイテムに相当する。

クロノトリガーピアスみたいなもんだ。

で、何が言いたいかって言うとHP回復手段豊富にあっても、MP回復手段はそんなに用意されていないのがフツーのゲームバランスだってこと。

現実も同じ。

からちゃんとライブラ(適切な見積もり)覚えとけよ。

現実世界ライブラはかなり高度な呪文なので、ミナデイン的な唱え方(チームで見積もる)も必要場合があるぞ

2014-10-11

アプリ屋がRailsを初めて触ってみて感じた事

Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。

発想が古臭い

モバイルファーストAPIファースト文脈ハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLゴリゴリ生成するなんてよほど特殊最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLメタプログラミング等のテクニカル技法宝石のように鏤められている様はまるでエジプト時代骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。

モデルMVC

Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsクラスディレクトリという特定実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナル概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。

レールから外れる辛さ

Rails界隈の人がよく「Rails流儀」や「正しい"MVC"」というのを口角泡を飛ばし議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRails世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインサービスレイヤ名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別名前役割を与えられても正直しんどいので、皆が皆libゴミを放り込んでいく様子にも納得がいきました。

レイヤ?何それおいしいの

RailsAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsリファクタ手法と称されているものクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときセットポジションDDD青本を投げつける必要が有るなと思いました。

TDDやれんのか

ビューとコントローラを結合させた場合結合テストはCapybaraとかのBDDマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。

分業とか出来るんだろうか

ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーRubyバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。

RESTとかきついです

RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思いますGETbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTあくまリソース抽象化する美しい概念なので、アクション副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間しか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計拝借することはよしとしても、「○○はRESTでは無い故云々~」みたいな注文はやめて頂きたいものです。

そんなに嫌なら他に行けば

とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまサーバーサイド初心者感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います

だってRuby楽しいんだもの

2014-02-28

去年はじめから現在まで

2013年1月か2月

プログラミング経験、ほぼ皆無。

HTMLCSS, JavaScriptちょっとだけ分かる

dotinstallとか見てブラウザタイマー作ってわーいって喜んでるくらいのスキル感。

プログラミング勉強したい

勉強したいけどスクールとかはお金かかるから嫌だ

→本を買ってやるのは安上がりだけど途中で挫折しそう

→じゃあお金稼ぎながら学んだらいいんじゃ

プログラマバイト探そう

求人サイトで見つけて応募してみる

経験でも大丈夫らしい

バイト始めることになった

バイト始まる

はじめは研修アルゴリズムPHPについて

課題を出されて、できたら業務に入れる

フレームワーク使って指定されたwebサービスをつくる

基本自分の力でつくる。放置される

誰も教えてくれない

今思うと初心者やらせるのはなかなかハード

ググってググってググりまくる

他のできる子はさらさらっと1週間くらいで終える

ひーひー言いながら2~3週間でなんとか終えた

この期間、ほとんどプログラミング以外のことしてない

なんとかなった

3月4月

PHPドキュメントを読む習慣がつく

ググってコードコピペして動かしてみる、という段階

動くと楽しい 分かると楽しい

このときくらいにパーフェクトPHPを読んだ。FWは、つくれる!

FWがなんたるかをやっと理解し始める

あーようするにURLを受け取って振り分けたり、DBからデータ引っ張ってきて画面に表示させたりするのね

分かった気になる←分かってない

HTTPリクエストについて気にしだした

GET/POSTでごにょごにょすればいいんだね楽勝だわ←全然分かってない

フレームワークはいくつも種類があることを知る

このころ、Sinatraという言葉を小耳に挟む。支那虎?

5月6月

FuelPHPを聞きかじって、何をトチ狂ったのか在宅でwebサービス受託をやる

まあ良い経験になった

フレームワークいくつかやって、web開発のいろんな概念tipsがたくさん頭に入ってきて、

あーあれかーくらいには思えるようになった

DBCRUD操作, ORM, DBマイグレーション, RESTfulとは, コマンドラインコード生成,認証周りのプラクティス ...

7月くらい

さて、バイトが本格的?になってくる

一人で開発 責任おもい

機能追加のタスク

ごく一般的機能

でもなんか躓いた。

書いたコードに自信が持てない

これでいいのか不安になって手が進まない

やっぱり自分で考えて経験したことのないことはなかなか難しい

DBのテーブル構成を理解するにも骨が折れた 命名規則大事

セキュリティで手直しはたくさんもらった

フレームワークにはDB操作ライブラリがちゃんとついてるのにそれ見ずに自分SQL組み立てて案の定エスケープしてないし、とか

必要ないところでCSRF対策してるし、とか

でも、なんとか完成させた

プッシュして、マージされて、できちんと本番環境で動いてる。やったね。

8月9月

Rubyを知った

PHPと違って()が殆ど無いし、;ないし、do~endとか何だよって感じだった。

ちょっとだけ触ってみた。使いやす

Railsも知った

それからは空いている時間の大半をRubyRailsにつぎ込んだ

まずはRailsTutorialをやってみた

テスト周りでつまづいたけどなんとか終わらせた

dotinstallやらミニツクやら、検索して出てきた記事・チュートリアルはとりあえず手をつけて学んだ

はじめはRuby理解せずにRailsをやっていたけど、すぐにRuby自体に興味が出てきた

はじめてのRuby・はじめてのプログラミング・たのしRubyプログラミング言語Ruby... 入門系の本を乱読した

PHPでさんざん苦労していたからか、Rubyオブジェクト指向を学ぶとなんの無理もなく頭に入ってきた

Rubyドキュメントの読み方を覚えた

その後、パーフェクトRubyで標準ライブラリやらGemやらSinatra支那虎じゃなかった)やらについて学んだり、

メタプログラミングRubyで黒魔術を学んだりした。巻頭のMatz言葉痺れたなー

バイトのほうも何とかこなせるようになってきた 成長すげー

9月10月11月

Vagrantをかじる

インフラ・ミドルネットワーク周りに興味がでてくる

AWSでいろいろ遊ぶ

メタプログラミングRubyは断続的に2~3回ほど読み返す

Rubyってほんと使ってて楽しい

webスクレイピングとか検索APIとか使ってムフフ画像をアハーンしたりして遊んでた

11月12月

Rubyと名のつく書籍を読みあさる

Ruby言語をつくろうだの、スクリプティングを極めようだの、JavaRubyがどうだの。

メタプログラミングだの、デザインパターンだの、テストだの、リファクタリングだの。

借りられる本は借りて済ませた。全部買ってると破産する

他にもRubyとつかない本もいろいろ。

達人プログラマーは途中で挫折した。そのうちもう一度読む

プログラマが知りたい97の何とか。いい本

Ruby関数オブジェクトからのつながりで関数型プログラミングにも手が伸びる

OOPと全く違う。

2014年1月2月

就活はじめるよー

まあ、エンジニア枠で探すことにする

エントリーめんどくさい

ので、1社受けて落ちたら次の会社エントリーするという作戦にした

無計画玉砕作戦

はいえ、なんとかなると思ってやってく

気を揉む期間

いろいろな会社採用ページ眺めていると気になること

入ってやる仕事の内容が分からない

やたらパララックスつかってゴテゴテにしてるわりに、何が言いたいのか伝わってこない

せめてよく使ってる言語くらいはのっけておいて欲しい。

気になる会社はいろいろ調べる

で、1社選んで応募して、選考が始まった

面接、失敗したなと思ったところもあったが

嘘つかない

知らないことを知ってるように話さな

は通せたので良かったと思う。

で、進んでいって最終面接。これもなんかよく分からないうちに終わってた

相手が適宜フォロー入れて話しやすいようにしてくれたのは覚えてる

うん、ぜひ当社にご入社いただけたらと思いますとのこと。やったね。

から気になってた会社ではあった。勝手リスペクトしてた会社

自分が憧れてる技術者さんたちが在籍してる会社でこれから働くことができる

いろいろと運が良かった。嬉しい

他の会社はどうしようかな。

受けてみたい気もするけれど、エントリーがめんどくさい

続けるかどうかは未定だけど、ひとまず休憩することにする

今は、関数型言語についての本買って読んでる。関数型、Rubyに劣らず楽しい

2011-09-23

「続 新しいプログラミングパラダイム」の目次


第1章 並行プログラミングGHC (上田和紀)
	1.1 はじめに
	1.2 ターゲットを明確にしよう
	1.3 はじめが大切
	1.4 GHCが与える並行計算の枠組み
		1.4.1 GHCにおける計算とは,外界との情報のやりとり(通信)である
		1.4.2 計算を行う主体は,互いに,および外界と通信し合うプロセスの集まりである
		1.4.3 プロセスは,停止するとは限らない
		1.4.4 プロセスは,開いた系(open system)をモデル化する
		1.4.5 情報とは変数と値との結付き(結合)のことである
		1.4.6 プロセスは,結合の観測と生成を行う
		1.4.7 プロセスは,書換え規則を用いて定義する
		1.4.8 通信は,プロセス間の共有変数を用いて行う
		1.4.9 外貨も,プロセスとしてモデル化される
		1.4.10 通信は,非同期的である
		1.4.11 プロセスのふるまいは,非決定的でありうる
	1.5 もう少し具体的なパラダイム
		1.5.1 ストリームと双方向通信
		1.5.2 履歴のあるオブジェクト表現
		1.5.3 データ駆動計算と要求駆動計算
		1.5.4 モジュラリティと差分プログラミング
		1.5.5 プロセスによるデータ表現
	1.6 歴史的背景と文献案内
	1.7 並行プログラミング効率
	1.8 まとめ


第2章 様相論理テンポラル・プログラミング (桜川貴司)
	2.1 はじめに
	2.2 様相論理
	2.3 時制論理
	2.4 多世界モデル
	2.5 到達可能性と局所性
	2.6 純論理プログラミングへ向けて
	2.7 Temporal Prolog
	2.8 RACCO
	2.9 実現
	2.10 まとめと参考文献案内


第3章 レコードプログラミング (横田一正)
	3.1 はじめに
	3.2 レコードと述語の表現
	3.3 レコード構造とφ-項
		3.3.1 φ-項の定義
		3.3.2 型の半順序と束
		3.3.3 KBLLOGIN
	3.4 応用――データベース視点から
		3.4.1 演繹データベース
		3.4.2 レコードプログラミングデータベース
		3.4.3 いくつかの例
	3.5 まとめ
	3.6 文献案内


第4章 抽象データ型とOBJ2 (二木厚吉・中川 中)
	4.1 はじめに
	4.2 抽象データ型と代数言語
		4.2.1 抽象データ型
		4.2.2 代数言語
		4.2.3 始代数
		4.2.4 項代数
		4.2.5 項書換えシステム
	4.3 OBJ2
		4.3.1 OBJ2の基本構造
		4.3.2 モジュールの参照方法
		4.3.3 混置関数記号
		4.3.4 モジュールパラメータ化
		4.3.5 パラメータ機構による高階関数記述
		4.3.6 順序ソート
		4.3.7 属性つきパターンマッチング
		4.3.8 評価戦略の指定
		4.3.9 モジュール表現
	4.4 おわりに


第5章 プログラム代数FP (富樫 敦)
	5.1 はじめに
	5.2 プログラミングシステム FP
		5.2.1 オブジェクト
		5.2.2 基本関数
		5.2.3 プログラム構成子
		5.2.4 関数定義
		5.2.5 FPプログラミングスタイル
	5.3 プログラム代数
		5.3.1 プログラム代数則
		5.3.2 代数則の証明
		5.3.3 代数則とプログラム
	5.4 ラムダ計算拡張
		5.4.1 ラムダ式拡張
		5.4.2 拡張されたラムダ計算の簡約規則
		5.4.3 そのほかのリスト操作演算子
		5.4.4 相互再帰定義式
		5.4.5 ストリーム(無限リスト)処理
	5.5 FPプログラム翻訳
		5.5.1 オブジェクト翻訳
		5.5.2 基本関数翻訳
		5.5.3 プログラム構成子の翻訳
		5.5.4 簡約規則を用いた代数則の検証
	5.6 おわりに


第6章 カテゴリカル・プログラミング (横内寛文)
	6.1 はじめに
	6.2 値からルフィズムへ
	6.3 カテゴリカル・コンビネータ
		6.3.1 ラムダ計算意味論
		6.3.2 モルフィズムによる意味論
		6.3.3 カテゴリカル・コンビネータ理論CCL
	6.4 関数型プログラミングへの応用
		6.4.1 関数型プログラミング言語ML/O
		6.4.2 CCLの拡張
		6.4.3 CCLに基づいた処理系
		6.4.4 公理系に基づいた最適化
	6.5 まとめ


第7章 最大公約数――普遍代数多項式イデアル自動証明におけるユークリッドの互除法 (外山芳人)
	7.1 はじめに
	7.2 完備化アルゴリズム
		7.2.1 グラス置換えパズル
		7.2.2 リダクションシステム
		7.2.3 完備なシステム
		7.2.4 完備化
		7.2.5 パズルの答
	7.3 普遍代数における完備化アルゴリズム
		7.3.1 群論の語の問題
		7.3.2 群の公理の完備化
		7.3.3 Knuth-Bendix完備化アルゴリズム
	7.4 多項式イデアル理論における完備化アルゴリズム
		7.4.1 ユークリッドの互除法
		7.4.2 多項式イデアル
		7.4.3 Buchbergerアルゴリズム
	7.5 一階述語論理における完備化アルゴリズム
		7.5.1 レゾリューション法
		7.5.2 Hsiangのアイデア
	7.6 おわりに


第8章 構成的プログラミング (林 晋)
	8.1 構成的プログラミング?
	8.2 型付きラムダ計算
	8.3 論理としての型付きラムダ計算
	8.4 構成的プログラミングとは
	8.5 構成的プログラミングにおける再帰呼び出し
	8.6 おわりに:構成的プログラミング未来はあるか?


第9章 メタプログラミングリフレクション (田中二郎)
	9.1 はじめに
	9.2 計算システム
		9.2.1 因果結合システム
		9.2.2 メタシステム
		9.2.3 リフレクティブシステム
	9.3 3-Lisp
	9.4 リフレクティブタワー
	9.5 GHCにおけるリフレクション
		9.5.1 並列論理言語GHC
		9.5.2 GHC言語仕様
		9.5.3 GHCメタインタプリタ
		9.5.4 リフレクティブ述語のインプリメント
	9.6 まとめ

2011-02-11

http://anond.hatelabo.jp/20110210084023

ブクマに「IDEのLLサポートが進めばJavaの優位性はない」とか言っている御仁がいるが、LLの記述の簡潔さの源は、メタプログラミングの多用による疎結合の実現(=機械的に補完しにくい)ではないのか。俺には、彼が何を言っているのか分からない。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん