「型推論」を含む日記 RSS

はてなキーワード: 型推論とは

2018-10-26

気づいたら変わっているもの

緩やかに変化を続けていて、気づいたら全く別のものに変わっているものが好きです。

例えば、TypeScriptの型システム最初シンプル型推論と型指定だったはずなのに、最近は複雑な型の設計がメインの作業になりつつあります

あるいはタプル的な要素を突っ込んだりしていて、当初のものとは明らかに違う構想が始まっています

TypeScriptバージョンアップのたびに変更を突っ込んできていて、しかもそれが追加機能というよりは機能改善なので1つずつ追わないとつらいですね。

Reactとかもそんな気があり、エコシステムもまた変わりそうな気配があります。今回の変更もまた根本的ですし、改善案も攻めてます

スポーツでも派手なフェイントは見栄えはいいですが、すぐにバレます。全身の位置関係を変えずに、等速で変化するのが一番だましやすいです。

人の成長とかも、かなり低速、等速なので、一緒にいると気づかれにくいですよね。

あとは思いつかないですけど、こうやって徐々に変化して見えないうちに置き去りにするという感覚が本当に好きです。

早すぎて見えないのも格好いいですが、遅すぎて見えないというのも同じように素敵だと思いませんか。

2018-06-12

C#Javaでvarを使うべきでないという人を見ると

型推論と、動的型やバリアント型と区別がついてるのかなと心配になる。

2018-03-20

anond:20180320150537

型推論の結果がまちがってたらどうすんだよ。

型推論ときコンピュータにやってほしい

おれはできないけどおまえらならできるんじゃないか

Java界隈でvarに関する議論がおきているらしいが

C#に導入されたときネットで「使うべきでない」「乱用すべきでない」「使いどころがない」みたいなことを言っていた人たちの9割くらいは、型推論と、バリアント型や動的型の区別がついてなかったと思う。

2017-02-01

http://anond.hatelabo.jp/20170201160608

システムハンガリアンはIDEの発達や型推論で廃れた。変数ポインタを当てるだけで型がわかる。

アプリケーションハンガリアンは、自分もメンバ変数btn~にしたり~Buttonにしたり迷ってたりしてたが、プロパティとして公開するときはハンガリアンにするわけにはいかないので、結局ハンガリアンをやめた。プロパティとメンバ変数機械的対応が取れてたほうが便利。"_プロパティ名"とかにしてしまう。

型よりもその変数意味のほうが重要だという考え方がハンガリアンが廃れた大もとの原因だろう。最近IDE中間一致で補完するのが主流なので、Buttonと打てばボタン一覧が出てくる。

2015-05-13

http://anond.hatelabo.jp/20150513102607

型推論関数関係あるんか?

そもそも動的型付けか静的型付けかは、関数型とはあんま関係なくね?

http://anond.hatelabo.jp/20150513101717

お前は型推論のあるマトモな関数型言語やってから出直して来い

Ruby見たときもコレのどこに関数型のエッセンスがあるんだとか思ったもんだ

今なら何を言ってるかわからんでもないが、

こういう勘違い野郎大量生産した元凶だとも思う

2015-04-18

プログラミングをやってると簡単に優越感を感じられる。マジおすすめ

型推論と動的型の区別がつかない人とか、参照渡しと参照変数の値渡しの区別がつかないとか、自分が一瞬で理解できた概念理解できない人が世の中にはいっぱいいるらしいと知ると嬉しくなる。

2014-06-04

プログラミング言語字面だけで理解してる人たち

swiftJavascriptとかLLみたいに言ってる人沢山いたけど、あれって変数宣言がvarだとか、見た目がスッキリしてるとかそういう印象だけで言ってるんだよね。

以前、C#型推論が導入されたときも(っていうか今でも)動的型やバリアント型と区別がつかなくて「使うな」「バグの元」みたいに言ってる人よくいたし。

あと、C++, Perl, Java, C#, Javascriptあたりをまとめて「C系の言語」と言ってPythonやらRubyみたいな言語比較する文脈で「似てるから」おぼえやすいとかいう人とか。

