「再帰呼び出し」を含む日記 RSS

はてなキーワード: 再帰呼び出しとは

2019-03-15

anond:20190315213851

一般人から全部暗号しか見えない。

検索したら関数型とか出てきたが関数型も分からない。

関数型はfor文を使わないで再帰呼び出しを使う印象しかない。

あと一般人から、なぜFacebookGAFAと呼ばれ恐れられているのかも分からない。

一般人でもグーグルアップルアマゾンがすごいらしいことは分かるが。

2016-05-01

社会人数年目で年収2000万越えた私が考えるプログラマキャリア

こんにちはシャイニング増田(シャイ増)です♥町中で良くリクルートスーツ就活生を見るようになりましたね。先日後輩の紹介で○○大学学生からグーグルに入りたいという相談を受け渋い気持ちになりました。○○大学ではTopCoderRed Coder相当の実績でも残していないと入れないでしょうし、ネームバリューだけでなんとなく「ビッグデータ♡」「人工知能♡」と言っている様は山師スタートアップの「フィンテック事業部を新設しました」のIRと同等クラスの浅ましさです。そこで若者に捧ぐ私が考えるプログラマキャリア論を参考にしていただければと思います

と、シャイニング丸の内さんの年収1000万越えの記事

http://www.shiningmaru.com/entry/2016/04/29/212824

を見て、あんまりプログラマがどうやって高給取りになれるかというキャリアの話って見たこと無いな、と思ったので書いてみます

全てのプログラマ給料を一杯稼ぐことを目指すべきだとは思いませんが、私のように、研究職でもなく、マネージャー職でもなく、コード書いてお金が貰えるならなんでも書くよ、という節操のないプログラマ志望の大学生にはとてもおすすめの高給取りになるための方法です。

プログラマで高給取りになりたかったらどんな仕事すればいいの?

まずは目標である高給取りになるにはどうすればいいか考えてみましょう。どんな能力があれば年収1000万円もらえるの?と思われるかもしれませんが、そもそも残念ながら給与というのは純粋あなたスキルによって上下する余地はあまりありません。

年収500万円のプログラマが頑張って仕事後も勉強会などへ行き、頑張ってスキルアップしても、会社年収を1000万円にしてくれることはほぼ無いと考えてください。年収500万円のプログラマ年収1000万円のプログラマの一番大きな違いは職場です。大抵の会社はどんなに優秀なプログラマでも給料大金を払うことはできません。

身も蓋もないんですが、高給取りになりたいと思ったら、自分磨きなんて糞くらえで、自分給料を一杯払ってくれる会社を見つけて入社するのが一番重要です。

じゃあどんな会社で働けばいいの?

金回りがいい会社が一番です。どういうところがいいの?というと、ざっくり2つのグループにわかれると思います

1. 世界的にシェアのあるサービスプロダクトを持っている会社

2. 金回りのいい業界企業の社内システム

1の典型的企業は、ベイエリアとかにある、世界向けのプロダクトを持っていて、競争力のある会社です。とても金回りがいいです。有名どころではGoogleFacebookAppleや若干株価が心もとないTwitterなんかがあります。何故これらの会社プログラマ大金を払い、何故日本の大抵の会社プログラマ年収1000万円を払えないかについてはhttps://note.mu/whynotgetrich/n/nd71f86a3e0cbを御覧ください。

2はあまりプログラマの人は縁がなく、存在すら知らない会社が多いのではないでしょうか?とても勿体無いですね。例えば金融系の企業はとても金回りがよく、社内システムの開発でもその恩恵を受けることができます。例えば外資金融系ではGoldman Sachs、Merrill Lynchは給与がよく、保険系では東京海上とかもまったり年収1000万越えるらしいんで、狙うといいんじゃないですかね。あまり詳しくないので、具体的な業務内容はインド発注管理するプログラマというよりはSEなのかもしれないですけど。

では他のドメスティックネット企業はどうなの?というと、残念ながらあまりいい話は聞きません。

