私が愛するオブジェクト指向とそれを使わない理由 - takuto_hの日記
この記事では、私がオブジェクト指向のどこを愛しどこを素晴らしいと感じていて、そのうえでなぜオブジェクト指向を使うことを避けているのかを書き留めておきます。関数型言語使いの方で、「オブジェクト指向の何がいいのかわからない」「オブジェクト指向難しすぎ・複雑すぎ」とおっしゃる方にぜひ読んでいただきたいと思っています。また、「オブジェクト指向言語完璧に理解したわ」と思っている方にも読んでいただきたく思います。 なお、ここでのオブジェクト指向の定義は、「各言語でオブジェクト指向と呼ばれているものすべて」とします。JavaやScalaやJavaScriptやSmalltalkやRubyやCommon LispやOCamlがオブジェクト指向と呼んでいるものすべての総称です。もっとまともな定義が知りたい方は以下の記事がおすすめです。 オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smallta
プログラミング言語において、型とはドキュメントである
http://d.hatena.ne.jp/perlcodesample/20130227/1361928810 この記事が話題なんでしょうか。 +Shiro Kawai さんの記事 http://blog.practical-scheme.net/shiro?20130227-equibillium を見つつ、つらつら思ったことなどを書いてみます。 まず、上のリンクの「変数に型がないとどのような型の値が代入されているかわからないという批判に答える」というセクションは、残念ながら答えているとは言いがたいものがあると思います。 第一に、多くのプログラミング言語では [] 等の演算子はオーバーライドできるため、演算子が使われているということを理由にデータの型を推定することはできません。 第二に、->new、というものがperlにおいて構文なのかどうかは知らないのですが、そうでないとすると、この
Haxe使いから見たTypeScript雑感 - terurouメモ
TypeScript良いですね。世間の流れは完全に動的型付け言語から静的型付け言語＋型推論に移ってきていますが、JavaScriptの上にうまくそれを導入してきた感じです。ヘルスバーグはやっぱすごいよね、と。 今後実装される予定のジェネリクスが載ってきたら、better JavaScriptとしては最強言語の一角になりそうな雰囲気ですね。 CoffeeScriptとTypeScriptについて 言語仕様としては正直別物レベルの存在なのだけど、ツールとしての性質（コンパイラがJSとして動作するなど）が大きく似ているため、Web上ではよく対比されてるようです。 TypeScriptが世に出てきてしまった以上、CoffeeScriptは「型付けのできないTypeScriptの出来損ない」みたいな存在になってしまったかなぁと。TypeScriptの出現以前から、CoffeeScriptには採用する
Shibu's Diary: Pythonはなぜ？str.join(seq)なのか？
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 PythonのAPI設計の中で、たまに思い出したように話題が出てくるのが、配列に入った文字列を結合するメソッド。Pythonではstr.join(iterable)です。他の言語(僕がよく知っているRubyとJavaScript)はArray.join(String)となっています。どちらでもありえる話ですが、個人的にはPythonの方が自然だな、と感じていました。ですが、他の言語の方がいいという人も多く、Pythonプログラマーの中でも好き嫌いが出たりもします。せっかく、弾さんがPerlの国からやってきて適度にガソリンをまいて炎上したところなので、Pythonの歴史を紐解いてみました。 軽くjoinの歴史について語っているサイトはないか探してみる 軽くぐぐってみると、何箇所か
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
「JavaScriptの配列は参照渡し(call-by-reference)」は間違い - rarilogger
「JavaScriptの配列は『参照渡し(call-by-reference)』」というネット上に大量に存在する間違った記述を訂正するエントリ。 結論から先に言うと JavaScriptにおいて、関数の引数として配列を与えた場合、『参照の値渡し』になります。『参照の値渡し』は、『参照渡し(call-by-reference)』ではなく『値渡し(call-by-value)』に分類されます。 参考エントリ 以下の解説が非常にわかりやすいです。G-chan Square - [javascript] javascriptの関数で引数に配列を渡すと、それは本当に参照渡しか？ G-chan Square - じゃ、「参照渡し」ってなんだ？簡単に端折ると、関数の引数として変数を与える場合、 値の値渡し(プリミティブ型変数の値をそのまま渡す) 値の参照渡し(プリミティブ型変数の参照を渡す) 参照の値
美しきObjective-C
Objective-Cというプログラミング言語があります。 C言語をベースにオブジェクト指向言語のSmallTalkの拡張を施した言語です。 オブジェクト指向を取り入れたC言語にC++がありますが 根本から拡張されているC++と違い Objective-Cは素のままのC言語にSmallTalkを融合させたような形を取ります。 Objective-Cは世界で2番目に美しいGUIを生み出した現AppleComputer社CEOである Steve Jobs氏がNeXTコンピュータのOSであるNeXTSTEPで採用した言語です。 NeXTSTEP自体はPC/AT互換機やHewlett Packard社のHP9000、 Sun Microsystems社のSparcStationにも移植されたようですが、残念ながら私は触れた事がありません。 現在では希にYahoo Auctionに出品されますが、
PHP のよいところとよくないところ - id:k-z-h
php前提。PHP はクソ。滅びろ。ruby はしらんが python か perl か java のほうがよっぽど楽。javascript は多分同じかもっと地獄。よいところ導入が安い動作環境的な意味でも、コード的な意味でも。置けば動くし、書けば動く。本当に何も知らん人間でもなんとか動く。エンジニアの頭数もそろえやすい。運用コストのスケーリングができるapache+mod_php だけでも普通に早い。apc 入れればそれだけで大抵のリクエストさばける。nginx+php-fpm+apc なんて環境にすればもっとさばける（と思う。まだ試してない。）最悪 HIPHOP-PHP でなんとかできることは Facebook が証明している。ドキュメントが読みやすいphp.net のドキュメントはテンプレートがしっかりしていて全部それにそっているので非常に読みやすい。邦訳も早い。よくないところ標準の
なぜ数ある言語からCommon Lispを選んだのか - 八発白中
はてなに入ってからよく「なんでCommon Lispで書くんですか？」と聞かれます。アリエルにいるときは全く聞かれなかった質問です。今まで当たり前のように受け入れていたことを改めて尋ねられるとはっとさせられます。 「Common Lispが一番書きやすいからです」 「あっ…すいませんでした」 なぜ謝られたし。これではまるで僕が変人扱いです。だけどたぶんこれが普通の感覚で、アリエルは変な人が多かったんでしょう。 こう言われることもあります。 「でも、Lispってカッコが多いじゃないですか」 これもまた久しく忘れていた感覚で、思わず答えに詰まってしまいました。Common Lispのカッコがそれほど多くないということは既に証明されているというのに。 先週末にid:m2ymと会って話をしたときにも同じような話をしました。閉じカッコがたくさん続いているとか、letのカッコの数が1個多いとか、そうい
ECMAScript の（構文上の）ごく基本的な構造 - oogatta のブログ
とてつもなく基本的なことでありながらいつも忘れてしまうのでここにメモしておく。 Program → Statement → Expression が基本的な流れ。これ以外の代表的な要素としては…。 Block は Statement の下。さらに Statement を含める（複文を作れる）。 Expression の下に AssignmentExpression 、 AssignmentExpression は LeftHandSideExpression AssignmentOperator AssignmentExpression 。 LeftHandSideExpression が NewExpression か CallExpression 。 NewExpression の下に MemberExpression がいて、その下にやっと PrimaryExpression や F
卜部昌平のあまりreblogしないtumblr
エゴサーチで見かけた反応とそれの感想など 速さのためにはCでないと この誤解は典型的ですねえ。今、申し訳ないんだけど、普通に書いたCのコードと普通に書いたJavaのコード走らせると、普通に書いたJavaのコードの方が速くなるケース、全部とは言わんが案外と多いですよ。なんでかというと、Javaは普通に書いたらJVMが人類の持てるテクノロジの限りを尽くして勝手に高速化してくれる1が、Cはあなたの能力以上に速くはならない。Cは速いJavaは遅いってのは10年くらい前には正しかったんでしょうけどねえ。 なお自分でベンチマークしてる暇なんかないよ!という人はshootout.alioth.debian.orgぐらいは読んでもいいんじゃないですかね。たとえばJavaとCの比較で見れば全体的にいって同じくらいのスピード、いくつかの項目でJavaのほうが速いのが分かる。 組み込み屋はCでなければ何を使うか
C#(VB)プログラマのためのF#入門
This document discusses various programming languages and tools, including F#, C#, VB, .NET Framework, and related concepts. It compares features of F# to other languages like options vs null, pattern matching, pipe operators and more. It also covers F# tools for Visual Studio like F#Depth colorizer and various IDE editions for using F#.Read less
生島さんが考える最強の言語 SQL - ぐるぐる～
生島さんが誰と闘っているのか知らないけど、ちょっと気になることをつらつらと。 SQLは最も高級言語 - SQLer 生島勘富 の日記 SQLは最も高級言語２ - SQLer 生島勘富 の日記 SQLとはなんぞや？ - SQLer 生島勘富 の日記 高級*言語* どうも生島さんは、「SQL は高級言語！」と言いつつ SQL の処理系 (RDBMS) のことを高級だと言っているようです。 言語が高級であることと、処理系の最適化が手厚いことをごちゃまぜにして、この言語高級！と言うのはまずいんじゃないでしょうか。別に、RDBMS を操作するための言語として SQL でなくたっていいのです。例えば Tutorial D/Industorial D もあるし、LINQ を SQL に変換せずに直接 DB の操作を行うような RDBMS/Linq to X と言うのも考えられます。 ここではとりあえず、
ECMAScript/実行コンテキスト - Web Application Programming Wiki*
概要 実行コンテキストは計算の状態を表し、以下の事項を決定する。 名前解決のためのスコープ thisの値 varによって宣言された変数がどのオブジェクトに付与されるか 実行コンテキストはスタックを成す。以下のタイミングで新しい実行コンテキストが作成され、スタックに積み上げられる。 プログラムの実行開始時。 関数が呼び出されたとき。再起呼び出しの場合は、呼び出されるたびに新しい実行コンテキストが作成される。 evalが実行されたとき。 それぞれ、プログラム終了時、関数終了時、evalの実行終了時に実行コンテキストから抜ける(スタックのトップの実行コンテキストが消える)。 実行コンテキストは以下の情報を持つ。 thisの値 スコープチェイン 変数オブジェクト スコープチェイン スコープチェインはオブジェクトのリストであり、識別子の評価時に参照される。 識別子fooを評価する際は、まずスコープチ
コア・JavaScript ( JavaScript. The Core. ) - oogattaの勉強日記
この文章は、 Dmitry A. Soshnikov さんの、 ECMAScript に関する優れた記事 "JavaScript. The Core." を許可を得て翻訳したものです。世の中に、 JavaScript のブラウザ API や、実装系に関する記事は多々あれど、 ECMAScript の仕様に則って、ここまで詳しく説明してくれている記事は殆ど無いと思います。今回は翻訳できておりませんが、文中で参照されている Dmitry さんの ES3 シリーズも、読み応えのある（ ECMAScript3 の仕様の副読本としても読める）素晴らしい内容ですので、是非チャレンジしてみてください！（ご要望があれば訳します翻訳許可を頂いたので、この記事内で参照されている章から逐次翻訳を進めます！）。 ちなみに Dmitry さんは、計算機科学や数学にも明るい方でらっしゃいます。が、私は違います。極力
30〜40年後の話 - 西尾泰和のはてなダイアリー
ブログ書いてないでさっさと原稿を書けよという気がするので、思ったことを忘れないように走りがきする感じで: 心配しなくても現在使われている大部分の言語はあと30〜40年で「昔そんな言語もあったね」レベルまで駆逐されるよ。 なぜ30〜40年って言ったかというと、それくらいあればプログラムの入力方法が変わる可能性が高いからだ。かつてパンチカードからキーボードに変わったように。 開発環境が変わった際に、いまの環境での「書きやすさ」を追求している言語はアピールポイントを失うことになるわけだな。だから、他の部分で40年後にも残る価値を持っていなければ駆逐されるのが当然だよ、と。 moriwaka: @nishio 割と同意するんですがFortranとCOBOLとCの長寿の秘密を解きあかしたい 僕の理解が正しければ、それは「新しい言語を学ぶことを厭わない人たちが好むような機能を持っていること」ではない。
Rubyがそろそろ一回終わってみるべき10の理由
いや、Rubyを取り巻く皆さんの生活まで終われとは言ってないですからね。終わってみるべきなのはRubyのコア部分の開発。 1) 百年の大計の欠如 https://twitter.com/yukihiro_matz/status/25168548474 によると、100年や200年続けるべきなんだそうだ。ふーん。100年って言ってみたいだけちゃうんか。200年後といえば本人はおろかまつもとゆきひろと面識のある人間すら死に絶えている時期なんだけどな。そこまで続けたきゃどうするればいいか真面目に考えたことあんのかね。日本国ですらこの120年で2回も憲法変わってんだぞ。惰性で200年もつわけがないだろ。 2) まつもとゆきひろがスケールしない 御存知の通りまつもとゆきひろのRuby開発に対するコミットペース(ここでいうコミットってのはソースコードをチェックインすることだけではなくて広く「関与」の意
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://movelang.org/
オラクル統合後の Java の今後について
コールバック不要：Javascript に逐次プログラミングを取り戻す StratifiedJS