VB6をやっていてVB.NETなら移行しやすいと思っていて「ぜんぜん違う言語だよ」って言われて驚く人とか。

共通のキーワードを使ってるとかぱっと見た目が似てたら、同じような言語と思ってしまう層がけっこうな量で存在するみたいで、そういう人たちも一応コードを書けてるんだよね。

そういう人たちの脳内ではプログラミングってどう認識されているんだろうか。永遠にからないと思うけど疑問に思ってしまう。

2013-09-22

http://anond.hatelabo.jp/20130922000614

元増田です。

  

そのためのデータ管理という項目をコンピュータ教育指導要領に含めるべきだって話です。

代替オフィスへ移行しても「名前重要なのは変わらないですし、互換性問題からマークアップ」も必要とすべきです。

  

マークアッププログラミング型推論のように行われる可能性は軽量マークアップ言語の登場からあり得ない話では無くなってますけど、それに至るまでは時間が沢山必要だと言って良いはずです。

僕は別に憲法のような確固たる可能な限り変えるべきではないルールとしてデータ管理からコンピュータ教育を推しているわけではないです。

  

ただデータ管理は少なくとも僕の寿命が尽きても広く使われるはずだ。この意見IT業界関係者ならば否定のしようがないことだと思います

SF的な量子コンピュータが使われようがデータ管理はされるし、一般ユーザはしなければならない。違いますか?

2013-06-18

よくわかんない

>静的型付け言語で、

>できれば型推論があって、

これって同時に成り立たせる必要あるの?

http://anond.hatelabo.jp/20130618162024

C++に大きく劣らない速度がある静的型付け言語で、

できれば型推論があって、

D言語くらいの明解言語仕様があって、

pythonのnumpyやscipy並のライブラリがあって、

ネイティブC/C++との接続が簡単な言語が欲しいです。

ないですか?

2013-06-16

理想プログラミング言語

http://anond.hatelabo.jp/20130614232508

処理系
  • 見通しの良い非同期処理 → Groovyか?
  • 使える環境はできるだけ多いとうれしい → Groovy
  • 起動速度が速い → Groovyか?
  • 実行速度ができるだけ速い → Groovy
まとめ

Groovy

2013-06-15

http://anond.hatelabo.jp/20130614232508

いわゆる「LL」ではないけど、Scalaを挙げておきたい。希望の要件はおおむね満たしてると思うけど、以下注釈

val users = service.getUsers // 1
val result = users.map { users => users.filter { u =>
  u.name.head == 'T' // 2
}}.flatMap { users => Future.traverse(users) { user =>
  db.write(user.id, user.name) // 3
}}

result.onSuccess { case _ =>
  println("Success!") // 4
}
// '=>'がうまく書けなかったので全角になってる。

2013-06-14

理想プログラミング言語

普段Perlを書いているんだけど、言語機能として欲しい機能ライブラリ任せだったりしていろいろしんどい

かいプログラミング言語はないかなーと思っているんだけど、なかなか自分の好みとピタリとくるものがない。まぁ好みにピタリとくるものなんかプログラミング言語に限らずないんだろうけど。

なので夢想してたのを垂れ流してみる。最近OOPディスのエントリとかあったので話題作りになれば。

Web系のエンジニアなのでWebサービス作ることが前提で、範囲広げすぎるとまとまらないので今回はLLを想定してる。

だいたい PHP, Perl, Python, Ruby, JavaScript あたりをイメージしながら、さらにこんな機能があればいいなーと思って書いたよ。

言語仕様
処理系
まとめ

2013-05-14

プログラミング大好き男に「どの言語が好き?」と訊ねられたとき、女はどう答えたらいいの?

あ、まず前提として、

貴女プログラミング大好き男を夢中にさせることが、

はたして貴女幸福にするかどうか、それはまた別問題だけれど。

はいえ、プログラミング大好き男たちは玉石混交ながら、

IT系の超かしこい男なども多く、

多くっつーかIT系でないのにプログラミング大好き男っていうのは超かしこ学生まぁこれは有望株)か研究者系なんか、

