「クロージャ」を含む日記 RSS

はてなキーワード: クロージャとは

2016-05-24

http://anond.hatelabo.jp/20160524140005

グローバルというより、単にスコープの外の値にアクセスしているだけ。

それが関数型じゃない、というのなら、クロージャはどうなるの?知ってたら教えてほしいが。

2015-06-30

http://anond.hatelabo.jp/20150630204427

何気にPHPデザパタ覚えるのに結構機能が充実してるからな。アクセス修飾子も静的メソッド普通に存在できるし、クロージャも使える。

活躍の場がweb位にしかないだけで、結構可用性は高いんよ。

2015-05-13

http://anond.hatelabo.jp/20150513093805

オブジェクト指向とか関数指向とか関係あらへんよ。

クロージャレベルの話なら今はどこの言語でも使用できるし、高度に発展したJS関数型言語と見分けつかん。

そういう意味で、特に関数型言語」とされているものをあえて学習する意味殆どねーって話なんじゃないかね。

2015-05-02

clojureのjはjavaのj

閉包を意味するほうのクロージャ綴りはclosureなのだが、

時々、クロージャ(clojure)という表記を見かける。

それ、JavaScriptに変換されても.NETに行ってもjavaのjが消えないあのLisp方言だ…。

そんな間違いするなんてご苦労じゃー。

http://anond.hatelabo.jp/20150502000045

まぁ、関数型として専門的に作られているような奴は、大体デフォカリー化ついてるけど、そいつらも要は裏ではクロージャ的なものを使ってる。

で、それこそJavascriptとかLispみたいな「関数型として、本当に最低限必要ものだけ揃えている」系列の奴等は、プログラマ側がクロージャ駆使して書いてあげる必要がある。

まぁ、関数型ばりばりの奴等ほど、色々至れり尽くせりの構文になっててベースを見せないので、あんまり意識してクロージャ使ってる、って感じにはならないけど、ベースにある所よくよく見ると、クロージャが出てくるって感じか。

2015-05-01

http://anond.hatelabo.jp/20150501220738

その「関数の部分適用」を実現するために(専用の機能を持っていない限りは)クロージャ必要なんだよ!!

