プログラマが今よりも楽をしてお金を稼ぐには

くっくっkura 🇯🇵🦀 @PG_kura

んー、そこで洗い出した依存関係で意味的に明らかな欠陥をあぶりだせるとして、それにどう対処するか、を考えたいところですねー。RT @tana_ash: @PG_kura そもそもプログラム全体で依存関係を自動的に解析して並列になるようにしたら最強なんじゃないかとw

くっくっkura 🇯🇵🦀 @PG_kura

・・・というのも、ボトルネックが例外だからであってw

くっくっkura 🇯🇵🦀 @PG_kura

非検査例外だとエラー耐性が弱すぎる一方、検査例外にするとコードの抽象化/共通化の能力を落とさざるを得ないから。

pokarim @pokarim

@PG_kura 個人的には、関数合成やコンビネータとしてのmapなどの組み合わせだけでプログラミングするのが良いのではと思ってます。仮引数、ポイント的なものを導入しない方が最適化しやすそうだと。

くっくっkura 🇯🇵🦀 @PG_kura

仮に依存関係が洗い出せたとしても、どんな例外がどんなところで発生するのか、その例外にどんな対応をするのか、っていうことを後付けでもいいから何かしら与えてあげられるようなものでないといけない。

めるぽん.am @melponn

@PG_kura 例外仕様もGenericsのパラメータ化しちゃいましょう！

くっくっkura 🇯🇵🦀 @PG_kura

メタプログラミング & 副作用なし、という観点でしょうか？RT @pokarim: @PG_kura 個人的には、関数合成やコンビネータとしてのmapなどの組み合わせだけでプログラミングするのが良いのではと思ってます。仮引数、ポイント的なものを導入しない方が最適化しやすそうだと。

くっくっkura 🇯🇵🦀 @PG_kura

それはありなのかもー、と思うですよ。でもほんとに解決したいのは発生する例外に対して妥当な対処をすること。RT @melponn: @PG_kura 例外仕様もGenericsのパラメータ化しちゃいましょう！

pokarim @pokarim

副作用の有無にかかわらず、HaskellのArrowのように抽象度の高い部品の組み合わせにした方が最適かも有利そうかなと。副作用は無くてすむなら無い方が良いですが。　RT @PG_kura: メタプログラミング & 副作用なし、という観点でしょうか？RT @pokarim:

くっくっkura 🇯🇵🦀 @PG_kura

あ、僕がこういうこと考えてるのは、コードそのものの堅牢性を高めるたいからじゃなくて、プログラマが今よりずっと楽をして金稼ぎしてほしいからです。

pokarim @pokarim

僕の場合はExcelなみに簡単でより強力な環境を作ってSIの必要性を無くしたいからです。 RT @PG_kura: PG_kura あ、僕がこういうこと考えてるのは、コードそのものの堅牢性を高めるたいからじゃなくて

くっくっkura 🇯🇵🦀 @PG_kura

@pokarim あ、post がかぶっちゃいましたが、→[http://twitter.com/PG_kura/status/19357486789] なので、抽象的なモノを組み合わせるのは大賛成なのですが、プロダクトに落とし込む過程で別の所で生まれる無駄を潰したいのです。

くっくっkura 🇯🇵🦀 @PG_kura

同意です。コンビニでレジ打ちしているバイトがその場でアプリケーションを練成して「2000 円になります」って売っちゃったりする時代が来たら万々歳です。RT @pokarim: 僕の場合はExcelなみに簡単でより強力な環境を作ってSIの必要性を無くしたいからです。 RT

pokarim @pokarim

@PG_kura 目的は一見違いますけどとるべき手段は近いかなと。プロダクトに落とし込むのではなくて、言語の部品の粒度を揚げておいてあとは処理系任せにできるような処理系を作ればいいのかなって。

くっくっkura 🇯🇵🦀 @PG_kura

プロジェクトの開始時は割と型のインターフェイスがどうだとか、仕様がどうだ、という話をしているのに、終盤になるとバグ曲線がどうだ、コミュニケーション能力がどうだ、という話に切替るのは、「道具であるプログラム言語を扱えていないから」で、その原因は「道具がしょぼいから」だと思う。

pokarim @pokarim

関数っていう、ひとつひとつの値を受け取ったときの処理を書くようなレベルのものを扱ってることが最適化の妨げになってると思う。集合から集合への対応やストリーム処理的なものをプリミティブにする必要がある。

Norihisa Fujita, ぽん @fjnli

.@PG_kura さんのつぶやきは、割とHaskellが近いのかなーと思ったり。望む所を100%実装しているわけではないけど、方向性として。

めるぽん.am @melponn

@PG_kura 「扱ってる人間がしょぼいから」という可能性も

pokarim @pokarim

同意です。仕様の変更が大事になるのも同じ。 RT @PG_kura: プロジェクトの開始時は割と型のインターフェイスがどうだとか、仕様がどうだ、という話をしているのに、終盤になるとバグ曲線がどうだ、コミュニケーション能力がどうだ、という話に切替るのは、

くっくっkura 🇯🇵🦀 @PG_kura

具現化したデータなり処理なりオブジェクトなりがまずあって、そいつらを個別に操作してたらきりがないほどにアプリケーションがリッチだからこそ、抽象化が意味を持つんであって。抽象的なものだけではアプリケーションは成立しないとです。

pokarim @pokarim

@PG_kura それは抽象化の仕方が悪いだけだと思います。道具がしょぼいのと同じで。

めるぽん.am @melponn

もっと言語をガチガチにしてしまって数学的アプローチとかの概念を十分に勉強しておかないとコンパイルすら通らないようなのにしておけば人間が勝手に進化するんじゃね？的な

くっくっkura 🇯🇵🦀 @PG_kura

お、そうなのですか。偉そうなことつぶやいてますが Haskell 知らないっていう・・・w RT @fjnli: .@PG_kura さんのつぶやきは、割とHaskellが近いのかなーと思ったり。望む所を100%実装しているわけではないけど、方向性として。

めるぽん.am @melponn

あーでもどういう方向に難しくするかで進化の方向が変わっちゃうかなぁ･･･全部アセンブラでとか嫌だ･･･

pokarim @pokarim

もちろん定数項までチューンしたければ話は別ですが。計算量のオーダーだけなら同じ処理ができるような抽象化の仕組みを考えればいいわけです。人が機械的にできる処理に落とせるなら理屈上は処理系にもできる。