あとはまったくかしこくもないクセに頭いいつもりして「Lispやってます(キリッ ハローワールドくらいですが」とか言っちゃうアホしかいないわけで、

したがって、釣り師たる女たちにとっては、

なかなかあなどれない釣り場です。

では、プログラミング大好き男に「どの言語が好き?」と訊ねられたとき

貴女は、どう答えれば理想的でしょう?

まず最初に、その男COBOLのようなタイプレガシーコード

あとはC/C++、そして(TechEdに参加するほどではないけれど)VisualBasicが大好きな、

そんなタイプ場合は、

貴女はかれの目を見て、微笑みとともに質問など無視して、こう言いましょう、

「わたしが、仕様書を作ってあげる♪」

これこそまさに必殺の答えです。

そこでプログラミング大好き男が、えへへ、とやにさがったならば、

貴女は、ひそかに、「コピペ量産しやすい技術的ポイントを抑えた仕様書」あたりを

ひそかに練習しておきましょう。これで成功まちがいなしです。

しかし、ここでは、もう少しハイブロウな(?)いわゆるプログラミング好きの男の

落とし方をお伝えしましょう。

この場合貴女は、こう答えましょう、

「わたしは、JVM上のScalaが好き。

型推論もあるしラムダ式クロージャスクリプト言語みたいに書けるの、豊富組み込みのコレクションメソッドはいつも便利だし、

XMLリテラルCaseクラスによるパターンマッチもTraitベースMixi-inも、大好き♪」

もしも貴女がそう答えたならば、

その瞬間、プログラミング大好き男の目はきらりと輝き、

かれの貴女への恋心は、

20%増量になるでしょう。

なぜって、Scalaは、

ちょっぴりお洒落Ruby風味に記述できて、

Maybeモナド差し込んで、

コンパイルは遅いながらも、そこがまた

ちょっぴりメモリを多く積めばいい富豪プログラミングみたいなふんいきをかもしだしていて。

しか関数型言語としての不変変数・不変Listを実装して

質高くふるまっていて、なおかつ、

JVM上で動くくせにJavaが「やるやる」と言ったまま実装してなかったラムダ式と仮想拡張メソッド型推論を実装した功績もあって。

したがってScalaこそは、

本来なんの接点もないまったく縁もゆかりもない別々の世界に生きている、

インタプリタ言語大好きな綺麗系OLと、玉もあれば石も混じっている、そんなプログラミング大好き男たちが、

この世界で唯一(いいえ、JVM系列のJRubyClojure と並んで唯三)遭遇しうる場所です。


では、参考までに、危険な回答を挙げておきましょう。

プログラミング大好き男に「どの言語が好き?」と訊ねられたとき

貴女がこう答えたとしましょう、

MicrosoftVisual Basic for Applicationが好き♪ 週3回は Excelコーディングするの。」

その瞬間、プログラミング大好き男の貴女への恋心は消えます、

なるほどMicrosoftは、世界最大のOS供給メーカー

特にOfficeは平凡ながら、ま、無難にまとめてあるものの、

しかし、「新UIのリボンUI!」「メトロUI対応!」とかなんとか無意味な自慢を吹聴し、

VBAはさらプログラミングについての謬見を撒き散らした罪がありますからプログラミング大好き男にとっては天敵なんです。

ティーガー戦車乗りのオットー・カリウスは「ティーガー乗りなら誰でも片側の履帯がはずれ僚車に牽引されて帰ってきた経験を持つはずだ」 って言ったけど

社内SESIerなら誰でもクソみたいな前任者が書いたクソみたいなExcel-VBAコードを直した経験があるはずなんです。

また、もしも貴女が「PHPが大好き♪ あたしが書いたPHPのWebサイトが、さくらサーバに7件あるよ♪」

と答えたとしても、同様の効果をもたらすでしょう、

なぜって、PHPは、1990年代にはWeb系を目指す人にとっては簡単で要件を満たすWebサイトが簡単に作れる輝きの道だったものの、

しかし2000年代うそうからセキュリティ関係の問題で転落し、

いまや、あの貧弱な言語能力では、Rubyの魅力に遥かに及びません。

(注1)

またもしもたとえあなたプログラミング言語が大好きで、

「わたし、.NET FrameworkのC#が好き、フォームアプリでも書くけど、

最高に好きなのはASP.net♪ SQLServer連携も、ajax control toolkitもすっごくおいしいの。」

と、答えたとしたらどうでしょう

なるほど、貴女の趣味は高く、

しか.NET Frameworkは、C# が cool であるのみならず、

.NET Framework上で動く F# や IronPythonIronRubyマネーJScriptも最高においしいんですけれど、

しかし、貴女の答えを聞いて、プログラミング大好き男はきっとおもうでしょう、

(なんだよ、MS信者な女だな、カネかかりそう)って。

(注2)

貴女が、プログラミングが大好きで、言語の名を挙げるにしても、

たとえば、JavaScript(node.js)ならば安心でしょう、

なぜならば、JavaScriptは、かけだしのプログラミング初心者にもマニアにもともに愛されるめずらしい言語で、

貴女がその名前を挙げても必ずしも、(jQueryがやっとの初心者と思われることはあっても)あなたプログラミング言語おた宣言をしているとは受け取られないでしょう。

しろへぇ。ちゃんとprototypeは使ってる?」と聞かれたら「当たり前じゃない。むしろnode.jsでいいMVCフレームワークが分からないんだけど…」と話を振ってみましょう。

男は嬉々として、30個くらいのnode.jsフレームワークを教えてくれることでしょう。(まぁどれもどれで帯に短し襷に長しなんですが)

あるいはRighno上で動かしたコードをnodeへ移植する話とか、CoffeeScript、甚だしきはClojureScriptを振ってみてもいいかもしれません。

しかし、たとえば、世界が(つーか竹内先生ポール・グレアムが)誇る超絶関数型言語の名作、Common Lispにせよ、

selfと書きまくることと海外で使われてることに定評のあるPythonにせよ、

バージョンアップごとに言語仕様が変わり、かなり素敵なものではあるもののobsolatedな罠にはまりやすRubyにせよ、

まったく読めない$_だらけで頭悪い仕様リセットしてPerl6にする(そしてまた全く読めない)Perlにせよ、

気さくなクジラ飛行机さんがふるまう素敵においしい日本語プログラミング言語ひまわりなでしこにせよ、

基地外トリッキー言語の代表BrainFxck・Glass・Missa・WhiteSpaceにせよ、

そういう言語名前をいきなり挙げるのは、ちょっぴり微妙。

ましてや貴女が、「Haskellが大好き♪ わたし、プロジェクトオイラーの問題もうほとんどHaskellで、解いちゃった♪」

と答えたならば、どうでしょう

これはかなり博打な答え方で、

なるほど、Haskellは、純粋関数型でありつつも副作用のある操作が行える超絶名言語ゆえ、

あなたがそう答えた瞬間、プログラミング大好き男がいきなり超笑顔になって、

へぇ、やっぱりHaskellなら大抵の問題は4行以内くらいで解いちゃった?」とか言いながら

鼻の下がだら~んと伸びちゃう可能性もあるにはありますが、

しかし、逆に、(なんだよ、この女、プログラミングおたくかよ)とおもわれて、どん引きされる可能性もまた大です、

なぜって、必ずしもプログラミング大好き男がプログラミング大好き女を好きになるとは、限らないですから

しかも、この答えには、もうひとつ問題があって、

男たちは、女を導き高みへ引き上げてあげることが大好きゆえ、

もしも貴女が、「Haskellが大好き♪」なんて言ってしまうと、

そこにはもはや、男が貴女圏論モナド教育する余地がまったく残されていません、

したがって貴女のその答えは、

プログラミング大好き男の貴女への夢を潰してしまうことに他なりません。

ま、ざっとそんな感じです、貴女の目にはプログラマーたちはバカでスケベで鈍感に見えるでしょうが

しかし、ああ見せて、プログラマープログラマーで繊細で、おざなりに扱われると傷つきやすく、ローカル変数名前一つにも気を使い、女と自分の将来に夢を持っています、

貴女の答え方ひとつで、プログラマー貴女への夢は大きくふくらみもすれば、

一瞬で、しぼんでしまいもするでしょう。


では、スキットを繰り返しましょう。

「わたしは、JVM上のScalaが好き。

型推論もあるしラムダ式クロージャスクリプト言語みたいに書けるの、豊富組み込みのコレクションメソッドはいつも便利だし、

XMLリテラルCaseクラスによるパターンマッチもTraitベースMixi-inも、大好き♪」

そして、その瞬間、プログラミング大好き男の目がらんらんと輝いたなら、

貴女はこう重ねましょう、

それからね、いま、わたしが使ってみたいWebアーキテクチャは、

Play Framework、素敵なリアルタイム嗜好のアーキテクチャって噂を聞いたから。

あなたのお暇なときがあったら、わたしをPlayへ連れてって♪」

これでもう完璧です。

PlayFrameworkと、Play(遊ぶ・じゃれる)のダブルミーニングでかれの股間も刺激しちゃえます。

そうなったらこっちのもの

デートの日には、ペアプロ用に Happy Hacking Keyboard をばっちり決めて、かわいい下着をつけて(注3)、

github.comの通販で売ってるoctcatのTシャツか、facebookの「いいね!ボタンがムネのところにあるTシャツ、 あるいは初音ミク(ないし彼のお気に入りアニメキャラ。北米ならMyLittlePonyで鉄板なんだけど)のコスプレを着てゆきましょう。

その日からプログラミング大好き男は貴女の虜になるでしょう。

では、釣り師としての貴女の、愛の幸運幸福をお祈りします!

注1:

(と、書いたもののPHPの現状をよく知りません。グローバル変数だらけになるのとか旧ASPみたいなもんなのかなぁ。count($array); とか書くのアホと思うがpythonも同じだった)

(あと、マジで機能とかTwitter連携とか診断メーカー的なのでもPHPで7つも作ってる女子居たら付き合いたい)

注2:

もっとも。objective-Cなんていう言語をやることに比べれば個人で行う程度なら金のかからない手法もなくはないのですが。

注3:

プログラマーにとっての「かわいい下着」と、女性にとっての「かわいい下着」の定義にずれがあるので注意。

半数くらいのプログラマーしましまぱんつが可愛いと思ってる気がするので、妙齢の女性が着用するには抵抗あると思うが、ボーダー柄のコットンショーツ(ただしキャラ絵のは除く)とか、

過度でないていどにフリルがついたものオススメ。また、色は、レッドだとプログラミング大好き男は引いてしまう(だってそれはコンパイルエラーときの色だ)ので、薄ピンクホワイト、薄ブルー、せめて黒(に差し色でピンクとか)あたりに留めたい。

補記:

 元ネタhttp://tabelog.com/tokyo/A1301/A130101/13002457/dtlrvwlst/3464106/

補記2:

  「プログラマー」か「プログラマ」かの問題については、特に意味は無いが前者を採用した。

補記3:

 言うまでも無いけど、ネタです。 

 また、COBOLとVB、C++ではまったくもって難易度が違うことも分かっています。後者になるほど圧倒的に難しい。

2013-04-05

JavaScript Lover

いっせーの!

Webにのって さあ出かけよう
ブラウザとのランデブー
ユーザー大事 実装が大事
JS、マジ大好き

ユーザーの痛み それ言語のせい?
UIの動き UXのつもり
今までのJSポジションを
越えた未来は どうなるの?

ねぇどうせWebKitでしよ ダメ?
ダメ! ECMA標準だけ
油断も隙もない
APIとのボーダー越えたい

そうもっと!

大胆で ちょっと強引?
俺ワールド全開
優しいJSも いじわるなJSひとりじめ

型つけてみて やっぱやめて
ウラハラ alt-js
Java以上C++未満の
JS、マジ最高

V8けが きらめいて
遠い背中も 追いかけたよ

これから最適化
フローグラフの分まで伝えたい
ぎゅってしてPNaClコンパイル ダメ?
ダメ! 不埒です

CSS3に甘えたい
GPUに触れたい
どこまで? APIボーダー教えて

おっとっと!

手強い IEの仇
ムキになったら
古いシステムFlashの将来も
譲れない

実装して やっぱやめて
一方通行プロセス
W3C信じて
プラグイン書いて
No more E4X

動的なの? 静的なの? 型推論好き?
好き!
好きだからわず答えて
Ion Monkey 越えよう

おっとっと!

大胆で ちょっと強引?
prototypeを知ったら
JSでの設計コーディングも変わるの?
答えてよ!

ときめき 走り出す
わくわくコーディング
Self以上 Scheme未満の
JS、超愛してる!!

「Girlish Lover」 PV

2013-03-03

http://anond.hatelabo.jp/20130303135038

元記事はそんなに外してもいないと思いますけどね。

静的型付き言語として関数型言語を持ち出してくるのは、論点が違うような気がしました。

静的型、型推論の嬉しさって、関数が一級かどうかでも違ってくると思いますし。

(つまり、静的型の得失について、scheme vs ML での議論と Java vs Perl の議論は別物だと思います)

結局は適材適所という結論にしかならないと思いますが、たとえば Web 系なら静的型付き言語で書いても面倒臭さの方が多そうです。

Web 系で一番面倒なのは文字列の扱いなので。そこは型システムで何も解決しないですよね。

そういうことより、文字列関数名として $funcName(arg1, arg2) みたいにコールできたりとか、

そういう柔軟さが便利なのですよね。

こういうの、静的型がある言語だと大変ですよね。Java ならリフレクションですよね。

他の言語ではどうするのでしょう。おそらく、自前で関数テーブルを作ることになるでしょうか。

静的型を持たない言語での開発が、大規模になると破綻するというようなことが言われます

別に破綻しませんよ。

大規模開発といっても、大抵フレームワーク規約に沿って実装するだけですし、

規模を LOC だと考える限りにおいては、大規模になっても複雑さは LOC に比例しませんから

単純にモジュール数が増えるだけで、一つ一つは単純な実装の繰り返しですよね。

おさしみにたんぽぽを乗せるお仕事と変わりません。たんぽぽの山が積まれていて途方に暮れるだけです。

もちろん、大規模になったときスケールしなくなるので C/Java にするというのはありますけど。

でも、これも Web 系では、ボトルネックネットワークデータベースというのが普通だと思います

2013-03-02

静的型付き言語を使う人たちが恐れていること (追記あり)

静的型言語課題は、十分強力な型推論を持ってる言語実用プログラムを書くのにパラダイムシフトを要求する点なんだが、それよりなにより「なんだか怖い点」にあると思う。信奉者が「そんなことはない」と熱く否定するさまがますます怖い。

https://twitter.com/yukihiro_matz/status/307369902648467456

@yukihiro_matz さんは普通ユーザの声を代弁している。@perlcodesample さんが静的型付き言語を使う人々の餌食になったのも記憶に新しい。彼らは何を恐れ、既存プログラミング言語を使う人々を攻撃し続けるのか。

型理論は先人から積み上げられたすばらしい理論体系だ。きちんと理解できる人は一部のエリートに限られ、こうしたエリート達の努力には本当に頭が下がるばかりだ。しかし、こうしたエリートのやってることは一般の人々からは評価されにくい。今、日本で有名な物理学者は誰か、名前を挙げられる人は居るだろうか。今、世界中医学者達が力を注いでいるのはどのような研究だろうか。普通の人は答えられない。

彼らは努力している分、人から評価されることを求める。しかし、努力=評価となるほど世の中甘くはない。残念ながら、頭の良さ=評価ともならない。そのため、彼らは普通言語を使う人々はいかに劣っており、自分たちが時間を費やしてきたことがいか価値のあることかをアピールするために他者を攻撃する必要が出てくる。そうしなければアイデンティティを保てない。

彼らのやっていることが本当に価値があることならば、そこまで他者を否定しなくとも勝手に支持者が増えていくのではないか。彼らのやっていることが本当に正しいのであれば、静的型付き言語によって成功するプロダクトが幾多も現れ、その効果自然証明できるのではないか。彼らは、そうなっていない現状に焦りを感じ、恐れている。本当は静的型付き言語実用的ではなく、自分たちの苦労は報われないのではないかと。

理論が美しいとか、エリートであるとか、そういうことだけでは必ずしも優遇されないのが社会の実情だ。静的型付き言語を使って、レガシーな命令型言語や動的型付き言語欠点暴露するような成果をどんどん出せばよい。

最後に、静的型付き言語の人々が忌み嫌う、動的型付き言語コミュニティ言葉を送ることでこのエントリを締めくくろう。静的型付き言語で、正しいプログラムからなるきちんとした社会を実現してやろうじゃないか

Shut the fuck up and write some code.

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

(追記)

これ、書いたのperlcodesample本人だろ

https://twitter.com/makotokuwata/status/307686753777639424

自演乙

https://twitter.com/kfujieda/status/307809398632374272

冤罪とか問題になってるご時世なので念のため言っておくけど、僕は@perlcodesample さんではない。上で下品な言い方をしたのでそこを批判されるのは当然だと思うけれど、言いたかったのは、ソフトウェア世界は形式手法型理論が全てではないわけだし、CS的な裏付けのないコード書いてる相手に対して一方的に自分の方が上の立場だと思わずに、もっと相手のやっていることを尊重して話をした方がいいってこと。

2013-02-27

型が無い事の利点とやらが全く的を射てない

変数に型がないということの利点について考える

http://d.hatena.ne.jp/perlcodesample/touch/20130227/1361928810

が大変お粗末な内容だったので、反論記事を書きます

型推論ソースコードコンパイル時間を遅くしてしまますソースコードが大きくなってきた場合に、すばやく書いて、すばやく実行結果をもらうことができなくなります

今時のパソコンならコンパイル時間なんて大したことない。

大規模開発環境コンパイル時間よりリンク時間の方が問題になりやすいが、それは別に型の話とは関係ない。

あと、インタープリタ最近は実行時にJITコンパイラが走る。

実行時間に影響がなく、開発者の待ち時間で済む方が実はよいのでは?

統合開発環境での、メソッド自動補完の機能の実装が少し難しくなります

みんなが統合開発環境をつくるとでも?

そもそも型が不定なら補完することすらできないので、

比較対象として相応しくない。

変数に型がないとソースコードの変更に強くなります。たとえば右辺の返す型に変更があったとしても、受け取る側のソースコードを変更する必要はありません。

これは逆に危ない。

実行するまで意図したインスタンスが返ってこなくなった事実に気づかないから。

コンパイル時に指摘してくれる方が安全

変数の型を持つ言語は、型が異なるのだが、処理としては同一の処理を行いたい場合には、オーバーロードという機能を使う必要があります変数の型がなければ、オーバーロード機能必要ではなく、ただ単にif文で分岐すればよいだけなのでとても楽です。

インターフェイスというもの勉強してください。

CならVTable。Javaならinstanceofなど同等の事はできます

というか、これ。型を意識しまくったコードじゃないですか???

C++テンプレートのような複雑でデバッグしにくい機能を使ったりしなければなりません。

とあるインスタンスしか入ってないつもりのリスト

実は全然ちがうものが混ざってた!なんて事故コンパイラによって止められる分、デバッグする必要すら無いんですけどね。

変数に型がないとどのような型の値が代入されているかからないという批判があるかと思います。可読性の問題で

変数に何が入ってるかわからないよりも、

インスタンスが何を持ってるのかわからない方が可読性に問題がある。

2011-09-23

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


第1章 新しいプログラミングパラダイムをめぐって (井田哲雄)
	1.1 はじめに
	1.2 プログラミングパラダイムの形成
	1.3 プログラミングパラダイムの展開
	1.4 パラダイム作法構造プログラミング
	1.5 構造プログラミングを超えて
	1.6 関数型プログラミング論理プログラミング,対象指向プログラミング
	1.7 新しいプログラミングパラダイム
	1.8 まとめ


第2章 ラムダ計算と高階プログラミング (横内寛文)
	2.1 はじめに
	2.2 ラムダ計算
	2.3 最左戦略
	2.4 コンビネータによる計算
	2.5 まとめ


第3章 マルセイユPrologProlog Ⅱ,Prolog Ⅲ
	3.1 はじめに
	3.2 準備
		3.2.1 述語
		3.2.2 項
		3.2.3 項の単一化
		3.2.4 節およびHorn節
		3.2.5 論理式の意味
		3.2.6 論理的帰結と導出
	3.3 マルセイユProlog
		3.3.1 Prolog記法
		3.3.2 Prolog計算規則
		3.3.3 Prologプログラムの例
		3.3.4 カットオペレータ
		3.3.5 DEC-10 Prologとの相違
	3.4 Prolog Ⅱ
		3.4.1 difオペレータ
		3.4.2 freeze
		3.4.3 ループ構造
		3.4.4 Prolog Ⅱのインプリメンテーション
	3.5 Prolog Ⅲ
		3.5.1 制約の枠組
		3.5.2 Prolog Ⅲのプログラム例
		3.5.3 束縛の領域と制約系
		3.5.4 Prolog Ⅲのインプリメンテーション
	3.6 まとめ


第4章 制約論理プログラム (相場 亮)
	4.1 はじめに
	4.2 制約プログラミング
	4.3 制約の分類
	4.4 プログラムの実行
	4.5 制約の評価
	4.6 まとめ


第5章 オブジェクト指向 (柴山悦哉)
	5.1 はじめに
	5.2 モジュラリティと抽象化
		5.2.1 抽象化
		5.2.2 手続抽象
		5.2.3 データ抽象
		5.2.4 オブジェクトによる抽象化
		5.2.5 並列オブジェクトによる抽象化
	5.3 共有
		5.3.1 多相型
		5.3.2 継承
		5.3.3 多重継承
		5.3.4 Self
		5.3.5 動的束縛の意義
	5.4 対話性
		5.4.1 クラスの再定義
		5.4.2 表示機能の一体化
	5.5 オブジェクト指向の弱点
	5.6 まとめ


第6章 型推論ML (横田一正)
	6.1 はじめに
	6.2 LCFの超言語からMLへ
	6.3 プログラミング言語と型
	6.4 ML表現と型宣言
	6.5 ML型推論
	6.6 LCFへの応用
	6.7 まとめ


第7章 Miranda (加藤和彦)
	7.1 はじめに
	7.2 Miranda概観
		7.2.1 等式による定義
		7.2.2 基本データ型と基本演算子
		7.2.3 ガード付き等式とスコープルール
		7.2.4 高階関数カリー化
		7.2.5 パターンマッチング
		7.2.6 ノンストリクト性と遅延評価
		7.2.7 ドット式とZF式
	7.3 型
		7.3.1 強い型付けと静的な型付け
		7.3.2 多相型
		7.3.3 型類義
		7.3.4 代数データ型
		7.3.5 抽象データ型
	7.4 処理系
	7.5 まとめ
	7.6 文献の紹介


第8章 項書換えシステムと完備化手続き (大須賀昭彦)
	8.1 はじめに
	8.2 項書換えシステム
	8.3 TRSの停止性
		8.3.1 意味順序
		8.3.2 構文順序
	8.4 TRSの合流性
		8.4.1 完備なTRS
		8.4.2 危険対
		8.4.3 危険対を用いたTRSの合流性判定
	8.5 Knuth-Bendixの完備化手続き
	8.6 KBの応用
		8.6.1 帰納的な定理証明への応用
		8.6.2 等号論理定理証明への応用
	8.7 まとめ


第9章 等式プログラミングから融合型プログラミングへ (富樫 敦)
	9.1 はじめに
	9.2 等式プログラミング
		9.2.1 等式プログラム
		9.2.2 代表的な等式プログラム
		9.2.3 プログラミング技法
		9.2.4 正則プログラム正規化戦略
	9.3 条件付き等式プログラム
		9.3.1 条件付き書換え規則
		9.3.2 条件の種類
		9.3.3 利点と問題点
	9.4 融合型プログラミング
		9.4.1 AMLOGシステム
		9.4.2 向付き等式
		9.4.3 実行戦略の変更
		9.4.4 代入操作
		9.4.5 合流するプログラムへの変換
	9.5 まとめ

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