(部分適用するために、まずカリー化 ⇒ そのカリー化にそもそもクロージャ必要

専用の機能があったとしても、大体裏でクロージャに似たような機能使って実装しているわけだし。

毛の壁のアレは、多少気持ちは分からないではない。

http://kenokabe-techwriting.blogspot.jp/2015/04/amazon102-93.html

これのやつなぁ……。

確かに自分最初関数勉強しだしたときに、混乱したポイントではあったんだよ。

なんでかというと、クロージャぐぐると、まっさきにjavascriptクロージャの説明が出てきて、その中で実用例として「呼び出すたびに出てくる数値がインクリメントされる」的な例が真っ先に出てくるから

「えっ、クロージャって、これやるための機能なの? 副作用バリバリじゃね?」って思っちゃうんだよね。

これはかなりのけっ躓きやすポイントになってしまっていると思う。

実際はJavascriptの例でよく出てくる使われ方は、かなり特殊例なんだけど、これが代表、みたいな扱いに見えるんだよね、今の検索結果だと……。

クロージャ」という言葉について

http://b.hatena.ne.jp/entry/kenokabe-techwriting.blogspot.com/2015/04/blog-post_30.html

http://kenokabe-techwriting.blogspot.jp/2015/04/amazon102-93.html

この記事自体はどうでも良いのだけど、以前「クロージャ」という言葉の初期の使用例を探したことがあったのを思い出したので、参考までに。

Landin "A λ-Calculus Approach" (1966)

We represent the value of a λ-expression by a bundle of information called a "clusure", comprising the λ-expression and the environment relative towhich it was evaluated.

我々は、ラムダ式の値を「クロージャ」と呼ばれる情報の束で表す。「クロージャ」はラムダ式とそのラムダ式評価に関する環境から成る


Moses "The Function of FUNCTION in LISP,or Why the FUNARG Problem Should be Called the Environment Problem" (1970)

A useful metaphor for the difference between FUNCTION and QUOTE in LISP is to think of QUOTE as a porpous or an open covering of the function since free variables escape to the current environment. FUNCTION acts as a closed or nonporous covering(hence the term "closure" used by Landin).

LISPでのFUNCTIONとQUOTEの違いについては、次のように考えるのが有用比喩になる。QUOTEは多孔的または開放的関数をおおっていて、自由変数現在環境へと脱出できる。FUNCTIONは閉鎖的(closed)または非多孔的に関数をおおっている(このことからLandinはクロージャ(閉包)という用語を使っている)。

(訳はhttp://kreisel.fam.cx/webmaster/clog/img/www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/funarg/funarg.html から)


Sussman and Steele "SCHEME: An Interpreter for Extended Lambda Calculus" (1975)

In order to solve this problem we introduce the notion of a closure which is a data structure containing a lambda expression, and an environment to be used when that lambda expression is applied to arguments.

この問題を解決するためにクロージャという概念を導入する。クロージャラムダ式とそのラムダ式引数適用されるときに使われる環境から成るデータ構造である


Steele and Sussman "The Art of the Interpreter" (1978)

We say that the procedure is closed in the current environment, and the &PROCEDURE-object is therefore called a closure of the procedure, or a closed procedure.

この手続き現在環境に閉じられている(closed)と言い、それゆえ&PROCEDUREオブジェクトはその手続きの「クロージャ」あるいは「閉手続き」と呼ばれる。

2014-07-17

関数型入門以前

これ読んでも関数型分からないけど、入り口の前あたりに立つために

関数型言語覚えたらなんの役に立つの

プログラマとしての引き出しが増える。

って書くと「そんなもんどんなプログラミングテクニックだって一緒だわ」って言われそうだけど、でもそうとしか言い様がない。

とりあえず、オブジェクト指向と同じで、プログラム構造化して、複数レイヤーに切り分けて部品化していくテクニックだとは言える。

ただオブジェクト指向とは大分切り口が違う。何ていうか、割と直交する切り口でプログラム構造を切り分けていく。

なので、関数型とオブジェクト指向と両方憶えるだけで、大分切り口の引き出しが増える。

オブジェクト指向関数型両方憶えると、プログラマとしての引き出し増やすのに効率が良い、って思えば良いかも。

具体的にどう切り分け方が違うの?

オブジェクト指向は、プログラムの各部品を「あれの中のこれの中のそれの中にあるあれ」みたいな感じで組み合わせる。

部品が更に細かい別の各部品で構成されていて、それぞれの部品が噛み合わさって、複雑な一つのプログラムを構成するような切り方。

関数型言語は、プログラム部品を「あれをした物にこれをした物にそれをした物にあれをする」みたいな感じで組み合わせる。

もっというとプログラム全体を簡単に記述するできるDSLがあって、そのDSLを簡単に実装するためのDSLがあって、DSLの入れ子構造で一番小さい部品シンプル関数、みたいな切り方。

どう使い分けたら良いの?

ケースバイケース。

ではあるんだけれど、シンプル部品を大量に組み合わせて構成するのがしっくりくるならオブジェクトで、部品数が少ないんだけど一個一個が複雑な動作する構成にしっくりくるのが関数型……かも?

関数型言語の紹介見てると、何かひたすらイミュータブルなデータを弄繰り回す説明ばっかり出てくるんだけど…

関数型言語たる条件として「関数が第一級オブジェクト」ってのがあるんだけど、関数が第一級オブジェクトだとイミュータブルなデータを素直に扱える。

で、イミュータブルなデータ構造使うと色々便利、ってことで実例として一番出てくるという。

何か型型言ってるんだけど、型くらいC言語にすらあるわ。メモリ領域の確保量を示すあれが何でそんなに重要なの?

関数型言語エポックメイキング的な言語が三つくらいあって、元祖Lispとその流れ汲んだMLMLの一種で関数型をある種の到達点に持っていったHaskellって感じ(独断偏見)。

で、このうちのMLって奴が、プログラミング言語に型システムがついてるんじゃなくて、型システムプログラミング言語がついてきた存在だったりする。

型で色々やるために生まれたわけで、まぁなんというかそもそも型と密接な関係にあって、Haskellもその流れを汲んでて、こいつが超有名になった、って感じ。

おかげさまで、型使って色々やったりする方法が日々考えられているわけです、静的型付関数型の世界では。

クロージャって、大まかな概念wikiとかで理解したけど、関数型でどう使われてるの?

関数型言語ではよく「関数関数を引き取って、合成した関数を返す関数」みたいなのが使われるんだけど、関数関数の合成って、それ合成された関数がもともと引数として与えられていた関数憶えてないと無理やん? 自分自身の構成部品憶えてられないわけだから

クロージャあると憶えててくれるわけですよ。

そんな感じで高階関数実用的なレベルで使うのには大体必須と言う。

モナドとやらは何に使うものなの? 何が便利なん?

関数型言語DSLを作りまくる言語みたいに書いたけど、モナドちょっと複雑なDSLを簡単に作らせてくれる仕組みだと思っとけば良い。

Haskell副作用が一切ない純粋関数型言語って言うけど、副作用なしでどうやって入出力してるの?

まず純粋定義だけど「全ての関数は同じ引数を与えられた際、必ず同じ値を返す」ってことで、これがいわゆる副作用がないって状態だ。

で、これって逆に言えば「プログラムである関数に対して、絶対に同じ引数を与えさえしなければ、その関数がどんな値を返したところで、事実上純粋だと言えてしまう」ってことでもある。

本末転倒感があるんだけど、HaskellではIOモナドという仕組みと特別main関数を使って「呼び出すたびに絶対に違う引数自動的関数に与えてくれる仕組み」を実現していて、こいつを使って入出力する。

うん……凄い本末転倒。ちなみにこの自動的に与えられる引数はRealWorldって名前がついていて、要は「刻一刻と変わり続け絶対に同じ状況にならない現実世界の状態を引数に取っちまっているようなもんだからしょうがないだろ?」的な感じ。

2014-04-10

プログラム中級者が感じる関数型の違和感

なんだか話題になってるから書く。

やっと初心者を脱して中級者になりかけてるプログラミング学習者が関数型言語に何を感じているかを書こうと思う。

1 圏論かいらないんじゃないの?

Haskellが短いコードプログラムを書けるというのは分かる。

forループmapやfoldで抽象化する利点も分かる。

それでやりたい処理のほぼ全てがまかなえるということも実感している。

副作用のない小さな関数を合成して大きな関数を作る利点も分かる。

再利用性も上がるし、どこからどう影響を受けているかが簡単に分かるからバグも出にくい。

ただ、Haskellの基礎になってる圏論が何の役に立つのかは、まったく分からない。

むしろ邪魔なんじゃないかと思う。

ファンクターやモナド概念圏論で扱われているのは分かるけど、圏論なんて名前だけ知ってればコードを書くのに不都合はないだろう。

圏論必要なのはHaskell設計する人であって、使う人ではないと思う。

なのに、やれクライスリ圏だ自己関手の圏だのと、うるさいったらありゃしない。

Linux上で開発環境整えるのにカーネルコードを読めって言うぐらい的外れだと思う。

いや、知識として持っとくのはいいだろうけど、役に立たんだろ。

2 言うほど新しい機能ないような?

Rubyが羊の皮をかぶったLispとはよく言われることだけど、関数型言語オブジェクト指向言語とそこまで違いがあるような気がしない。

純粋言語ではできないけど、クロージャに内部状態を保持してもらって無名オブジェクトみたいな使い方をすることはあると思う。

その無名オブジェクトもっとあれこれデータ関数詰め込めば、いつの間にか普通にJavaC#で使うようなクラスのできあがり。

その間はなめらかにつながっていて、不連続に切れるようなもんじゃない。

関数プログラミングと言いつつ、オブジェクト指向の考え方は利用できる。

上級者はデザインパターンdisるのが好きかもしれないけど、逆の考え方をするべきだと思う。

デザインパターンオブジェクト指向言語欠点を補うための苦肉の策じゃないよ。

関数プログラミングの基礎的なパーツだと思う。

からちょっと見た目がすっきりするだけで、結局やることはオブジェクトプログラミングと変わりはないと思う。

3 なんか選民思想にとらわれて無い?

関数プログラミングコミュニティの人って、業務でクソコードメンテさせられて、その現実逃避に美しいコードに擦り寄っているように見える。

もちろん、美しいコードを書けるなら書いた方がいいし、現代的な言語を使えるなら使ったほうがいいと思う。

けど、適材適所というか、オブジェクト指向言語でも、やってやれないことはないわけで。

役に立たない圏論をありがたがる所とか、どうもイキがってるように見える。

せいぜい生産性が倍になる程度で、他の要素が悪ければ帳消しになるような利点でしかないに違いないのに。

開発プロセスとかを見直す方が仕事を楽にしてくれるんじゃないのかな?

2014-01-23

http://anond.hatelabo.jp/20140123150556

ああ…その通りだ。だから、C系全般はユーザこそ多いモノの糞コードになる確率結構高いように思う。

ラムダ式とかクロージャとか使い始めると、インデントすらあまり意味をなさなくなってくるからな。

そこら辺、上手いことやってる言語があると幸せなんだけど。pythonとか?

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++ではまったくもって難易度が違うことも分かっています。後者になるほど圧倒的に難しい。

2012-09-20

http://anond.hatelabo.jp/20120920164222

こういうのを望んでいるなら、不可能。

var i = 10;

[1,2,3, ... ,99,100].each(function(i) {
	// 何かの処理
});

console.log(i); // 10と出て欲しい

jashkenasはこう主張している

if they do clash, shadowing the variable is the wrong answer. It completely prevents you from making use of the original value for the remainder of the current scope. Shadowing doesn't fit well in languages with closures-by-default ... if you've closed over that variable, then you should always be able to refer to it.

衝突が起こるとしても、変数隠蔽(shadowing)は間違った解決法だ。スコープ内のその他のすべての変数に関して、オリジナルの値の利用を完全に塞いでしまう。隠蔽は、クロージャが標準(closures-by-default)な言語にはうまくマッチしない。その変数を閉じ込めているならば、常に参照出来るべきだ。

ソースhttp://www.sixapart.jp/techtalk/2012/01/coffeescript.html

2012-09-04

"Hello world!"

このお話はたぶんフィクションです。実在の個人や企業とはあんまり関係ありません。そういうことにしろください。


10年前、20代になったばかりの頃の僕は、今思えば本当に最低な生活を送っていた。高校を中退し、実家とは疎遠で、友達もなく、金もなく、夢も希望もなく、ただバイト先と自宅を行き来するだけの毎日。いつも視界には霞がかかったようで、底の見えない空虚さだけが僕の心を支配していた。

それでも趣味らしいものはあった。オンボロマシンRedHatを入れ、ダイヤルアップの細い回線自宅サーバを立て、Perlでガラクタのようなプログラムを動かす。そんな子供じみた遊びだけど、プログラムを組んでいるときだけは空虚さを忘れ、画面の中に没頭できた。

ただ、そのときの僕はもうすでにいろんなものに打ちのめされていて、若者にありがちな全能感などというもの霧散していた。自分プログラミングで何かを成すだとか、それを仕事にしようなんてことは一切頭になかった。このまま夢も希望もなく人生を終えるのだと、そう思っていた。

それでも転機は訪れる。

勤めていた工場で派遣切りにあった僕は、「働きたくないでござる! 絶対に働きたくないでござる!」とか言いながらニート生活をしていた。そろそろ翌月の家賃も払えなくなってきたころ、派遣会社から電話がかかってきた。「プログラム開発の仕事があるんですがやりませんか?」と。そういや履歴書だかスキルシートだかに、Perlがどうたらとか書いたっけ。実務経験もない中卒に仕事まわすとかwww ……とは思ったものの、このままでは本気でホームレス一直線だったので引き受けた。

はじまりはそんなもの。たいした覚悟があったわけでもない。

派遣された先は従業員数10人くらい、パートさん含めても50人くらいの小さな会社だった。現在手書きの伝票でやっている処理をWeb化したいのだという。システム担当者はおらず、事務員さんがExcelAccessを使える程度。すべて僕一人でやらなければならない。マジか。

ともあれ、まずはサーバである。後々の運用を考えるとLinux系は使えない。事務所の片隅に放置されていたWindows 2000マシンApacheを入れてそれでよしとした。

次はデータベース。でもこの頃の僕は「正規化ってなんれすか?」というレベルだったので基礎から勉強した。なんかMySQLってのがいいらしい→社長に申請→「今Access使ってるからそれでいけ」→「はい」→パフォーマンスの面で問題出るだろうなとは思ったがしょうがない。

次は言語最初はPerlで書こうと思ってたけど、PHPってのが流行ってるらしいのでこっちにした。ウホッ! いい言語……。

そして業務内容を把握するため、現場あっちこっち駆けずり回りながらヒアリングする。ときには部長から愚痴を聞かされ、ときにはパートのおばちゃんから誘惑され、そんなこんなを繰り返し、仕様をつめていく。

そして数ヶ月かけて開発したシステムの稼働である。そのときのことは今でも忘れない。

現場の人がラインからデータ入力する。サーバデータが送られてくる。別の事業所からも送信されてきてる。問題ない。事務員さんが伝票処理を行う。問題ない。すげえ、ちゃんと動いてる。お遊びで作ったプログラムではなく、本当に本気の業務用プログラムである。それを僕が1人で作ったのだ。このプログラムで業務がまわり、利益を生み出すのだ。社会に対して、何らかの作用を及ぼすのだ。僕みたいなクズにでも、そんなことが可能だったのだ。

そのことに気付いたときの感動を、僕は今でも忘れない。


それからちょっといろいろあって、ホームレスになった。うん、急展開なのはわかってる。でもこの間のことは語ってもあまり面白くないし、公序良俗に反する話もあるのでざっくりはしょる。どうせフィションなんだから細かいことを気にしてはいけない。

話を戻そう。

ホームレスになってからの数日はひどい精神状態だった。足元から世界が崩れていく感覚。視界がぐにゃりと歪む。帰りたい。でも帰る家がない。だからホームレスというのか……というトートロジーを何度繰り返しただろうか。

もうあまり覚えていないけど、このときの僕は本当にもう何もかもどうでもよくなってたと思う。ただ、自分の全財産がバッグ1つしかないということに対する心地よさ、開放感があったのはよく覚えてる。そんな状況で地べたに座り込んで見る風景。きっと、今はもう見えない。あの頃の僕にしか見えない風景が、そこにはあった。

いろんな人と出会い、流れ流れて、最終的に西成のあいりん地区にたどり着いた。関西圏の人には説明不要かもしれないけど、よく言えば日雇い労働者の街、ぶっちゃけて言えばホームレスメッカである。今はもう綺麗になってしまったし、治安もそこそこよくなったけど、僕がいた頃はまさに「カオス」としか表現のしようがない状況だった。

どこから持ってきたんだといいたくなるようなガラクタばかりを並べた泥棒市。簡素な骨組みにビニールシートをかぶせただけの飲み屋。「ないかーないかー」と声が聞こえてきたので見てみると、警察署の近くなのに道端で堂々と丁半博打をやっている。コンビニトイレ張り紙には「トイレが詰まる原因になるので注射器を捨てないでください」とある。いやトイレが詰まるとかの前に気にすることがあるだろ。ケンカなんて日常茶飯事。頭から血を流したおっさん普通に歩いてる。数百人規模で並ぶ三角公園炊き出しは圧巻。四角公園の炊き出しでは誰もいない場所にワンカップの瓶とかがたくさん並んでる。何かと思って聞いてみたら「あれで並んどることになってん」と返ってくる。学食の席取りルールみたいだ。ああもう全然書ききれない。

でも一番印象に残っているのは、南海線の高架下、うず高く積まれたゴミ山の前でガラクタ解体していたおっちゃんのこと。奇声を発しながらハンマーを振り下ろしていたおっちゃん。その両目は、これ以上ないほどにキラキラと輝いていた。その鉄屑を売った金でビールが何本買えるか皮算用でもしているのか、あるいは幸せになる魔法の薬でもキメているのか、そのときの僕にはわからなかったけど。

そして、人生を投げ出していた僕に付き合ってくれたおっちゃん、あなたのことも忘れません。モーニングをおごってくれて、いろんな話をしてくれて、聞いてくれて、役所の福祉課まで連れて行ってくれたおっちゃん。あなたがいなければ、僕は今でも西成でぬるま湯の日々を送っていたかもしれない。

いろんな人に助けられて、ホームレスの施設に入ることになった。舞洲という人工島にあるのだけど、これがまた周囲に何もないのだ。スポーツ関連施設、ゴミ処理場、物流センターが点在するくらい。コンビニ1件ありゃしない。だけど施設での生活は意外にも楽しかった。2段ベッドが6つ並んだ12人部屋。むさくるしいけど、みんなバラエティに富んでいた。刑務所上がりのいかついおっちゃん、虚言癖のひどいおっちゃん、ほとんど一日中寝てるじいちゃん、薬のフラッシュバックがひどい兄ちゃん。そんな人達の中で過ごせば、自分がどれほどクズであっても気にならない。やはり僕はこちら側の人間だと再認識した。

市街地にある施設へ移ってからはいろんな仕事をした。生駒の山奥にドブさらいに行ったり、事務所移転バイトで腰をやってしまいそうになったり、なんやかんやあったけど、長くなるのではしょろう。結局のところ、またプログラマをすることになるのである

そろそろ身バレしそうな領域に入ってきたのでここでもう一度強調する。このお話はたぶんフィクションです! たぶんフィクションです! 大事なことなので2回言いました。


そう、またプログラマとして働くことになった。今度は従業員数300人くらいの大きな会社である日本人なら誰でも知ってるであろう大企業の子会社ということもあり、本社からの出向社員東大京大卒当たり前みたいな状況。そんな人達の前で中卒の僕が前に座ってプレゼンやら仕様検討会やらをするのだ。何の罰ゲームだよ……。

最初に思ったのは、「ここにいる人達は育ちがいい」ということだった。みんな礼儀正しい。喋り方や立ち居振る舞いまで、今まで僕がいた世界とは何もかもが違っていた。まるでドラマに出てくるような「ちゃんとした人生を送っている人達」だ。そんな人達に囲まれていると、「生きていてごめんなさい」と言いたくなる。本当に。

他に驚いたこと。社内で連絡を取り合うのにメール使ってる。やばい。社内メーリングリストとかもある。やばい。定期的にミーティングとか勉強会とかもする。なにそれ怖い。自分がいっぱしの社会人になったかのような錯覚に陥る。ちょっと前まで西成でゴミ拾いのバイトしてたのに。「勘違いするんじゃない! 西成の日々を思い出せ!」と何度も自分に言い聞かせ、自我を保った。

とはいえ、萎縮してばかりもいられない。気付いたことはどんどん提案した。あちこちに散らばっている共通の処理をライブラリ化したり、サーバで負荷がかかっている部分を改善したり。却下されたものも多かったけど、採用されたものもそれなりにあった。業務の改善案を考えるのは楽しい。誰かがプログラマの三大美徳に「無精」を上げていたっけ。極度のめんどくさがりで、楽をするための苦労は惜しまない僕には、こういう仕事天職なのかもしれない。

システム開発の方も順調に進んでいた。この頃はMicrosoftですらWeb版のOfficeを出すような状況で、デスクトップアプリに比べても遜色ないレベルのWebアプリがどんどん出てきていた。この会社で開発しているのも、そんなAjax技術を多用したWebアプリだ。JavaScriptを用いた本格的な開発に最初はとまどったけど、書けば書くほど言語自分の手に馴染んだ。クロージャprototypeといった基礎をちゃんと学ぶと、書けるコードレベルが段違いに上がっていくのが楽しかった。

仕様にもこだわった。実際に使う人がどんなふうに操作するのか、何度も何度も脳内でシミュレートし、どんなUIが最適なのか、データ構造はどうするべきか考え、実行速度とメンテナンス性の板挟みに苦しみ、何度も何度もリファクタリングを繰り返す。

そのとき開発していたシステムは、メイン画面でほとんどの処理を行うタイプのものだったのだけど、そのメイン画面のJavaScriptコードは最終的に1万行を超えた。もうこの頃にはJavaScriptでのオブジェクト指向的な開発手法というもの自分なりに構築されつつあった。そしてこのカチャカチャとした手触りの、安物のオモチャのような言語は、僕の一番好きな言語になったのだった。

そんなある日、僕が作ったシステムのメインユーザーである他部署の偉い人が来て、開口一番こう言った。

「あのシステムいいね!

この機能が素晴らしい、とか、あの発想はなかったわ、とか、とにかくべた褒めして、そして去っていった。機能追加要望の前口上だと思って身構えていた僕は拍子抜けした。「あの人が他人を褒めることなんてめったにないよ、すごいね」と近くの席の人が言う。

そのとき僕は「カチリ」という音を聞いた。

どこにもはまることのない歪な歯車。その僕が、社会という大きな機械の中に組み込まれる音だったのだと思う。まあすぐに外れてしまうのだけど。その一瞬だけは、僕は確かに社会の一部になれたのだ。


そして契約期間満了となり、再び僕は人生の岐路に立たされる。

これからどうするか? 今の技術力ならそれなりのところに就職できるかもしれない。でも僕にはやってみたいことがあった。半年かけて海外を旅するのだ。

今、僕の手元にはまとまったお金がある。こんなのは人生で初めてのことだ。そして僕は今、どこにも所属していない。どんなところに行ったっていいし、何をしたっていい。この先、そんな状況がどれだけあるだろうか? 人生長いのだ、そりゃあ何度だってあるかもしれない。でも今回やりたいことをやらなかったのなら、僕はきっと何度だってやらずにいるままだろう。

もちろん怖くなかったわけじゃない。なにせ海外なんて行ったことがなかったのだ。ずっと極貧の生活をしてきた僕は、国内旅行だって満足にしたことがない。

いろいろと考えた。ない頭を使って考えた。自分の英語は通じる? 病気になったときは? 荷物をなくしたら? あれこれ考えると心配事ばかりが頭をめぐって、わけがわからなくなる。

最終的に決定打になったのは、自分が何も持っていないという、この状況だった。

そう、僕は何も持っていない。家族友達も、夢も希望も。だけど、そんな人間だからこそできることがあるんじゃないかと思ったのだ。何も持たないからこそ、どこにだって行けるし、何にだってなれる。それはタロットカードの「愚者」みたいなものだ。愚かな者は恐れも何も知らぬからこそ、無限の可能性を秘めている。

心を決めたら後は早かった。

パスポートを取得した。航空券を手配した。住民票を海外転出した。トランクルームを借りた。住んでいた部屋を引き払った。

空港へ向かう電車の中で、懐かしい感覚に襲われた。あの日、ホームレスになったばかりのころの感覚世界が足元から崩れていく感覚。でもあのときとは決定的に違うことがあった。それは、今回は自分が望んでこうなったのだということ。流されるまま生きてきた僕が、初めて自分人生に対して主導権を得た。それだけが決定的に違っていた。それだけで十分だった。足の震えは、これからの旅路への、期待に対する震えなのだった。


初めて踏みしめる異国の地。最初はいろんなものに圧倒された。

自分とは異なる人種、異なる言語。街の看板すらまともに読めない。レストランの注文すらおぼつかない。ちょっと電車に乗るのも大仕事だ。それでも時間をかけてひとつひとつなんとかしていった。

見知らぬ街の匂い、喧騒、バケツをひっくり返したようなスコール、旅の中で出会う怪しい人、優しい人。僕の前でたくさんの風景が流れていく。

川辺のレストランで昼ご飯を食べた後ボケーッとしていると、猫が膝の上に乗ってくる。動くのもめんどくさくてボケーッとしてたら日が暮れてた。そのまま猫と一緒に晩ご飯を食べた。そんな日もあった。

長距離列車に乗っていたとき、車内食にピーナッツバターのようなものが付いていたので、普通にパンに塗って食べた。でも梅干的なものだったらしく、めちゃくちゃ酸っぱかった。「すっぱ! すっぱ!」とかやってたら向かいの席の女の子爆笑していた。僕も笑った。そんな日もあった。

最初は少し移動するのにも大変な思いをした。でもいつの間にか、ローカルバスに乗って気ままに旅するようになっていた。

たどたどしかった英語も、日常会話程度なら普通に喋れるようになっていた。

いろんな国のバックパッカーにもたくさん出会った。お互いつたない英語でやりとりするのも楽しかった。今度は彼らの国にも行ってみよう。だからいつか世界一周に出ようと、僕は心に決めた。

こんな旅に出たところで自分は何一つ変わらないと思ってた。でも、何かが変わってきている。それが何なのかはわからない。たとえば図太さだったり、適当さだったり、そういうのもあるのだけど、何か違う。それよりもっとプリミティブなもの。感情になる前の感情、行動になる前の行動。マグマのような熱量を持ったドロドロとしたものが、自分の中に渦巻いているのを感じる。それがいつ形を成すのかはわからない、今はまだ。だけどいつかどこかで、忘れた頃にひょっこり出てくるんじゃないかと思う。そのときを楽しみにしていよう。

そして夢のような日々は終わる。


日本に帰ってきたとき、手持ちの金は10万以下だった。部屋は解約していたので住むところもなかった。普通にホームレスだった。僕は焦らず慌てず、西成へ向かった。

しばらくはドヤ(安宿)に泊まった。一番安いところなら500円から泊まれる。西成はいいところだ。

宿に住民票を移し、ハロワ失業保険を申請した。

前の会社から戻ってこないかと誘われたけど、「働きたくないでござる! 絶対に働きたくないでござる!」と言って断った。

いや働きたくなかったのは本当だけど、もう1つ理由があった。職業訓練組み込み系を学ぼうと思っていたのだ。

スマートフォン含むタブレット端末の市場がこれからも拡大していくのは間違いない。そうすると必要になってくるのは組み込み系の知識。いやアプリ作るだけなら必要いかもしれないが、そういった知識があれば、自分ができることの幅がぐんと広がると思う。

それに、今の僕には基礎的な力が圧倒的に足りない。すべてを独学で、我流でやってきたけど、やはり限界を感じる場面が多々あった。だから今回ちゃんと体系的に学んで、足元を固めようと思ったのだ。

結果的には正解だったと思う。本当に基礎の基礎から学べた。

ブレッドボードを用いて回路を組むところから始まって、アセンブラC言語組み込みLinuxでのデバイスドライバ開発、アプリ開発。これまで高級言語の十分に進化しきった部分にしか触れてこなかった僕にとっては、どれも難しかったけど、どれも面白かった。これからどういう道に進むかまだわからないけど、ここで学んだことは絶対に無駄にならないと思う。

そうして職訓で勉強するかたわら、悶々と考えていたことがある。世界一周についてだ。

今はまだ金もないし、そんな金を稼げるあてもないのだけど、いつか(たぶん10年後くらいには)行こうと本気で思っている。

ルートだけでも今から考えておこうと思って、いろいろと旅程検討アプリを試してみたのだけど、どれもいまいち使い勝手が悪い。海外のものも含めて探しまくったけど、自分が思うようなものは見つからなかった。

だったらもう自分で作るしかない。せっかくだから就活ときポートフォリオとして使えるよう、ちゃんとしたWebアプリを作ることにした。

最初の1ヶ月は地図APIの選定と、検証コードを書き捨てるだけで終わった。

2ヶ月目は基礎部分の構築だけで終わった。

3ヶ月目に本気を出し、ほぼできあがった。

4ヶ月目でサーバドメインを用意し、最後の仕上げをした。

そしてベータ版リリースした。 http://planetter.com/

それが先週の話。

そして今、こうして増田投稿する文章を書いている。

だからこのお話はここで終わりだ。正確に言うなら、ここから先の展開はまだわからない。


10年間を振り返ってみて思う。あの頃と比べて、何か変わっただろうか?

家族や親類とは縁が切れたままだし、いまだに人付き合いは苦手だし、金はないし、夢も希望もない。それは今でも変わらない。ただ、あの頃あれほど感じていた空虚さは、跡形もなく消えている。

西成の高架下で見た光景を思い出す。ガラクタ解体していたおっちゃん。あのキラキラした目。たぶんあの瞬間に僕は、自分にとって一番大切なものは何なのか、心の深い部分で理解したんだと思う。

世界一周だなんだというのも本当はどうでもいい。僕はただ、いつだってドキドキしていたいのだ。

初めて人を好きになったときの気持ち。知らない街で暮らし始めたときの気持ち。そして、プログラムが思い通りに動いたときの気持ち。

それを持ち続けていたいのだ。いつだって新しい世界にワクワクしていたいのだ。

だから僕は、今日ガラクタのようなコードを書き続けている。

ふと目を閉じれば、まぶたの裏に映る、あの日のメッセージ

"Hello world!"


このお話はたぶんフィクションです。実在の個人や企業とはあんまり関係ありません。でも、ここに綴った僕の想いは、ノンフィクションです。

2012-01-24

http://anond.hatelabo.jp/20120123003316

でもより良いコードを書こうとしてクロージャデフォルト引数、動的スコープといったものを気にしだすと弱点に気づく。

具体的にどんなの?

2012-01-23

http://anond.hatelabo.jp/20120122234606

言語仕様そのものはそんなに酷くない。

でもより良いコードを書こうとしてクロージャデフォルト引数、動的スコープといったものを気にしだすと弱点に気づく。

弱点に気づいた後で、それを直そうとしたり埋め合わせる機能を考えるのが他の言語

これは弱点じゃなくてPython様が与えた試練だから文句を言うなと押し付けるのがPython

2012-01-18

Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1

 

42 : デフォルト名無しさん : 2011/11/12(土) 23:53:51.20

Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ

端末からテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに

PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか?

けどまぁ、情弱文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか

45 : デフォルト名無しさん : 2011/11/13(日) 01:41:24.25

数値計算や端末からテキスト処理なんてWeb系じゃ大して使わないからなあ…

43 : デフォルト名無しさん : 2011/11/13(日) 00:04:23.30

PHPが未だに現役なのは、単に歴史的な経緯でしかないだろ

Pythonに関しては、ZopeさえコケていなければWebサーバLLとして大成功していたはずなのに、

Railsなんかが登場したおかげで、すっかり影が薄くなってしまますた....

44 : デフォルト名無しさん : 2011/11/13(日) 00:49:55.28

zopeってコケてたんだ

ってか、railsインスパイアされたフレームワークって今じゃ幾らでもあるよね

djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、

pythonPHPの方がユーザー数は圧倒的に多いと思うんだけど

本家railsって、他を遥かに越えるほど良いものなんだっけ?

48 : デフォルト名無しさん : 2011/11/13(日) 08:30:25.68

44

Zopeが登場した当時、RDB+PHPはもう古い、これからOODB+ZopeWebの中軸になる!」

さかんに宣伝され、雑誌でもZope特集が組まれていた

 

少なくとも自分ZopeからPythonという言語を知ったし、その時点でRubyは知らなかった

そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう

今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい

 

djangoCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう

しかしRailsはRailsコミュニティの活動が活発だし、その進化は異常に早い

 

Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoCakePHPから

何かのイノベーションが提示されでもされない限り、後発のdjangoCakePHPRailsに追いつくのは無理

Railsは決して技術的に完璧Webフレームワークではないんだけどね....(たとえばSeaSideのような.... )

 

からこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている

51 : デフォルト名無しさん : 2011/11/13(日) 12:55:40.83

 C a k e P H P は う ん こ   

遅い、設計が古い、動作がおかしいの3重苦

日本では流行ってないけど海外だとYiiが流行ってきてる

55 : デフォルト名無しさん : 2011/11/13(日) 17:31:12.14

CakePHP使ってんの?

可哀そうにw

53 : デフォルト名無しさん : 2011/11/13(日) 14:44:48.55

求人PHPばかりだからPHPやるしかないだろ。

57 : デフォルト名無しさん : 2011/11/13(日) 19:34:04.95

でもやっぱりいつもの使い慣れたLL(Python/Ruby)で

Webサービスを書きたいってのがある

73 : デフォルト名無しさん : 2011/11/15(火) 17:32:46.07

アメリカ言語ユーザー数は

Python>>>>>>>>Ruby

求人数は

Ruby on Rails>>>>>>>>Django

http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=

どういうことなの?

74 : デフォルト名無しさん : 2011/11/15(火) 17:48:15.59

RubyRails以外に使い道がないか

75 : デフォルト名無しさん : 2011/11/15(火) 17:54:35.50

海外ではRubyは昨今のRailsバブルのお陰で

もはやWebスタートアップ共通語になってるらしいからね

求人数が多いのはそのためだと思うよ

76 : デフォルト名無しさん : 2011/11/15(火) 18:03:23.05

なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・

Pythonのほうが使いやすいと思うのだがフレームワークRailsが優位なんだろうか

77 : デフォルト名無しさん : 2011/11/15(火) 18:23:14.33

Djangoは周辺ライブラリ微妙だし本体も鈍くさい感じがする。

でも、FlaskはSinatraより好きだからPythonが嫌いってわけではない。むしろ好き。

 

ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。

78 : デフォルト名無しさん : 2011/11/15(火) 18:38:46.28

同感だ

同じように思っている人が他にもいて安心した

79 : デフォルト名無しさん : 2011/11/15(火) 18:54:37.13

PHPJavaScalaには

Railsみたいなフレームワークあるのに

Pythonはいいのないんだよな

80 : デフォルト名無しさん : 2011/11/15(火) 21:19:09.89

PHPフレームワークが乱立しすぎているから、RailsPHPで実装してみようというやつが出てきた。

Scalaも注目されだしたのはつい最近のことだしな。

それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、

つの間にかフェードアウト

ただ、どうやってもRailsもどきRailsを超えることはできないのは間違いない。

83 : デフォルト名無しさん : 2011/11/15(火) 21:25:38.55

パクリオリジナルを超えられない(キリッ って定型句だけど、

これってキリッって言いたいだけだと思う。

後発品が先に出たものを超えたものなんていくらでもあるから

84 : デフォルト名無しさん : 2011/11/15(火) 21:30:04.39

D言語って超えたって?

85 : デフォルト名無しさん : 2011/11/15(火) 21:31:12.00

B言語って超えたって?

86 : デフォルト名無しさん : 2011/11/15(火) 21:53:33.76

でもRailsRubyの黒魔術を使いまくりから

PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない

90 : デフォルト名無しさん : 2011/11/15(火) 22:50:07.81

スタートアップなんて根無し草の集まりにとって、

googleが囲った言語coolさを見出せないんだろ

123 : デフォルト名無しさん : 2011/11/20(日) 11:32:16.79

まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ

91 : デフォルト名無しさん : 2011/11/15(火) 22:52:42.98

そういう理由じゃなくてRailsのほうが単純に情報プラグインも多いからでしょ

3 : デフォルト名無しさん : 2011/11/15(火) 23:07:07.67

linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん

わざわざ不合理で不完全な言語を使うなんて

社会からハミ出た奴らの精神的な作用によるものじゃないの?

95 : デフォルト名無しさん : 2011/11/15(火) 23:20:20.21

django情報プラグインが増えないという、

現実に対する鬱憤を吐いてるようにしか聞こえないな

もしも

linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん

真実であるのなら、今頃はdjango情報プラグインが溢れかえっているはず

104 : デフォルト名無しさん : 2011/11/16(水) 01:20:49.05

Python信者乙。

yumや、gdbgnome拡張pythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。

ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。

94 : デフォルト名無しさん : 2011/11/15(火) 23:15:11.93

というか、世界中Pythonプログラマが Remeber Zope!! を合い言葉

打倒RailsたるWebフレームワークを開発しているはずだけど、

いまだにRailsを超えるプロダクトが登場しないのはナゼ?

Railsも登場してから、かなりの年月が経過しているんだけどなぁ....

その間にもRailsRails 3が登場して、REST/AJAXの強化等の進化継続しているよ

347 : デフォルト名無しさん : 2011/12/09(金) 10:16:35.22

Ruby では

ary.map {|x| x**2}

となるものが、Python では

map(lambda x: x**2, ary)

となり、lambda の本体が1つの式では表現しきれなくなると

def mapper(x):

.....

map(mapper, ary)

書き換える必要があります

348 : デフォルト名無しさん : 2011/12/09(金) 10:24:20.94

Pythonのlambdaを用いた階乗計算

f = lambda x:(x and f(x-1)*x)or 1

RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから

andやorを使った不自然記述をしなくても

f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}

または

f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}

と書けます。lambda内でreturnが使えますから、書きたければ

f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}