数年前に年収1000万円で新卒採用(http://news.livedoor.com/article/detail/5997716/)、みたいな話が数社から出てきて、ようやく日本でも人材獲得競争が激しくなってきたな!と思いましたが、どうなったんですかね?全然うまくいかなかったからもうやっていない、という話を聞きましたが、実際どうなのか現場の話を聞いてみたいものです。

私が最近聞いた中ではLine年収1000万円を軽く越えるオファーを出していて、他のインセンティブもついてたら、上場したあかつきには軽く2-3000万円はいくんじゃないかと思われますLineくらいになってくると、1のグループに入ってる感じですね。景気いいですね。うらやましいです。

そんな会社全部よくわからないよ!無理だよ!私が志望しているこれらの会社の中からだったらどれ選べばいいの?と思ったら技術部門の最高責任者っぽい人とかの給与を調べましょう。それより多くは絶対にもらえません。あとは平均給与を調べてみましょう。プログラマは社内の中でも特に多く給料が貰える職であることは少ないと思われるので、平均給与が1000万円越えてなければ、プログラマとしてキャリアを積んで1000万円の大台に達することは難しいかもしれません。

大学卒業までにどんなスキルを身に付ければいいの?

と、1000万円を稼げる企業がおわかりいただけたかと思いますので、次にこれらの企業入社するにはどうすればいいかについて考えてみましょう。

まず先に2のグループ企業についてですが、私は全く明るくないので、どんな採用プロセスなのか全然わかりません。とりあえず英語憶えてたほうが外資系選択肢に入ってくるのでいいんじゃないですかね?

次に1ですが、こちらもやはり英語がわかると、海外での勤務が選択肢に入ってくるので同じくおすすめです。新卒日本法人に入る場合は、企業によってはちゃんと英語習得のためにフォローが入るので、技術力優先だったりもします。

ここまできてようやく技術の話が来ましたが、具体的に何ができればいいの?というと、まずポインタ再帰呼び出し理解できるか調べてみましょう。

Joel先生が書いてますが、ポインタ再帰呼び出しはどんだけ優秀なプログラマでも何故か書けなかったりするので(http://local.joelonsoftware.com/wiki/Java%E3%82%B9%E3%82%AF%E3%83%BC%E3%83%AB%E3%81%AE%E5%8D%B1%E9%99%BA)、まずこれらをちゃんと理解してるか見てみましょう。私も世界中の100を越えるプログラマ面接を行ってきましたが、再帰呼び出しを書かせようとすると絶望するプログラマはとても多いです。

ポインタは使う機会は大分減ったと思いますが、再帰呼び出しはまだ現役なので、理解できなくて、プログラマになりたいわけではなく、ただ高給取りになりたいのであれば、別のキャリアを目指した方が楽かもしれません。

採用において重要なのは履歴書の実績と面接での技術力です。ベイエリアなどの企業プログラマ採用面接では、「あなた自身動物に例えると何ですか」みたいな質問を聞いてくることはありません。技術的な質問、又はコードを書かせる問題を出してきますTop Coderのような競技プログラミングと似てるので、練習しておくことをおすすめします。各種データ構造アルゴリズム計算量を憶え、うまく適用できるよう勉強しましょう。

面接官によってはコンピュータネットワークの仕組みについて聞いてきたりするので、ヘネパタ、オペレーティングシステム、詳解TCP/IPあたりは読んどくといいかもしれません。後々色々な技術を学ぶ時に理解が深まりやすいので、どちらにせよ読んでおいて損はないです。

面接対策だけでなく、プログラムはよほど専門的な内容でなければ、レファレンス引きながら問題なく実装できる、というレベルには達しておきましょう。履歴書に華を添えるなら、オープンソースプロジェクトに参加するかソフトウェアサービスを公開してみてください。githubアカウント名やプロダクト名、サービス概要URLを書いておけばあなた技術力がより上手く伝わるはずです。

外資だと必要になる英語ですが、技術的な話がを中心であれば、一般会話より必要ボキャブラリが限られており、習得は思われているほど難しくはありません。かつ、メールテキストベースでのやりとりが中心であれば、最初のうちは大変ですが、ゆっくり時間かけることもできます

採用された!どうすれば1000万貰えるの?

あなた技術力が認められ、年収1000万円はないかもしれませんが、結構な高給取りになれました。おめでとうございます!さてここから昇給するにはどうすればいいのでしょうか?

(シャイニング増田先生次回作にご期待だくさい!)

お金が大好きなシャイニング増田先生過去作品はこちら:https://note.mu/whynotgetrich

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 まとめ

2008-10-31

http://anond.hatelabo.jp/20081031010058

エントリについている『大はずれだろ。どこが「名前の由来」やねん。』云々は別増田です

口調が違うのでわかります。

ちなみにそのエントリについてるエントリも私とは別増田です。

より多くのものを表現できることを表現力が高いというと思うのですが。

ループ処理を再帰で書き直したときの話をしています。

今回の場合、再帰で表現できるのはループ処理だけですが、再帰には他の表現もあるため可読性の点でマイナスに働いてしまいます。

まぁ、それがシンプルでわかりやすい、ということですが。

それはそれとして、再帰呼び出しは「呼び出し」と言うぐらいで、関数呼び出しの一種ですね。

(今までそういう話は出てなかったですが、改めて合意します)

ここで出てきた。http://anond.hatelabo.jp/20081028222130

「同意する」とも次のエントリ記述されている。

で、再帰の考えにおいて私とあなたは同一の認識なので話をつめる必要性を感じない。

http://anond.hatelabo.jp/20081030193739

エントリについている『大はずれだろ。どこが「名前の由来」やねん。』云々は別増田です

(って言っても増田だから説得力ないかもしれませんが)

さて、

表現力としても再帰処理よりループのほうが優秀だと思うな。

再帰処理はループ以外の処理もできるけれど、ループループしかしないからね。

より多くのものを表現できることを表現力が高いというと思うのですが。

ループの方がシンプルで判りやすいぞ、というのであれば(前にも書きましたが)人それぞれなので特に否定しません。

これが再帰呼び出しではなく関数呼び出しを表しているというのには合意してもらえたでしょうか。

再帰関数呼び出しの一種だと言ったし、あなたも同意したではないか。

えーと、従前からの私の主張は「ループ再帰呼び出しの一種である」ということです。

それはそれとして、再帰呼び出しは「呼び出し」と言うぐらいで、関数呼び出しの一種ですね。

(今までそういう話は出てなかったですが、改めて合意します)

だからといって、再帰呼び出しの説明として、(再帰呼び出し以外のすべての関数呼び出しにも当てはまってしまうような)一般的な関数呼び出しを持ち出すのは範囲が広すぎると思いませんか。

というか、以下の言い方だと何でも再帰呼び出しになってしまいますよ。

再帰処理って処理を停止して新しい処理を行い、終了後に停止していた処理に戻ることじゃない?

処理A -> 処理B -> 処理A が再帰処理の名前の由来でしょ?

すなわち、

A() { B(); }

ですら再帰呼び出しだということになってしまいますが、それはやっぱり説明として変でしょう?

2008-10-30

http://anond.hatelabo.jp/20081030015647

別に怒っちゃいないよ。

表現力としても再帰処理よりループのほうが優秀だと思うな。

再帰処理はループ以外の処理もできるけれど、ループループしかしないからね。

これが再帰呼び出しではなく関数呼び出しを表しているというのには合意してもらえたでしょうか。

何を今更。

再帰関数呼び出しの一種だと言ったし、あなたも同意したではないか。

http://anond.hatelabo.jp/20081029183233

最初のネタ扱いの書き方が失礼だったことは申し訳なかったですが、どうかカッカしないで欲しい...。

で、結局、何を「メリット」と考えるか、何を軸に「大小関係」を考えるのかがずれているのだと気づきました。

それで、元々のプログラムループ記述されていた場合、わざわざ再帰処理に書き換えるには明確なメリットが必要だと思う。

「forを再帰で代替するなんて、どういうメリットがあるの?」という大元増田の疑問に対して、「ループ再帰の一種なので、表現力としてはメリットデメリットもありませんよ(大小関係はないですよ)」と申し上げましたつもりでした。

まあ、そもそも元がfizz_buzzの書き換えの話だしね。

再帰に書き換えて俺のプログラムが速くなるのか」というのなら、処理系もよりますが速くなったり遅くなったり変わらなかったりすると思います。

それで、一番引っかかっているのが、これ。

再帰処理って処理を停止して新しい処理を行い、終了後に停止していた処理に戻ることじゃない?

処理A -> 処理B -> 処理A が再帰処理の名前の由来でしょ?

これが再帰呼び出しではなく関数呼び出しを表しているというのには合意してもらえたでしょうか。

2008-10-29

http://anond.hatelabo.jp/20081028222130

元増田と違う人かもしれないが、

言語によるのかも知れないが、私が触ってきた言語では全部自分自身を関数呼び出しすることを再帰と言っていた。

これには同意します。しかしながら、

再帰処理って処理を停止して新しい処理を行い、終了後に停止していた処理に戻ることじゃない?

処理A -> 処理B -> 処理A が再帰処理の名前の由来でしょ?

これは再帰呼び出しの説明としては、やっぱり変だと思いますよ。

ネタ扱いしたのは悪かったですけど。

これも言語によるのかも知れないけど、私が触ってきた言語では再帰スタック領域を消費していた。

理論上は同じループ処理かも知れないが、現実的には違うものであり、ループのほうが一般的に処理コストが小さいはず。

もちろん、別増田も指摘している通り、すべての言語が末尾最適化されてるわけじゃありません(ついでに言うと、すべての再帰呼び出しループに変換できるわけでもありません)。

しかし、gccですら(条件付きながら)末尾再帰最適化してくれるご時世ですから、必ずしも「再帰スタック領域を消費」「ループのほうが一般的に処理コストが小さい」とは言えないと思いますよ。まあ、gccなんぞ知らんと言われればそれまでですが。

というか、もともとはプログラム構造の書き換えの話で、処理系の実装の話をしているつもりはなかったのですけどね。

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