字幕表 動画を再生する 字幕スクリプトをプリント 翻訳字幕をプリント 英語字幕をプリント [Applause] [拍手] Hi! こんにちは! First of all, まず初めに、 I just want to give a big shout-out to the organizers of this conference. このカンファレンスの主催者に大きな 感謝を伝えたいと思います。 I feel like this has been a fantastic smooth experience from start to finish, 初めから終わりまで、素晴らしく、そしてスムーズな カンファレンスであるように感じます。 so... ですので・・・ [Applause] [拍手] Amazing job. 驚くべき仕事です。 Hi! I'm Anjana Vakil. こんにちは!私はアンジャナ・ヴァキルです。 I am an English teacher turned computational linguist 私は英語の教師から数理言語学者に、 その後ソフトウェア開発者に turned software developer 職業転換した者です。 and as I mentioned a little bit earlier today, そして、今日少し前に述べたとおり、 about six months ago, I knew nothing about functional programming 半年ほど前までは、関数型プログラミングについて 何も知りませんでした。 and very little about JavaScript. そして JavaScript についても ほとんど知りませんでした。 So, what I want to do today is kind of ですので、今日私が皆様に話したいことは、 take you guys along on some of the things I've learned JavaScript で関数型プログラミングを 行うことについて、 about doing functional programming in JavaScript 私が学んだことのいくつかです。 and I am not an expert in any of this, 私はこのどれにおいても 専門家ではありません。 so this is going to be me taking you along on my learning journey ですので、私の話は皆様を 私の学習の旅にお連れするだけで、 and nothing more. それ以上のものではありません。 I'm going to try and save a little time for questions at the end, 最後に質問のための時間を 少し取っておきたいと思っていますが、 but we'll see how that turns out. やってみないと分かりません。 So, how did I end up standing here さて、私はどのような過程を経てここに立ち、 talking to you guys about functional programming in JavaScript? 皆様に JavaScript の関数型プログラミングに ついて話しているのでしょうか? About six months ago in the fall of 2015, 半年ほど前、2015年の秋、 I went to a programming community in New York City 私はニューヨーク市の The Recurse Center という called The Recurse Center プログラミングコミュニティに行きました。 which quick plug ちょっと宣伝っぽくなってしまいますが、 is probably the best programming community I've ever experienced そこは私がこれまで経験した中で最高の プログラミングコミュニティーでした。 and it's a programming retreat コンピューターサイエンスの where you can go and learn about 世界の中で、自分が関心を whatever is interesting to you in the world of computer science 持っていることについて学ぶことができる プログラミングの合宿なのです。 and so I got there 私がそこに行ったとき、 and a lot of people were talking about functional programming, 多くの人たちが関数型プログラミング、 Haskell、Clojure など functional programming, Haskell, Clojure, all this cool stuff, 面白そうなことについて 話し合っていました。 a lot of people were working in JavaScript getting into node 多くの人たちが JavaScript で仕事をしていて、 ノードにのめり込んでいました。 and these were some really interesting topics どれも大変興味深いトピックで、 and so I started talking to people there 私はそこで他の人たちと話し始め、 and finding out what is all this stuff. それらが何なのかを 解明し始めました。 So, what is functional programming? では、関数型プログラミングとは 何でしょうか? Few different ways that question can be answered. この質問にはいくつかの 異なる視点から答えることができます。 First of all, it's a programming paradigm. それはまず、 プログラミングパラダイムの1つです。 Some other paradigms are like imperative programming その他のパラダイムは、これをしろ、 where you say do this and then do that あれをしろ、という命令型プログラミング。 or object-oriented programming そしてオブジェクト指向プログラミングですね。 which maybe a lot of you write object-oriented JavaScript 皆様の多くがオブジェクト指向J avaScript を 書くために使用しているのではないでしょうか。 where you have objects and they have methods on them オブジェクトがあって、その上にメソッドがあり、 and you change them, etc., etc. それらを変更するというような プログラミングです。 Functional programming is also a paradigm 関数型プログラミングもパラダイムの1つで、 where functions are king そこでは関数が王様です。 and we'll talk about what that means in a little bit. それがどういう意味かは後でお話しします。 It's also a style of coding, 関数型プログラミングは、 コーディングのスタイルでもあり、 of organizing your code, コードを整理するスタイルでもあり、 writing your code, コードを書くスタイルでもあり、 style of approaching projects プロジェクトへの アプローチのスタイルでもあり、 and really more than that it's kind of a mindset you can get into, そしてそれ以上に、関数型プログラミングは 考え方の一種で、 a way of thinking about a problem, 問題についての考え方、 a way of approaching a task タスクにアプローチする方法、 and it's also a really sexy trend そして本当にセクシーなトレンドでもあります。 with lots of buzzwords that'll make you super popular プレカンファレンスパーティーなどで 他の人たちと話しているときに、 when you're talking with people at the pre-conference party or whatever it is. あなたを超人気にしてくれる 沢山の流行語を含み持っています。 No, just kidding. それは冗談として、 But it is something that's gotten a lot of attention 関数型プログラミングは、 高い関心を集めています。 and, so yeah, I thought it was important そのため私は、みんながそれほど to find out why everybody was so excited about it. 夢中になっている理由を知ることが 重要だと思いました。 So, why do functional programming in JavaScript specifically? では、なぜ特に JavaScript で 関数型プログラミングを行うのでしょうか? Well, I don't know about for all of you, もっと経験豊富な JavaScript 開発者の perhaps more experienced JavaScript developers, 皆様はどうか分かりませんが、 but when I started learning JavaScript 私が JavaScript の学習を始めたとき、 having had some object-oriented programming experience with Java, C-Sharp, Java、C-Sharp などでの オブジェクト指向のプログラミング経験が that kind of thing, ありましたが、 I found object-oriented JavaScript super confusing, オブジェクト指向の JavaScriptは 非常に分かりにくいものでした。 prototypal inheritance, how does that work? プロトタイプの継承?それはどのように機能するの? という感じでした。 How many of you guys, quick show of hands, オブジェクト指向の JavaScript で 何かをしていて、 have ever run into a bug or a problem or something unexpected with this, バグや問題や何か予期せぬことに 遭遇したことがある人は doing something... 手を挙げてみてください。 Yeah, exactly. Right? ええ、やっぱり。そうですよね? So, I found that really tricky and confusing ですので、私にはそれが トリッキーに感じ、混乱しました。 and so I thought, all right, I know I want to get more into JavaScript そこで私はJavaScriptについて より深く知りたくなりました。 but let me set aside the object orientation でも、オブジェクト指向については ひとまず置いて、 and try to think about things in a functional way 関数的な観点から 考えてみましょう。 which is maybe simpler in some ways その方が簡単かもしれません。 and avoid some of these problems すると、これを間違った対象に like bugs introduced by binding this to the wrong thing. バインドして発生するバグなどの 問題を回避できます。 So, functional JavaScript to me at least is a bit safer, ですので、私にとって 関数型 JavaScript はより安全で、 a bit less tricky, より簡単で、 a bit easier to debug デバッグしやすく、 but easier to maintain as you're building a project プロジェクトを構築する際に より維持しやすいと感じます。 and we'll take a look at some of the features これをより簡単にしてくれる機能については、 that make that easier in a bit. 後ほどお話しします。 Also, there is already a huge community of developers また、JavaScriptに 関数的なアプローチをする who are doing JavaScript in a functional style, 開発者の大きなコミュニティが 既にあるため、 so there's a lot of libraries out there 関数型 JavaScript を 書くにあたって役立つ to help you write functional JavaScript. ライブラリが 充実しています。 There's a lot of people out there that are experts in this, これを専門とする 多くの人がいます。 for example, there was a talk in the next room over earlier today on Ramda 例えば、先ほど隣室では Ramda に ついての講義が行われました。 and there are people here you can talk to そして、ここでは、おそらく私よりも that probably know a lot more about functional JavaScript than I do, 関数型 JavaScript について 詳しい方々とも話すことができるでしょう。 but the point is there's already a community, 私が言いたいことは、既にコミュニティが 存在しているということです。 so this isn't necessarily something you'd be doing on your own, ですので、必ずしも独りで JavaScript と grappling you versus JavaScript, 真っ向勝負をするわけではありません。 there's other people to support you, サポートしてくれる人たちがいて、 which I found really helpful. それは私の支えになりました。 Okay. OK。 So, hopefully by now I've convinced you さて、皆様に関数型プログラミングが that functional programming is at least interesting 興味深いものだ、と納得 いただけたかと思います。 and that we could do it in JavaScript to avoid these headaches, etc. そして、それを JavaScript で行うこと によって、頭痛の種などを回避できる、とも。 How can we do it? では、どうすればできるか? What does it mean? それはどういう意味なのか? This is what I was asking myself. これは私が自問した内容です。 So, the main thing さて、これは and maybe it sounds like a tautology or obvious is that 同語反復のように 聞こえてしまうかもしれませんが、 in functional programming 関数型プログラミングの目玉は you want to do everything with functions, すべてを関数を軸に行うことです。 so we want to express everything in our program in terms of functions. ですので、プログラム内のすべてを 関数的な観点から表現します。 And a function of course is just something もちろん関数とは that takes an input and gives an output. 入力に対して 出力を返すもののことです。 So, we want to be thinking about ですから、プログラム内の kind of the flow of data of inputs and outputs through the program, 入出力のデータの流れに 焦点を当てることになります。 instead of thinking about objects and how they interact オブジェクトや、それらの相互作用方法や、 and how they manipulate 処理方法、 or thinking about steps in a recipe like in an imperative style. 命令型のレシピのステップ について考えるのとは違います。 Here we're really thinking about how we can express everything ここでは、入力を受け、出力を返す、 in terms of functions, すべてを関数で表現する方法を taking inputs, giving outputs. 模索しています。 So, for example, 例えば、これは、 this would be a non-functional way for me to get the text 「Hi, I'm Anjana」 というテキストを “Hi, I'm Anjana” to appear on the screen. 画面に表示させる、非関数的な方法です。 I could assign a variable, I call it “name” name という変数を宣言し、 and have it store the text “Anjana.” そこに「Anjana」というテキストを 代入します。 I could have a greeting like “Hi, I'm” or “Hello, I'm”, whatever, 「Hi, I'm」または「Hello, I'm」を 変数の greeting に代入し、 and then I could log that to the console. それらを console.log() で 表示することができます。 This is sort of an imperative style. これは、初めにこれをして、 First do this, then do that, then do this other thing, 次にあれ、その次に別のことをしろ、 という命令型のスタイルです。 we don't have functions here, ここには関数が含まれていません。 we're not expressing this in terms of how inputs are transformed into outputs. これは、入力がどのように出力に変換されるか、 という観点からは表現されていません。 So, maybe a more functional way of doing the same thing ですので、同じことを より関数的な方法で行うには、 and this is a really simple example, just for the sake of it, これはあくまで簡単な例ですが、 is to define a function called greet name というパラメータを受け、 which takes a parameter name name の先頭に and returns a string which adds “Hi, I'm” 「Hi, I'm」を加えた文字列を返す、 to the beginning of that name. greet という関数を定義します。 So, for example, if I type greet, 例えば私が greet と書き、 the string Anjana, Anjana という文字列を feeding that as input 入力として与えると、 then I get the output “Hi, I'm Anjana”, 「Hi, I'm Anjana」という出力が返ってきます。 that's a more functional way expressing this in terms of functions. これが関数を用いて表現する、より関数的な方法です。 Okay. So, another... それではもう1つ・・・ maybe the main thing about functional programming もしかしたら関数型プログラミングの目玉は is to avoid side effects 副作用を避け、 and instead to use pure functions. 代わりに純粋関数を 使うことなのかもしれません。 So, what does that mean? これは どういうことでしょう? A side effect is anything that a function might do 副作用とは、関数が行う that isn't computing its output from the inputs you've given 入力をもとに 出力を算出し、出力を返すこと and returning that output. 以外の行動のことを言います。 So, for example, 例えば、 printing something to the console is not returning an output, コンソールに何かを表示するのは、 出力を返すのとは違います。 it's doing something else, 関数側で、 something that's on the side of the function 別のことをしているわけです。 or if you have a function that uses some globally defined variable 出力を算出するにあたって、 関数への入力だけに頼るのではなく、 to compute its output グローバルに定義された that doesn't depend only on the input to that function, 変数を使用する 関数などは、 so that's not pure. 純粋ではありません。 It's taking something from outside the function これらは関数の 外にあるものを持ち込み、 and involving it in some way in what the function does. 関数の動作に何らかの形で 関与させています。 So, this is just a really quick explanation of what a pure function では、副作用を避ける 純粋な関数がどういったものか、 that avoids side-effects would do. 簡単に説明します。 For more information on that このトピックについては、 there's excellent Wikipedia articles on these sorts of things, 素晴らしい Wikipedia の記事が いくつかあります。 but basically the idea is that 要約すると、 you want your function to do nothing 入力を受け、それだけを基に except take its input, use that and only that 出力を算出し、 それを返す to compute an output ということ以外の and then return it. ことをして欲しくないのです。 That's pure. これが純粋なのです。 So, for example, this function here, 例えば、この関数の場合、 we have this globally defined variable name グローバルに定義された 変数 name があり、 which gets used in the function それが関数内で使用されます。 as you can see in the last line there, ご覧の通り、最後の行で使われます。 it gets used, so there's no input, ですので、入力がありません。 we don't have name as an argument to this function, name はこの関数の 引数になっていないため、 it's just reading something in from the global state. グローバルな状態から何かを 読み込んでいるだけです。 That's not pure. これは純粋ではありません。 Also, not pure because 純粋ではない理由はもう1つあります。 the return value of this function here isn't what we care about, この関数の場合、戻り値は ここでは気にしません。 we care about doing something, 何かを行うこと、 changing the world in some way 世界を何らかの 形で変えること、 other than the return value, 戻り値を求めているのではなく、 in this case, printing to the console. この場合、コンソールに 表示することが目的です。 So, this is a not pure function here. ですので、この関数は純粋ではありません。 A pure function might look like this. 純粋関数は次のようになります。 Here we have, ここに、 the only thing that matters この関数の出力に to the output of this function is its input, 唯一重要なものは 入力で、 the argument that we pass to it 私達が渡す引数があります。 and the only thing that it does is return its output. そしてこれが唯一行うのが、 その出力を返すことだけです。 Okay, so I've been talking for a while now about pure functions さて、しばらく純粋関数 についてお話ししましたが、 that's because this is really like a key thing at least for me, それもこれが私にとって、とても 重要なトピックだからです。 something I've taken as one of the key parts of functional programming 関数型プログラミングの重要な 一部として私が学んだのが、 is thinking about things as purely as possible. 可能な限り純粋に考える、 ということです。 Another key point would be using higher-order functions. もう1つのポイントは 高階関数を使うことです。 So, this means functions that can take as inputs other functions 高階関数とは、 他の関数を入力できる、 or a function that can return a function as its output. または他の関数を出力する ことができる関数のことです。 So, basically, we're treating functions kind of as objects themselves. つまり、関数をオブジェクト として扱うわけです。 They can be passed to other functions. 他の関数に渡すこともできます。 You can have layers of functions within functions within functions, etc., 関数内に関数のレイヤーが含まれ、 その関数内にも関数が含まれることも可能です。 and these are what's called higher-order functions, これらがいわゆる高階関数です。 they come up a lot in functional programming. 関数型プログラミングで 頻繁に登場します。 This is a bit of a random example, これはちょっと行き会ったりばったりな例ですが、 but let's say we have this function at the top here, 上の方のこの関数があるとしましょう。 makeAdjectifier makeAdjectifier where we give it an adjective これは adjective を与えると、 and it returns actually a function. 関数を出力します。 It doesn't return a string or a number or anything like that, 文字列や数字を返すのではなく、 it returns us a function その adjective を与えた文字列に足す which adds that adjective to a string that you give it. 関数を返すのです。 So, for example, I can use the makeAdjectifier function 例えば、 makeAdjectifier 関数を使って、 feed it the input “cool” 「cool」と入力すると、 and get a function that's called coolifier. coolifier という名の 関数が返ってきます。 So, now when I pass a string to coolifier, そして、coolifier に 文字列を渡すと、 I get “cool” added to that string. その文字列に 「cool」が足されます。 So, if I pass conference, I get cool conference. ですので、conference を渡すと、 cool conference が返ってきます。 So, the idea here is that we have a higher-order function ここで言いたいことは、 これが関数を返す which returns a function. 高階関数だということです。 And this kind of wrapping your head around this これを理解することは、 at least for me 少なくとも私にとっては、 is one of the key things to being able to write in a functional style 関数的なスタイルで 書くにあたって重要でした。 because as we'll see a bit later, 何故なら、 後ほどお見せするように、 we need these higher-order functions これらの高階関数が in order to avoid some of the tricks 他のパラダイムで使い慣れている that we're used to using from other paradigms. 習慣を避けるのに必要だからです。 So, learning the thing to get into that functional mindset 関数的なマインドセットに 切り替えるために、 for me really involved wrapping my head around this concept. 私には、この概念を 理解する必要がありました。 Okay. はい。 So, one of these things that we're going to avoid さて、 避けるべき習慣の1つは that we're used to doing is iterating, 繰り返しです。 using like “for” or “while”, these sort of things. 「for」や「while」の使用。 We're used to going over lists and doing things to all the items in it. 私達はリスト内のアイテムすべてに 変更を加えることに慣れてしまっています。 Instead, in a functional style, 関数的なスタイルでは、代わりに、 we might use higher-order functions like Map or Reduce or Filter Map、Reduce、Filter などの 高階関数を使うかもしれません。 which often take as an input これらは一般的に not only the list that you want to do something to in some way 変更を加えたいリストだけを 入力として受けるのではなく、 but also a function that then you're going to apply to it. そのリストに適応したい関数も受けます。 In the interest of time I'm not going to go into too much detail 時間の都合上、Map、Reduce、 Filter の機能については about what Map, Reduce, and Filter do, あまり詳しくは説明しませんが、 but I found and also thanks to my colleague Khalid up there, あちらの同僚のカリードのおかげで a really cool graphic that I think expresses Map and Reduce pretty well, Map と Reduce をうまく表現した、 とてもクールな図式を見つけました。 maybe you guys have seen it before, 既に見たことのある方も いるかもしれません。 the MapReduce Sandwich, everyone! 皆様、MapReduce サンドイッチです! So, the idea here is that let's say you have a list, リストがあるとしましょう。 in this case, a bunch of vegetables. この場合は沢山の野菜。 They're whole vegetables. まるごとの野菜です。 We got some bread in there too パンもありますね。 and we want to transform that data in some way. そして、このデータを 何らかの形で変換したい。 So, for example, let's say we want to slice that data 例えば、データを スライスしたいとしましょう。 and we have a function 'slice up' or 'cut up' or 'chop' そして「slice up」または「cut up」 または「chop」という関数があり、 which we can apply to each item in that list. リスト内の全アイテムに 適用できるとします。 Now, usually I would do “for vegetable in sandwich ingredients,” 通常、for 文を使って、 サンドイッチ内の野菜の具材を do all of this, すべて指定し、 do all this chopping, すべてに chop を適用します。 but in a functional style we'd use Map, ですが、関数的なスタイルでは Map を使い、 give it the list of ingredients and give it the function 'chop' 具材のリストと関数の chop を与えると、 and I would get out a new list where everything has been chopped. すべてが chop 済みの リストが返ってきます。 Then we have a Reduce function 今度はリスト内の which basically combines all of the items in a list in a certain way, すべてのアイテムを特定の方法で 組み合わせる、Reduce 関数を使います。 in this case, layering この場合レイヤリングを用いて、 to make a delicious sandwich, 美味しいサンドイッチを 作ります。 and Filter let's say Filter は、 そうですね・・・ could be if you hate cucumbers, キュウリが苦手だったとします。 you could have a Filter function この場合、 which makes sure that Filter 関数を使って、 キュウリ以外の only things that are not cucumbers get through the filter. 具材だけが通過する フィルターを作ることができます。 So, these are the ways we use these higher-order functions このような高階関数の 使い方によって、 to get around the type of “for” or “while” iteration 関数型プログラミングで 癖になってしまった that we're used to doing in functional programming, 「for」や「while」による 繰り返しを避けることができます。 instead we're going to feed functions to higher-order functions 代わりに、 Map、Reduce、Filter などの like Map, Reduce, and Filter 高階関数に関数を与え、 to get the sandwich that we want. 私たちが望むサンドイッチを 手に入れます。 And again, this is not intended to be a totally clear explanation またこれは Map、Reduce、 Filter の明確な説明を of how Map, Reduce, and Filter work, 意図したものではありません。 but there's plenty of information on that online. それについては、ネット上に たくさんの情報があります。 The idea is that we want to use these instead of “for.” 「for」の代わりにこれらを 使用したい、ということです。 So, another thing that we want to do is もう1つ 気を付けなければならないのが we want to avoid mutating data, |avoid mutability. ミューテーションするデータを避け、 ミュータビリティを避けることです。 Mutation in the sense I just mean changing objects in place. ミューテーションというのは、定位の オブジェクトの変更を指します。 So, when we have something that's immutable, ですので、 イミュータブルなものは、 I'm sure a lot of you guys are familiar with the term, きっと多くの方がこの用語を ご存じだと思いますが、 it's something data that can't be changed in place. 変更不可のデータのことです。 Once we've set it it's there forever. 一度設定すると、 いつまでも存在します。 It's never going to change. 決して変わることはありません。 So, let's take a look at an example. それでは、例を見てみましょう。 Just because for me 私はこれを this was another thing that required a little head wrapping. 理解するのに 多少苦労しました。 So, this would be an example of mutation which is non-functional. これは、非関数型の ミューテーションの例です。 We have a rooms variable which stores a list, リストを保管する 変数 rooms があります。 so “H1,” “H2,” and “H3,” "H1"、"H2"、"H3" です。 because that's what we thought the rooms were, これらが rooms であると 思ったからです。 at least that's what I thought the relevant rooms were, 少なくともこれらがrooms に 関連していると思いました。 and then we say no no no actually it's not “H3,” it's “H4”. ですが、これは間違いでした。 "H3"ではなく、"H4"だったのです。 So, let's replace the thing at index [2] in rooms with “H4.” では、rooms のインデックス [2] の要素を"H4"に置き換えましょう。 And so, then we have rooms has actually changed, これで rooms が 実際に変わりました。 we went from [“H1,” “H2,” “H3”] ["H1"、"H2"、"H3"] から to [“H1,” “H2,” “H4”]. ["H1"、"H2"、"H4"] に変わりました。 So, that is still stored in the variable rooms これはまだ変数 rooms に 保管されています。 but we've actually changed something in place ですが、実際には内容を 一部置き換えました。 and this is something that functional programming avoids これは多くの問題を 引き起こす可能性があるため、 because this can cause a lot of problems 関数型プログラミングでは 避けられています。 and this is part of the reason why we get into trouble with this これは私たちがこのような状況で 問題に遭遇する理由の一部です and with these sort of object-oriented approaches, このようなオブジェクト指向の アプローチでは sometimes you can change things in a way that you didn't intend, 意図していない形で何かを 変えてしまうかもしれません。 so that what you thought you were dealing with あなたが扱っていると 思っていた内容が、 if I thought that rooms meant [“H1,” “H2,” “H3”] 例えば、rooms が ["H1"、"H2"、 "H3"] を意味すると思った場合、 and I didn't know that somewhere else in my code 知らない内に コードのどこかで I had replaced something in the rooms array rooms の配列内の要素を 置き換えてしまっていたら、 I could run into trouble. 問題が発生する 可能性があります。 I could end up introducing bugs into my code コードにバグが入り込む 可能性もあります。 and having a really hard time tracking them down こっちの rooms は正しいのに、 because rooms here is the right thing, あっちの rooms は間違っている、 rooms there is the wrong thing, そのため、バグの発見が 難しくなってしまいます。 ah! what happened? Where did this go wrong? ああ!どうして? どこで間違えてしまったのでしょう? Oh! my God! ああ!なんということでしょう! You end up crying in front of your computer. 結局コンピュータの前で 泣いてしまいます。 No, just me. いえ、私だけですね。 So, a better way to go about things ですので、データをイミュータブルなもの、 is to think of all data as immutable, never changing. 決して変わらないものとして 捉えた方がより良いですね。 For example, 例えば、 with no mutation we still have our rooms which has the wrong ミューテーションがなくても、 間違った内容の rooms、 [“H1,” “H2,” “H3”] ["H1"、"H2"、"H3"] があります、 but instead of changing it in place これをその場で 変更する代わりに、 I'm going to make a new rooms array 先ほどお話しした using this map function この map 関数を使って、 that we talked about a little bit earlier 新しい rooms の配列を作成します。 where I'm mapping, この map に関数を与えて、 I'm feeding a function into this map, マッピングして、 which looks at each room in the list リスト内の各 room を見て、 and if it's “H3”, "H3"があった場合、 oops! I have a missing = sign there, おっと!「=」を 忘れていました。 last-minute slides, 土壇場で作成した スライドなんです。 if the room is “H3” it returns “H4” instead of “H3”, 要素が"H3"の場合、"H3" の代わりに"H4"を返します。 otherwise it returns whatever the room was. それ以外の場合は、要素が 何であったかを返します。 Okay. Understanding this specific example is not crucial この特定の例を理解すること は重要ではありません。 but the point is that once I've assigned this new rooms variable, 要は、この新しい rooms 変数に代入を行ったら、 new rooms has the correct values I expect “H1,” “H2,” and “H4”. 新しい rooms には、"H1"、"H2"、 "H4"という正しい値が期待されます。 But rooms is the same as it always was, でも rooms は 以前と同じだということです。 it hasn't changed at all. まったく変わっていません。 So, this is thinking about rooms as being immutable, つまり、ここでは rooms を イミュータブルなものと捉えています。 we're not changing it 変更を加えていません。 and that's something that's really important for functional programming これは関数型プログラミング において、とても重要です。 because as I said, 先ほども言ったように、 it helps you avoid a lot of headaches, a lot of bugs. 多くの頭痛の種、多くのバグを 避けるのに役立ちます。 So, how much time do I have? では、残りどれくらいの時間があるでしょうか。 Okay. Good. ああ。良かった。 We have a little time to talk about persistent data structures, yey! 永続データ構造について話す 時間がありますね、やった! The problem with immutability is that イミュータビリティの問題は、 when you're treating arrays and things like that as immutable, 配列などをイミュータブルに扱うとき、 what you end up doing is making new copies of everything. 結局はすべての新しい コピーを作ってしまいます。 So, if I want to change my one room in this list ですので、1つの要素を変えたい場合、 I have to make a whole new array まったく新しい配列を 作成する必要があります。 and when you're dealing with short little things like this このような短く、小さいものを 扱っているとき、 maybe that's not a big deal, 大した問題では ないかもしれませんが、 but as your objects get bigger, more complex, オブジェクトがより大きく、 より複雑になるにつれて、 this can give you efficiency problems これにより効率の問題が 発生する可能性があります。 because if you have to copy over everything, なぜなら、変わらなかった ものがあったとしても、 even the things that didn't change, すべてをコピーする必要がある場合、 every time you make one little adjustment 少し調整して、 配列を少し変えた and you want to make a new copy, 新しいコピーを a slightly different copy of your array, 作成するたびに、 it takes you a lot of time, 多くの時間が かかってしまうからです。 you have to go through everything in the list to copy it over, コピーするために、 リスト内のすべてをたどり、 you end up using a lot of space 多くのスペースを使用することに なってしまいます。 that maybe once the objects start getting bigger and bigger これはオブジェクトが 大きくなるにつれて becomes a problem. 問題になってきます。 And so, one thing that's very popular in the functional world そこで、関数型の世界で 人気なのが as a way of getting around these efficiency issues これらの効率の問題を 回避する手段として、 is to use persistent data structures. 永続データ構造を 使うことです。 This was something introduced sort of theoretically by Phil Bagwell, これはフィル・バグウェルによって、 理論的に紹介されたものです。 he wrote a paper called Ideal Hash Trees. 彼は Ideal Hash Trees という論文を書きました。 I can put a link in the slide to that later 後でスライドに リンクを貼っておきます。 and then Rich Hickey who invented the language Clojure そして、Clojureという 言語を発明したリッチ・ヒッキーが implemented the data structures using Bagwell's ideas バグウェルのアイデアを使用して データ構造を導入し、 to make Clojure really efficient for these immutable data structures Clojureをイミュータブルなデータ構造、 そして関数型の操作に対して and for these functional operations. 効率的なものにしたのです。 Okay. OK。 So, the way persistent data structures work if I may, 永続データ構造がどのように 機能するのかというと、 if you will indulge me, お許しを頂けるなら、 I'm going to step back to the chalkboard right here. こちらの黒板を使います。 We're getting retro. Yeah, it's happening. レトロで行きましょう。 Okay. OK。 So, if we have like an array where we had H1, H2, H3, H1、H2、H3 が含まれた配列がある場合、 typically what I do in a mutable world is just get rid of this 通常、ミュータブルな世界なら これを取り除き、 and replace it with H4, H4で置き換えます。 but as we said we want to avoid that. ですが、先ほども述べたように、 こうすることは避けたいです。 So, instead, if I copy it over into a new array, 代わりに、これを 新しい配列にコピーすると、 I copy H1, H1をコピーして、 I copy H2 H2をコピーして、 and I replace, instead of copying H3 I put in H4. H3をコピーする代わりに、 H4を入れます。 Great! いいですよね! But now I have to store two arrays, ですが今度は配列を2つ 保存しなければならず taking up a lot of time, 時間がかかってしまいます。 look how long that took me to do all of that. これを行うのに、どれだけの時間が かかったか、ご覧になったでしょう。 Terrible. Right? 結構かかりましたよね? I know you guys feel as upset about this as I do. 皆様も私と同様、 ご立腹のことでしょう。 I can see it in your faces. 顔に出ています。 What if instead we represented this array right here as a tree, 代わりに、この配列を 木構造として表したら、 such that each leaf node of the tree ツリー構造の それぞれの葉ノードが is one of the things that I'm trying to store 保管しようとしている ものの1つとなります。 or perhaps 2 of the things or 3 or 32 or some number of the things または2つ、3つ、32、 とにかく、何かしらの数になります。 and if I want to change something, そして、何かを変えたいとしても、 I don't need to replace the entire array, 配列全体を 取り換える必要はありません。 I can just make a new node over here, like H4, このように、ここに新しいノードの H4を作成できます。 and now I can make a new tree また、新しい木構造を作ることができます。 which instead of repeating H1 and H2 H1 と H2 を繰り返す代わりに I can reuse those same things and just make a new node 同じものを再利用して新しい ノードを作ることができます。 which connects them to my new element over here, それらをこちらの新しい要素につなげます。 so that now I have here a data structure which contains H1, H2 and H4 すると、H1、H2、H4 を含む データ構造ができました。 but I didn't need to make a whole new thing. ですが、まったく新しいものを作る 必要はありませんでした。 I just needed to make my one little part. ただ小さな一部を作っただけです。 I can reuse the old structure of the list. リストの古い構造を再利用できます。 So, this idea, this sort of topic is called structural sharing この考え、このようなトピックは 構造共有と呼ばれます。 because we can share parts of the old versions with the new versions, 古いバージョンの一部を新しい バージョンと共有できるため、 so we have much more efficient operations for adding, より効率的な 追加操作を行えます。 changing things or moving things from vectors, for example, or arrays 例えば vector または配列内の要素の 変更、または移動も可能で、 and this can also be done for maps, for hash maps that sort of thing これらは、Map や HashMap などでも行えます。 and it basically makes the world of functional programming bust wide open 関数型プログラミングの 世界を大きく広げてくれます。 so that we don't have to go through these long time イミュータブルなデータを 更新するとき、 and expensive space operations いつも時間がかかったり、 to update our immutable data all the time. 容量を食う、高コストな操作を 避けることができます。 So, to do this in JavaScript, JavaScript で これを行うにあたって、 there are a couple of libraries that are really popular. 人気なライブラリがいくつかあります。 One which I like to use is called Mori 私のお気に入りは Mori です。 which I'll show you the link for in a little bit 後ほどリンクをお見せします。 which actually uses ClojureScript Mori は ClojureScript という、 which has these type of data structures natively, こういったデータ構造がネイティブに 組み込まれている言語を使います。 it ports them over to JavaScript, それらを JavaScript に移植するので、 so you can use them right from JavaScript JavaScript から 直接使用できます。 and it's great. 素晴らしい ライブラリです。 It has a lot of also like general functional programming helpers また、Map や Reduce など、 一般的な関数型プログラミングの like Map and Reduce and lots of other things. ヘルパーが 他にもたくさんあります。 There's also another popular library called Immutable.js Immutable.js という人気な ライブラリもあります。 which Facebook put out これは Facebook が 出したもので、 which is JavaScript through and through. 徹頭徹尾 JavaScript です。 I haven't worked as much with that 私はそこまで 使用していないのですが、 but I know a lot of people like that as well. 気に入っている人を たくさん知っています。 And yeah, so these are ways もし今すぐにでも you can try out using these immutable data structures 試してみたいとお考えなら、 if that is something you feel like you can't wait to do now. イミュータブルなデータ構造は このように使用してみることができます。 I know. 分かっています。 I can just feel the excitement. Yeah, that's great. ワクワク感が伝わってきます。 ええ、素晴らしいことです。 Okay. Moving on. はい。では次へ。 If you're ready to try it out, 試す準備ができたら、 like I said, we have Mori and Immutable.js, 先ほども述べたように、Mori と Immutable.js があり、 links there to those libraries. こちらがそれらのライブラリのリンクです。 There's also a lot of utility libraries ユーティリティライブラリも 多数あります。 which don't focus so much on this persistent data structure thing, これらは永続データ構造には それほど焦点を当てていませんが、 but instead give you a lot of helper functions like Map, Reduce, etc. 代わりに、Map、Reduce などの 多くのヘルパー関数を提供しています。 So, Underscore, Lodash, for example. たとえば、Underscore、Lodash などです。 Today I found out that Ramda is a thing 今日私は Ramda について知りました。 because there was a talk on it the other day 先ほどそれについての 講義があったので。 and there are many more. 他にも、もっとたくさんあります。 And in fact, JavaScript has some built-in functions, 実際、JavaScript にはいくつかの 組み込み関数があります。 like for example, arrays have a built in Map, Reduce functions. たとえば、配列には Map、Reduce 関数が 組み込まれています。 So, a few slides ago we saw this rooms.map, 少し前のスライドに この rooms.map がありましたね。 that's because the array prototype has these functions Map, Reduce, etc. 何故かというと、配列プロトタイプに Map、 Reduce などの関数があるためです。 So, you can even do some functional programming in pure vanilla JavaScript 従って、これらのライブラリを一切 使用せず、純粋なバニラ JavaScript で without using any of these libraries. 関数型プログラミングを 行うこともできます。 Okay. はい。 So, if you are sitting there thinking, ですから、そこに座って What? Huh? I didn't really get that something about immutability, 「え?何?イミュータビリティとは?」 side effects, pure functions. What now, huh? 「副作用、純粋関数。よくわからない」 とお考えで、 If you want to learn a bit more about all these buzzwords, ここ20分間、私が解説してきた これらすべての like I said, all these sexy buzzwords セクシーな用語について that I've been throwing at you for the last 20 minutes, もう少し詳しく知りたい場合は、 I highly recommend a nice gentle introductory article called 優しく素敵なこちらの 導入記事を強くお勧めします。 “An introduction to functional programming” 私が度々述べている The Recurse Center の by Mary Rose Cook 元まとめ役でもある、 who is a former facilitator at The Recurse Center マリー・ローズ・クックによる that I keep talking about. 「関数型プログラミング入門」です。 The link is up there, リンクは上の方にあります。 but basically this is a really nice introduction これは本当に素晴らしい入門書で、 that kind of goes into a little bit more depth 今日私がお話しした in some of the “commandments” of functional programming 関数型プログラミングの「おきて」について that I've mentioned today. より深く知ることができます。 So, if you are a little intrigued ですので、私が話してきた 内容に興味はあるけれど、 but not quite clear on this stuff that I've been mentioning, 今ひとつ 理解できないという方は、 I highly recommend you check it out. ぜひチェックしてみてください。 So, I think that's it for my talk. では、私の話は以上です。 We have a couple of minutes for questions, I suppose, 質問のための時間をとってあります。 eight minutes by my account, 8分間ですね。 but first of all I just wanted to say thank you guys very much. でも、まず最初に、 皆様にお礼を言わせてください。 I'm Anjana Vakil. 私はアンジャナ・ヴァキルです。 Anjana Vakil on Twitter Twitter名も アンジャナ・ヴァキルです。 and has link there to my GitHub. Twitterには私の GitHub への リンクもあります。 So, would love to keep in touch 連絡を取り合いましょう。 if anybody else is out there also learning 私のように初心者として関数型 JavaScript を functional JavaScript as a newbie like myself, 学んでいる方がいらっしゃれば、 definitely reach out, 連絡してください。 we could stick together, 一緒に頑張りましょう。 but first of all I want to give a huge thanks でも、まず初めに JSUnconf 主催者の方々と、 to again the JSUnconf organizers, 特にダイバーシティ スポンサーの方々に especially the diversity sponsors. 重ねてお礼申し上げます。 I'm here on a diversity ticket myself かく言う私もダイバーシティの 資格で参加しています。 and wouldn't have been able to come without that awesome program この素晴らしいプログラムなしに ここに来ることはできませんでした。 and all of you and the sponsors who sponsored those tickets そしてチケットをスポンサーしてくださった 皆様やスポンサーの方々のおかげでもあります。 and also a huge huge thank you to The Recurse Center また、The Recurse Center にも、 後ろの方にいるカリードをはじめとする and some of the alumni there who have helped me learn all this stuff 同窓生にも 大変感謝しています。 including Khalid at the back there サル・ベッカーにも感謝です。 and Sal Becker, another alum, サルも同窓生で、 who explained a lot of this stuff to me The Recurse Center で、 カフェインを燃料に over several long caffeine-fueled conversations at The Recurse Center 長い会話の中で 私に多くを教えてくれました。 and if any of you are interested in spending time そして、ニューヨーク市での 自主教育プログラミング合宿に on self-directed educational programming retreat in New York City もしご興味があれば、 definitely check out recurse.com, recurse.com をぜひチェックしてみてください。 it's an amazing community. 素晴らしいコミュニティです。 Okay, that's it for me. Thanks. では以上です。 ありがとうございました。 [Applause] [拍手] Thank you very much. ありがとうございました。 Yes, _____ はい、_____ Does anybody have any questions about functional programming? 関数型プログラミングについて 質問がある方はいますか? Don't know if I'll be able to answer them but I can try. 質問に答えられるかどうか分かりませんが、 努力します。 Yeah. はい。 Actually, always the professors at my faculty 私の学部の教授達は常に always said that object-oriented programming オブジェクト指向プログラミングの方が is better than functional programming 関数型プログラミングより優れていると and I was thinking that is it better 言っていますが、 本当にそうなのでしょうか? or is it you think that we should use それとも関数型プログラミングは functional programming only on JavaScript JavaScript のみで使うべきだと思いますか? or also on other programming languages like C _____ それとも C のようなその他の プログラミング言語でも使うべきですか? So, I think that's a great question とても良い質問ですね。 and it kind of gets into a little bit of the, それは、私が考える プログラミングパラダイムの what I think of as kind of the philosophy of programming paradigms. 哲学に少し関わってくることです。 So, as I was learning about functional programming 私が関数型プログラミングについて 学んでいたとき、 I started even wondering what is a programming paradigm プログラミングパラダイムが何なのか、 そして and why do people fight about them, なぜ人々はそれについて論争するのか、 why do people say object orientation sucks, なぜ人々はオブジェクト指向は最低で、 we have to do everything functional すべてを関数で行うべきだと言うのか、 and why do people say no, functional programming sucks, そしてなぜ人々は、それは違う、 関数型プログラミングは最低だ、 we need object orientation. 必要なのはオブジェクト指向だと言うのか And the conclusion that I came to is that 疑問に思い始め、 私が達した結論は、 no one paradigm is better or worse than other paradigms. 他より優れた、または他より劣る パラダイムはないということです。 They just have different advantages and disadvantages パラダイムはどれもそれぞれ 異なる長所や短所があり、 and they have different situations 異なる状況における in which they're going to be kind of the best tool 特定の問題に対して最適なツールと for that particular problem. なることができるのです。 So, for example, if you just want to really quickly write up a script 例えば、コンピューターで 何かをサクッと that just does something on your computer once really fast, 一度だけ実行するスクリプトを 簡単に書きたい場合、 you're probably just going to do it in an imperative style, おそらく、これをして、あれをして、 do this, then do that, then do the other thing. 次に別のことをするという 命令型を使用すると思います。 If you don't need to maintain it, をれを維持する必要がなく、 if you just need it to happen right there, そのときすぐに実行させたい場合、 imperative programming is a totally legit paradigm for that. 命令型プログラミングは 全く正当なパラダイムです。 If you're trying to model real world objects 実世界のオブジェクトを モデリングしようとする場合、 and how they interact それらがどのように 相互作用するか、 and how they go around and things you can do, どのようにめぐり渡るのか、 そして私達ができることをモデリングしようとする場合、 like if you're trying to model, I don't know, 例えば、図書館の本や、 教師と生徒を含むクラスを books in a library モデリングする場合です。 or classes with teachers and students それらがすべてどのように 相互に関係しているのか、 and how they all interrelate that sort of thing, というようなことです。 そのような場合は、 maybe thinking about it in an object-oriented way makes most sense オブジェクト指向の方法を用いて考えるのが 最も理にかなっているのではないでしょうか。 because that's exactly the problem you're trying to solve, 正に私達が解決しようとしている問題が is modeling objects オブジェクトの モデリングだからです。 and that's why that paradigm came about. パラダイムが生じた理由が それだからです。 But if you're trying to avoid some of those problems しかし、もし実世界のオブジェクトとは 関係しない状況において、 that I was talking about オブジェクトを when you have maybe a situation 使わなければならないという that doesn't actually refer to real-world objects, 理由だけで それを使用していて、それが where you're using objects just because you have to ありとあらゆる副作用や 追跡困難な and that's introducing all kinds of side effects and weird bugs 変なバグを発生させていて、 今言ったような問題のいくつかを that are hard to track down, 回避しようとしているならば、 maybe you want to consider thinking about it データに対して 関数を使用して考え、 in terms of functions on your data 色々なものを 複数の関数を通して、 and things being pipelined through multiple functions そして色々と変化させて、 パイプラン化することを and undergoing various transformations, 考慮すると良いかもしれません。 not in the sense that the data is being mutated データをミューテートさせる という意味ではなく、 but in the sense that we're getting new outputs 古い入力に基づく 新しい出力を得る based on old inputs, という意味です。 then functional programming is probably the way to go そうすれば関数型プログラミングは おそらく有効な方法であり、 and it has a lot of advantages such as being nicely, 色々なものを 1つのことだけを行う小さな関数に you can break things down into small functions that only do one thing. 分解することができなど、 多くの利点があると思います。 So, if you want to change something ですから、何かを変えたいとき、 you don't have to change an entire class structure, クラス構成全体を 変える必要はなく、 you can just change the one little function 変更したいことを実行する that does the thing you want to change. 小さな関数を1つだけ 変えれば良いだけなのです。 So, I think it has advantages, it has disadvantages. ですから関数型には 長所と短所、両方があると思います。 I definitely wouldn't say it's better than object orientation in all cases すべてのケースでそれが オブジェクト指向より優れているということはなく、 and I definitely wouldn't say object orientation is better in all cases either, オブジェクト指向がすべてのケースで より優れているということもありません。 it really depends on your situation. その時その時の 状況によるものなのです。 Also, very good introduction of programming philosophy. プログラミング哲学への 大変良い序論でもあります。 I used to be a philosophy major, so that might be why. 私の専攻は哲学だったので、 そう感じるのかもしれません。 Any other questions? 他に質問はありますか? You mentioned Map function アンジャナさんは 「Map」関数に言及し、 and the Map function is not working, 「Map」関数が 機能しないと仰っていましたが、 so do you mix it... それを組み合わせるのですか? Before that, I come from object-oriented programming style 私はオブジェクト指向 プログラミングスタイルを 使用していて、 and not so much into functional. 関数型については あまり知りません。 That's cool too. それもいいじゃないですか。 The professors really just test our functions 教授たちは学生の関数だけをテストし、 and can avoid the concurrency Map 関数導入の可能性のある that the Map function could possibly introduce. 並行性を回避することができるのです。 Non-blocking and concurrency and promises 非ブロック性と並行性と約束について are all things that I do not feel qualified to talk about right here. ここで話す資格は、私にはないと思います。 I would love to turn that question over to the audience though. この質問は聴衆の皆様に 投げたいと思います。 Anybody want to respond? 答えてくださる方はいますか? _____ _____ Fight fight fight. ファイト、ファイト、ファイト。 Just kidding. それは冗談。 Just kidding, just kidding. 冗談、冗談です。 That would be against the code of conduct, you guys. 行動規範違反になってしまいますよね。 _____ _____ I would also guess that perhaps it's blocking 私はおそらくそれは ブロック性だと思いますが、 but we can discuss this later in a small room or outside. これについては、後で小さな部屋、 または外で話し合いましょう。 [Laughter] [笑い] Thank you for the conversation starter question though. でも、会話の切り出しとなる 質問をありがとうございました。 Excellent question とても良い質問ですね。 and I would love to know the answer. 私もその答えを知りたいです。 Look forward to talking you guys more. もっとお話しできることを 楽しみにしています。 I guess... それでは・・・ I guess we are done with the talks, the big talks now. これで講演は終わりです。 Thank you. ありがとうございました。 Thank you. - Again. ありがとうございます。 [Applause] [拍手]
A2 初級 日本語 米 関数 プログラミング オブジェクト 配列 出力 データ Learning Functional Programming with JavaScript - Anjana Vakil - JSUnconf 54 2 LONGSIAN LIANG に公開 2021 年 06 月 02 日 シェア シェア 保存 報告 動画の中の単語