でもOKです。

390 : デフォルト名無しさん : 2011/12/10(土) 15:35:41.62

348

これはPythondisっているように見せかけてRubydisっているのか? と一瞬思ってしまったw

だってRubyのほうが長くない?CLのfuncallみたいなcall()がちょっとうざいし…

そしてどっちもlambda式の中で束縛変数名前再帰可能、と

350 : デフォルト名無しさん : 2011/12/09(金) 11:12:13.28

要素に対する関数適用と、抽出を組み合わせる場合

Python

print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]

暗号のように見える。

Ruby

puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}

思考の流れと、コードの流れが一致しているので書きやすい。

351 : デフォルト名無しさん : 2011/12/09(金) 11:22:55.04

だれだPythonなら書き方はひとつとか言ってるのは

map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))

354 : デフォルト名無しさん : 2011/12/09(金) 12:22:07.37

pythonて可読性が高いのをうたってる割にはそこいまいちだよね

353 : デフォルト名無しさん : 2011/12/09(金) 12:10:08.46

Ruby場合には、左から右へと無名関数データフローあるいは

パイプラインのように並ぶからコードが読みやすい

 

関数型プログラミングに不慣れな初心者でも、参照透明性のあるコード自然に書ける

プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby

 

それと比較すると、Pythonコードは、関数型プログラミングというもの

いかに高度で難解なものであるかという事をもったいぶってプログラマ押し付け

 

もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう

356 : デフォルト名無しさん : 2011/12/09(金) 12:53:45.66

階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す

result_list = source_list.map { |elem|

  x = foo(elem.x)  # ここが局所宣言を書く部分

  y = bar(elem.y)  # ここも局所宣言の続き

  x + y       # 最後に評価された式の値が、無名関数のリターン値になる

}

Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから

x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける

このポイントは、実用的なプログラム関数型風で書こうとした時に、威力を発揮する

357 : デフォルト名無しさん : 2011/12/09(金) 12:59:21.07

余計分かりづらくなった

358 : デフォルト名無しさん : 2011/12/09(金) 13:17:26.54

リスト内包表記が暗号みたいと言ってる奴は

高卒ドカタなんだろうなぁと可哀想になる

大学数学に触れる機会があれば

集合の表記に似せてることが分かるから

386 : デフォルト名無しさん : 2011/12/10(土) 01:41:34.46

数学とかで慣れてるし区切りが関数のがわかりやすい

359 : デフォルト名無しさん : 2011/12/09(金) 13:46:31.97

355

map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。

関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね

Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ

360 : デフォルト名無しさん : 2011/12/09(金) 13:53:28.85

Rubyだと直感的に書けるコード

[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')

Pythonだと読みにくい。

'-'.join(map(str, reversed(sorted([1,4,3,2]))))

361 : デフォルト名無しさん : 2011/12/09(金) 14:07:17.88

360

Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....

364 : デフォルト名無しさん : 2011/12/09(金) 14:28:55.99

カッコだらけのコードを分かりやすくする基本的な方法静的単一代入じゃないか

Rubyのやり方は基本ではなく玄人のやり方だろ

372 : 369 : 2011/12/09(金) 16:21:03.82

Pythonでは組み込みの型でメソッドチェインはやって欲しくないな

listにmap,filterメソッドができたとしても、

似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。

シーケンスプロトコルの利点が活かせない。

383 : デフォルト名無しさん : 2011/12/10(土) 01:17:28.39

372

外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてます

Rubyユーザーは列挙可能なものmapselectできて当然だろって思ってる気がしま

377 : デフォルト名無しさん : 2011/12/09(金) 18:41:51.79

Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる

得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない

Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い

379 : デフォルト名無しさん : 2011/12/09(金) 18:48:52.27

Pythonユーザー調教っぷりは異常

「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く

387 : デフォルト名無しさん : 2011/12/10(土) 13:40:40.74

リストの内包表記はシンプルに書けるときは使うけど

基本その場でdefするのがPython風なんだと思う。

389 : デフォルト名無しさん : 2011/12/10(土) 14:40:31.04

無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像

384 : デフォルト名無しさん : 2011/12/10(土) 01:23:49.48

outer(center(inter( arg )))

これを読みづらいと感じるのは、左から右に流れる

日本語文に慣れているからだと思うが、

もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか?

385 : デフォルト名無しさん : 2011/12/10(土) 01:34:57.89

なるほど、ということは右から左、左から右どっちでも行ける言語が最高ですね

F#パイプライン演算子最高ということで

2011-10-17

http://anond.hatelabo.jp/20111017190959

俺も VB はねーだろと思う。

言語仕様云々の前に参考に出来るオープンソースが少ない。

JS関数型な所あるね。関数を第一級で扱える言語はそういう性質が少なからずあるので。

とくに JS はちょっと凝ったことを便利にやろうとすると関数オブジェクトとして使うことになる。

クロージャの循環参照うざいけど。

http://ja.wikipedia.org/wiki/%E7%AC%AC%E4%B8%80%E7%B4%9A%E9%96%A2%E6%95%B0

2011-03-16

ドラゴンボールで学ぶオブジェクト指向」 のクロージャに関して

http://anond.hatelabo.jp/20110316202255 - ドラゴンボールで学ぶオブジェクト指向

また、ポイポイカプセルのように技を塊にして色んな人が使えるように出来ます

var shotKamehameha = new function(){
	//かめはめ波を打ちます。
}

noumin.kougeki = sendKamehameha;
buruma.kougeki = sendKamehameha;

noumin.kougeki();  //カメハメ波がでます

このような仕組みをクロージャと言います。クロージャクロージャの中に記述することも出来ます

って書いてるけど、クロージャってのはそういうものじゃないよなぁ、と。 まあファーストクラス関数オブジェクトっていうところはあってるけど、それだけでクロージャと言えるのかというとちょっと違う。

"a closure is a first-class function with free variables that are bound in the lexical environment." (Closure - Wikipedia) とあるように、関数内の変数レキシカルスコープに結び付けられているようなものがクロージャなのであるJavaScript で例を書くなら、次のようになる。

// クロージャを返す関数
var getClosure = function getClosure() {
    // クロージャからアクセスされる変数
    var counter = 0;
    // クロージャ
    var closure = function closure() {
        return counter++;
    };
    return closure;
};

// クロージャを取得
var closure = getClosure();

// クロージャを実行
closure(); //=> 0
closure(); //=> 1
closure(); //=> 2

匿名ダイアリーで大なり記号とか書くときってどうしたらいいんですかね... ">" ってなっちゃ

ドラゴンボールで学ぶオブジェクト指向ツッコミ

http://anond.hatelabo.jp/20110316202255

亀仙流やつ鶴仙流など、世の中にはいくつかの流派があり、それぞれ
カメハメ波やドドン波、舞空術などの技(メソッド)がある。
実際に技を使う場合、技を覚えているZ戦士(インスタンス)が必要。

クラス = 流派

メソッド = 技

インスタンス = Z 戦士

というのはおもしろいと思うし, 例えばゲームを作るなら実際にそういう実装になると思う.

例)セルを作りましょう。
class Cell extends Goku,Veget,Picoro,Tenshinhan,Kuririn{
....
}
cell_inst = new Cell();
cell_inst.shotKienzan(); //Kuririnをextendsしているので気円斬が使えます

しかし, ここではクラス = Z 戦士になってしまっているので, 混乱を招くだろう.

むしろ, 「JavaScript における prototype」 に絞って説明するのはどうだろう.

(ついでに「撃つ」の現在形は shot でなく shoot ですね)

var Goku = function () {};
Goku.prototype.shootKamehameha = function () {
  console.log("波!!!");
};

var goku = new Goku;
goku.shootKamehameha(); // 波!!!

var Gohan = function () {};
Gohan.prototype = new Goku;

var gohan = new Gohan;
gohan.shootKamehameha(); // 波!!!

そしてセルによる吸収は, 動的な継承として考えるのがより自然だろう.

var Goku = function () {};
Goku.prototype.shootKamehameha = function () {
  console.log("波!!!");
};

var Vegeta = function () {};
Vegeta.prototype.shootBigBangAttack = function () {
  console.log("ビッグバンアタック!!!");
};

var Cell = function () {};
// 吸収メソッド
Cell.prototype.absorb = function (target) {
  for (var method in target) {
    this[method] = target[method];
  }
};

var goku   = new Goku;
var vegeta = new Vegeta;

var cell = new Cell;
cell.absorb(goku);   // 悟空を吸収
cell.absorb(vegeta); // ベジータを吸収

cell.shootKamehameha();    // 波!!!
cell.shootBigBangAttack(); // ビッッグバンアタック!!!

そして次にクロージャの使用例として挙げられた次の例.

例)連続エネルギー波
var shotRenzokuEnergy = function( count ){
	var shotEnergy = function(){
		//エネルギー波を放ちます
	};
	for(var i=0;i<count;i++){
		shotEnergy();
	}
};

この実装では, shotRenzokuEnergy を実行するたびに shotEnergy が毎回定義されてしまい, 非効率である.

以下のように書き換えることで, shootEnergy の定義は, shootRenzokuEnergy の定義時の 1 回のみとなる.

var shootRenzokuEnergy = (function () {
  var shootEnergy = function () {
    console.log("エネルギー波!!!");
  };

  return function (count) {
    for (var i = 0; i < count; i++) {
      shootEnergy();
    }
  };
})();

shootRenzokuEnergy(10); // エネルギー波!!! x 10

ドラゴンボールで学ぶオブジェクト指向

オブジェクト指向の基本

亀仙流やつ鶴仙流など、世の中にはいくつかの流派(=クラス)があり、それぞれの流派にかめはめ波どどん波舞空術などの技(メソッド)がいくつかあります

実際に流派にある技を使う場合、技を覚えているZ戦士(インスタンス)が必要になります

例)亀仙流を覚えた孫悟空を使ってかめはめ波を放って敵を倒す
goku = new KamesenRyu("goku");
goku.shootKamehameha(teki);

Z戦士によっては複数の流派の技が使えたり、自分の技を人に教えることが出来ます継承)。

また悟空クリリンのように同じ流派でも同じ技で違う性能を持っていたり、オリジナルの技を持っているなどの違いがあります

クラスセルを作るためのZ戦士達の遺伝子情報と言っても良いかもしれません。

例)セルを作りましょう。
class Cell extends Goku,Veget,Picoro,Tenshinhan,Kuririn{
....
}
cell_inst = new Cell();
cell_inst.shootKienzan(); //Kuririnをextendsしているので気円斬が使えます


世界の成り立ち

世界プログラミング言語)によってはただの人を後付でZ戦士にすることが可能です

(JavaScriptRubyなど)

noumin = new Hito(); 
noumin.kougekiKuwa = function(){
	//戦闘力たったの5…ゴミめ!
};

noumin.shootKamehameha = function(){
	//な、なんだと!?
};

農民がいきなりかめはめ波うつようになったら危険ですね、危ないです。

このように後付でメソッドを追加出来るタイプ危険性を含んでいます。

クラスインスタンス

http://anond.hatelabo.jp/20110316204446

インスタンスなのかクラスなのかはっきりしろよ・・・

セルを作るならZ戦士(インスタンス)を継承しなきゃならんぞ

とても良いつっこみが来たので追記します。

前半部分ではZ戦士をインスタンスしましたが、セルを作るにはZ戦士がインスタンスでは出来ないので

なのでZ戦士それぞれをクラスという形に再定義しました

何をインスタンスにして、何をクラスにするかが「設計」なんですね。

何がインスタンスで何がクラスか、加えて説明します。

セルの第一段階ではGokuなどのZ戦士の遺伝子があれば作ることが出来ました

cell_inst = new Cell(); //このセルは第一段階

でも第二段階以降は人造人間17号、18号が必要でしたね。

cell_inst.absorb(17gou); //第二段階に変身
cell_inst.call18gou();
cell_inst.absorb(18gou); //最終段階に変身

class Cell ....{
   function call18gou(){
        if(!this.17gou)return error(); //17号を吸収していないと失敗する
        this.17gou.speak("****略*****ドクターゲロ様****略****");
   }
}

この場合、17号と18号はそれぞれインスタンスです

17gouを吸収したので、17号の声で18号を呼ぶことが出来るようになりました

でもドクターゲロ「様」って言ったのでセルだってバレバレですね。

かいセリフは忘れたのでどなたか資料を下さい…。

追記

コメントへのレスを追加。

http://anond.hatelabo.jp/20110316224648

追記2

クロージャについてちゃんと書こうと思って挫折。どなたか良いアイディアを下さい。

変数スコープ解説する必要があるかなと思ったんですオブジェクト指向からは外れるような気がします。

エネルギー波→連続エネルギー波がどこかに使えそうな気がしましたが、気のせいだったぜ…

追記3

続編書きましたhttp://anond.hatelabo.jp/20110319020332

2010-06-29

http://anond.hatelabo.jp/20100628022930

なんか話が合いそうだなと思ったので返信。増田なのがちょっと勿体ない気もするけど。

ちなみに俺のバックグラウンドを書いておくと、学生時代の専攻は工学系なんだけど、それにしてはオーバースペックなぐらい数学をかじってた感じの方面。あんまり詳しく書くと特定されそうなんでこの程度で勘弁ね。

"Pattern Recognition and Machine Learning"のビショップ物理出身だけど、あの年代は確かにそういう色が強かったのかもしれない。

確かにその種の傾向は上の世代までかもしれないね。

ビショップ物理出身なのは知らなかったけど、それ聞いてなんか合点のいく気がした。何か妙に数学へのマニアックなこだわりの片鱗が見える割に、数学屋から見ると妙な記号法を使うんだよね、あの人。

工学としては例外的に高度な(物理の道具としてはまあ普通の)数学を使ったりするので

全然高度じゃないです><

いや、だからあくまで「工学として」ね。線型代数と、微積の「計算」以外を使うことって工学ではそうないでしょ(フーリエ変換とかだって工学の文脈では所詮「計算」だもんね。)。

制御理論とか機械学習では、関数解析の概念がちょっとだけ出てくるけど、あんなんでも数学屋にとってはオアシスだね。

もっとも、カーネル法関係ではいつも申し訳程度にMercerの定理が言及されているのを見ると「なんだかなあ」っていつも思うけど。

情報幾何とかは(無駄に)高度だけど、実用性はあんまないオナニー(しかも日本でしか流行ってない)感があるし。

そうそう、あれに限らず統計学理論の一部にはものすごく違和感あるんだよね。

増田だから書けるけど、情報幾何なんて「お前、双対接続って言いたいだけちゃうんかと」って感じだし、他にも色々、何でも抽象化して一般化すりゃいいってもんじゃないんだぞと言いたくなることが色々。

統計学理論機械学習パターン認識の関係は、数理物理理論物理実験物理の関係に似てる気がするんだよね。しかも統計学場合普遍的に綺麗な構造なんてものがあると思えないだけに余計に始末が悪い。「ひも理論実験で検証できないから科学ではない」って批判があるらしいけど、統計学にも同じ批判されても仕方ない理論が色々あるよね。データから何かを推定する理論なのに、データがどれだけあっても実用的には絶対まともな結果が出せないモデルとか。

CVレイトレーシングで経路積分使って云々というのもあったけど(その人はGoogleに言ってアドセンスかなんか作ってるらしい)、あれもまぁ適当パス空間で平均とるだけって感じがするし…。

CVはまあ何でもありの世界だよね。誰か無限次元リー群とか使ってみてくれないかなと思う。というか俺自身が一度やろうとして無意味なことに気づいてやめたんだけどさ。

結局性能はあんま変わらないからもっとシンプルモデルでいいよとかなってそう。

イジングモデルとかその辺は不勉強なんであまりよく知らないんだけど、一般的にその手のモデルは、性能が変わらないだけならいいけど、計算量がどうとかデータ量がどうとかで事実上使えなかったりすることが多いんだよね。着想として物理からアイディアを持ってくるのはいいんだけど、物理から持ってきたアイディアなら必ず筋がいいはずみたいな思いこみ(そう思いたくなる気持ちはよくわかるけど)はどうかと思う。

普通に日本の伝統新卒採用でそういう会社に行く人はいるけど、やってることは工学とかあるいは良くわからない専攻の人と同じな気がする。これはちょっと曖昧だけど。

うん、そうなってしまうのは仕方ないでしょうね。

ただ逆に、変わり種のバックグラウンド持ってる人は道具箱が豊富だから、新しいこと思いつく可能性もあるわけで、採用されるとしたらむしろそれを買われてじゃないかな。俺自身、工学部の人は普通は絶対知らない数学を色々知ってるので、それをどうにか武器にできないかいろいろ試行錯誤中だよ。というか特許とかの形で発表したのもすでにあるけどね。

特に情報系の分野は実装力で評価されることが多いし…。実装力は数値計算得意とかそういうのとは全く別のスキルだよね。プログラミングマニア的な要素が必要。

分野にもよるけどね。情報システム計算機自体を専門にして、ハードとかインターフェイスに近い部分をやってたらどうしてもそうなるけど、信号とか画像とか音声とか言語とかの処理のコア部分を作るときにはコーディング能力よりも紙と鉛筆能力の方が大事・・・、だと思いたい。

どうもパソコンマニア的気質は中高生のときに飽きてしまって、「PCパーツの種類とか流行言語とか覚えたってどうせ10年したらすぐに廃れるんだから」という感じで、余りはてな民的に新しいネタ追いかけたくないんだよね。クロージャって何ですか、ああそうですね閉包ですね、集合の内部と境界の和集合ですねっていう感性の持ち主なので。正直、コーディングは単純作業と認識してます。

2010-01-28

IT土方なんて、ただの甘えでしかない

自分仕事を「IT土方」なんていってる奴に出くわした。はっきり言えば、ただの甘え。と言うか、愚図。

こういう連中のせいで、エンジニア全般の価値が下がっているわけで、さっさと営業でもなんでもやってりゃいい。

お前と俺が同じ職業?ご冗談もほどほどに、だ。

出来るといわれる人々は、下記を否定しないはずだ。

エンジニア仕事ほど、未来があって、毎日が新しいくて面白い仕事はない。

これから先、人の生活に益々コンピューターが入ってくる、ハードウェア技術進歩もまだまだ止まらない。

そろそろ頭打ちになって来たって言われてるCPUだって、まだしばらくはムーアの法則に従う見込みだ。

シリコンフォトニクスとか夢見たいな技術も実現すべく日々研究されている。

そうしてハード進歩すれば、開発技術もあたらしくなる。当然そこに新しい仕事がうまれていく。

仮に量子コンピューターが実現すれば、言語そのものに変革が起こる。

それを学べるってだけで涎が出るだろ?でなきゃおかしいんだよ。

毎日同じ様にだ。今持ってる知識で解ける範囲のみで仕事をしてれば、それは昨日とは何も差が付かないし面白い訳がない。

日本エンジニア馬鹿というかクソだと思うのは、平気で人が作ったものを何も考えずに使って仕事をすること。

そして使えることを技術だとのたまう事。そんなんで技術が付くかカス

Hadoop使ってないで、key-value位は自作しようとしやがれ。

結果使うことになっても、作ろうとした過程で手にした経験ほど面白いものはないはずだろ。違うのか?

そしてもうひとつ日本エンジニアの大多数は数学がまるで分からないってこと。

いいか。エンジニア文系仕事じゃない。コーダーエンジニアプログラマって括りでまとめるな。

エンジニアリングを本気でやるなら、他の工学と同じようにコンピューターサイエンスを理解し使いこなせるだけの

数学の素養が必要だ。線形代数とか微分積分解析学エンジニアなら離散フーリエ解析くらいはわかっていて当然だろ?

だから思う。

IT土方とか言ってる奴は甘えてないで、仕事の中に面白さを探して作ればいい。

C#を使ってるなら、バリバリクロージャーを使えばいい。

プロジェクトが火を吹いてるなら、アジャイル・ディベロップメントでも試せばいい。

何か面白そうな論文を見つけたなら、読んでおいていつか実装しようと虎視眈々と狙ってればいい。

アルゴリズマーの知識が羨ましければTopCoderにでも行けばいい。

ソフトウェア世界にはコミュニティが幾つも開かれていて、学ぼうとする人や毎日を変えようとする人の

全てを受け入れてくれる。そりゃあ残業が多くて時間がないのかもしれない、それなら残業しないで余暇

勉強に当てられる環境転職したり、仕事の10%を勉強に当てる事を認めさせたり、したらいい。

ソフトウエア世界には、面白いものがいくつでも転がっていて、そして誰も拒絶されない。金も殆どの場合

かからない。だれでも、第一線の技術を作れるし、学べるし、楽しめる。

俺は6年エンジニアをやって3回転職したよ。海外でも働いた。

今は楽しんでいるし、この仕事を死ぬまで楽しんでも居たい。

今IT業界がつまらないと思ってる人は、もう一度言語を学び始めた頃の気持ちを思い出してみて欲しい。

あの頃は毎日が面白くて、試してみたいこと、知りたいことが山の様にあったはずだ。

その気持ちを何年でも変わらず保ち続けることが大事だよ。

IT土方なんて、ただの甘えだ。

毎日が楽しくなるなら、営業でもなんでもやればいい、ただし営業だって学ばないやつは使えないと思うよ。

ただ逃げたいだけの奴には、逃げ場なんかどこにもない。

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