最近聞いたポッドキャスト、 Compiled Conversation #8, #9 がドメイン駆動設計の入門としてすごくよかったので、英語で文字起こしして、和訳をしました。参加者のお二人に和訳をブログに載せる許可をいただきました。LLMによる機械翻訳ベースなので、細かな表現が意訳されていたり、また文字起こしの間違いにより一部おかしな内容になっているかもしれません。ぜひ英語でわかる方は本編を英語で聞かれることをお勧めしますが、日本語の和訳だけでもニュアンスが十分伝わるので、よろしければご覧ください。
Domain Modeling Made Functional Part 2 with Scott Wlaschin
(1)-1はこちら
(1)-2 はこちら
(1)-3 はこちら
(2)-1 はこちら
(2)-3 はこちら
podcastのリンクはこちらです。
登場人物
- Ed Mann（ホスト）: ポッドキャストの司会者
- Scott Wlaschin（ゲスト）: 『関数型ドメインモデリング』著者、F# for Fun and Profit ブログ執筆者
エラーハンドリング - Railway Oriented Programming
Ed Mann
英語はこちら
How do I solve like dependency injection or dealing with errors and asynchronous constructs?
依存性注入やエラー処理、非同期構造をどのように扱いますか？
Scott Wlaschin
英語はこちら
Right things. Exactly. So this is the kind of thing where you'd probably do it in a very different way. So let's start off with the error handling, which are infamously called railway oriented programming a long time ago and people still hate me for that, but.
その通りです。これは非常に異なる方法で行うものです。エラー処理から始めましょう。これは以前「Railway Oriented Programming」と名付けて、人々はまだそのために私を嫌っていますが。
Ed Mann
英語はこちら
Why do they hate?
なぜ嫌われるのですか？
Scott Wlaschin
英語はこちら
It I because they don't like, don't like. I came up with a new word for something that's already got a.
すでに名前があるものに新しい言葉を作ったからです。
Ed Mann
英語はこちら
Word. Oh, I really liked it. I know I love. I love the visual as well. I use it a lot.
ああ、私は本当に好きです。ビジュアルも大好きです。よく使います。
Scott Wlaschin
英語はこちら
People, I think I personally, I mean, I, you know, I think it can go overboard, overboard. But I mean, I do think, I think it was quite a good metaphor for how you do error handling. And it seems to have a lot of people seem to find it very useful as a way. So I mean, so the model there is rather than, you know, in the classic C you would return an error as a H function would return an error and you'd say, you know, get the error and get more details about the error, whatever. And then in when you then you started introducing exceptions like in Java and C and then you just the function does not return anything.
個人的には、やりすぎることもあると思いますが、エラー処理の方法についての良い比喩だったと思います。多くの人々がそれを非常に有用だと感じているようです。モデルは、クラシックなCではエラーを返し、エラーの詳細を取得します。JavaやC#で例外を導入し始めると、関数は何も返しません。
Scott Wlaschin
英語はこちら
Thing you have to catch the exception if something.
何かあった場合に例外をキャッチする必要があります。
Ed Mann
英語はこちら
Went well and you don't know.
うまくいったとしても、わかりません。
Scott Wlaschin
英語はこちら
That there is an and you don't know unless you're using checked exceptions in Java, you have no idea that there's actually an exception that you have to catch. You have to look at the documentation to see. So the functional programming uses the great one of the nice things about algebraic data types, which is you have a choice type, which is something or something that most languages have a record type, which is, you know, a name and an address and an e-mail. So that's a record, but something or something or something is.
Javaのチェック例外を使っていない限り、実際にキャッチしなければならない例外があることはわかりません。ドキュメントを見なければなりません。関数型プログラミングは代数的データ型の素晴らしい点を使います。選択型があり、何かまたは何かです。ほとんどの言語にはレコード型があり、名前、住所、メールアドレスなどです。しかし、何かまたは何かまたは何かは、
Scott Wlaschin
英語はこちら
Common in Oh, Oh, and you typically the nearest thing you have is like an enum or something like that where you can say, you know, red or green or blue, but they're not really a proper data type. There's not extra data associated with. It's just a bunch of especially basically a bunch of constants that are considered this one type. But but in in functional programming, the algebraic type system allows you to something, something or something. And so for error handling, you can say is a success or a failure and you can have two different cases and you can have.
OOで一般的な最も近いものは列挙型のようなもので、赤、緑、青と言えますが、実際には適切なデータ型ではありません。追加のデータが関連付けられていません。基本的には1つの型と見なされる定数の束です。しかし関数型プログラミングでは、代数的型システムにより、何かまたは何かを許可します。エラー処理では、成功または失敗と言うことができ、2つの異なるケースを持つことができます。
Scott Wlaschin
英語はこちら
Different data associated with each case. So the success you return just you return the success and the data that was successful. And in the error case, you return the fact that was an error plus the error data that was happening. And so each function you can actually look at the type signature of the function and say, oh, I can see that this function rather than just returning a string, it returns a string or an error. And I can just look at it straight away until this might not work. So it's I don't have to look at the documentation to see if it throws exceptions. So it's it is like the C version, but with much, much more detail, I mean.
各ケースに異なるデータを関連付けます。成功の場合は成功とそのデータを返します。エラーの場合はエラーとエラーデータを返します。各関数の型シグネチャを見て、この関数が単に文字列を返すのではなく、文字列またはエラーを返すことがわかります。すぐにこれが動作しない可能性があることがわかります。例外をスローするかドキュメントを見る必要がありません。Cバージョンに似ていますが、はるかに詳細です。
Scott Wlaschin
英語はこちら
Another analogy Golang uses also have a pair of things as a return value. But again, they just say everything's a pair and you always have to check did one of the pairs work. So this is the problem with the returning errors as values is like how do I chain these things together? It's like I want to do the successful thing, but if there's an error, I want to stop. So I make it looking ugly without making it ugly. So in Go you say if it's if it's not an error, do the next thing if it's not an error, do the next thing if it's not an error, do the. So the code looks kind of ugly to me. But in in functional programming because you can pass.
Golangも戻り値としてペアを使います。しかし、すべてがペアで、常にペアの1つが機能したかチェックする必要があります。値としてエラーを返すことの問題は、これらをどのようにチェーンするかです。成功したことをやりたいが、エラーがあったら停止したい。コードを醜くせずにどうやってそれを行うか。Goでは、エラーでなければ次のことを行い、エラーでなければ次のことを行います。コードが少し醜く見えます。しかし関数型プログラミングでは、
Scott Wlaschin
英語はこちら
A function as a parameter. You can have a special helper adapter where you pass one of these functions in and it converts it into a consistent, what I call A2 track model where there's an error track and there's a success track. And if you're on the, if something happens, you kind of switch onto the error track, which is the well weight oriented programming idea. But then you can connect all these things together in a very elegant way where you don't actually see the error handling happening. So it looks like you've got the nice success path happening, but the error part is still there and it is being handled behind.
関数をパラメータとして渡すことができます。特別なヘルパーアダプターがあり、これらの関数の1つを渡すと、一貫した、私が「2トラックモデル」と呼ぶものに変換します。エラートラックと成功トラックがあります。何かが起こったら、エラートラックに切り替わります。これがRailway Oriented Programmingのアイデアです。しかし、これらすべてをエレガントな方法で接続でき、実際にエラー処理が起こっているのを見ることはありません。素敵な成功パスが起こっているように見えますが、エラー部分はまだそこにあり、裏で処理されています。
Scott Wlaschin
英語はこちら
The scenes, so you get the benefits of looking like you're not dealing with it, but behind the scenes you're actually dealing with it fully without you can never forget to catch the error because it's not an exception that it's an error as a value being passed on. So that's something there's a very functional programming approach to something which is typically as far as I know only used in functional programming. Now people are using this there are railway oriented libraries for Ruby and for Python And for C# and stuff like that. I'm not sure I agree with that because.
舞台裏では、処理していないように見えるメリットを得ますが、舞台裏では完全に処理しています。エラーをキャッチすることを忘れることはありません。例外ではなく、値として渡されるエラーだからです。これは関数型プログラミング特有のアプローチです。今では、RubyやPython、C#などにRailway Orientedライブラリがありますが、私はそれに同意するかわかりません。
Scott Wlaschin
英語はこちら
There's just not the natural way of doing things.
それは自然なやり方ではないからです。
Scott Wlaschin
英語はこちら
In Ruby and Python, I think she sticks to how you're supposed to do it in I just, you know, some funny enough, I'm against it in outside of functional programming because in a functional programming language, I would expect that people know how to deal with this stuff. This is a very common technique in functional programming, but it's not a common technique in, in, in Ruby or or Python or, you know, C# even. So, you know, I'm, I'm, I'm two minds about that. I mean, I think it's a good technique, but I think sometimes again, people get hyped up over something and I personally wouldn't use it if I was doing.
RubyやPythonでは、それぞれの言語での適切な方法に従うべきだと思います。面白いことに、関数型プログラミング以外では反対です。関数型プログラミング言語では、人々がこのようなものを扱う方法を知っていることを期待します。これは関数型プログラミングで非常に一般的なテクニックですが、RubyやPython、C#では一般的ではありません。二つの意見があります。良いテクニックだと思いますが、時々人々は何かに熱狂しすぎます。個人的には使わないでしょう。
依存性注入と純粋関数
Scott Wlaschin
英語はこちら
Anyway, and then what else do you talk about says things such as like, because I think like this all boils down to something like dependency check, right? Yeah, dependency injection. So there's. OK, so there's a good example. So in dependency injection you would typically in oh, you'd pass in some sort of interface in the class constructor. Now, if you in functional programming, you don't have classes, so you don't have a class constructor. But what you can do is pass it in as a function parameter to a function. So if you have a function that's doing something and it needs to write to the data, write to the database as part of that, you.
他に話すことは、依存性チェック、依存性注入についてです。OOでは通常、クラスコンストラクタに何らかのインターフェースを渡します。関数型プログラミングではクラスがないので、クラスコンストラクタがありません。しかし、関数パラメータとして関数に渡すことができます。何かをする関数があり、その一部としてデータベースに書き込む必要がある場合、
Scott Wlaschin
英語はこちら
***** that in as another function parameter that does the IO or does the whatever the dependency thing is. But as I said at the beginning, one of the things I've quite opinionated about now is to avoid doing any kind of nondeterministic code. Anything with databases or timestamps or random numbers, Anything which is not predictable is to keep that at the edges, so you keep your pure codes.
IOや依存関係を処理する別の関数パラメータとしてそれを渡します。しかし、最初に言ったように、今私が強く意見を持っているのは、非決定的なコードを避けることです。データベース、タイムスタンプ、乱数など、予測できないものはエッジに保ち、純粋なコードを保ちます。
Scott Wlaschin
英語はこちら
100% predictable and 100% deterministic. And what you do is you separate the decision making part of the code.
100%予測可能で100%決定的です。そして、コードの意思決定部分を分離します。
Scott Wlaschin
英語はこちら
From the database or the IO part of the code. So rather than mixing in like in a lot of OO things, you might say update the customer e-mail and then save the customer. And if something else then also, you know, send the e-mail or whatever. What I would do is keep that as two separate steps. One is to update their e-mail and the customer. And that is a deterministic, it's always true. And there's a second step at the very end of the workflow is all the things I need to do at the end of the workflow. OK, at the end of this workflow, I've determined that I need to save the customer. I need to send an e-mail I.
データベースやIOのコードの部分から分離します。多くのOOでは、顧客のメールを更新してから顧客を保存し、何か他のことがあればメールを送信します。私がすることは、それを2つの別々のステップとして保つことです。1つは顧客とそのメールを更新することです。それは決定的で、常に真です。ワークフローの最後に2番目のステップがあります。ワークフローの最後に行う必要があるすべてのことです。このワークフローの最後に、顧客を保存し、メールを送信する必要があると決定しました。
Scott Wlaschin
英語はこちら
Need to update the invoice. I need to do this, this, this. I keep a list of all those things and at the end of the workflow, I do all those things as a separate step. And then I don't need to have dependency injection because I just directly call those IO type functions as the last step in my workflow. But if I like I say the dependency injection equivalent would be what I call what you might call parameter injection. And the other thing in functional programming is you tend not to use things like mocks and stuff. You just, you just call things and you know, again, this mocking you don't have.
請求書を更新する必要があります。これ、これ、これをする必要があります。それらすべてのリストを保持し、ワークフローの最後にそれらすべてを別のステップとして実行します。そして、依存性注入は必要ありません。ワークフローの最後のステップとしてそれらのIOタイプの関数を直接呼び出すからです。しかし、依存性注入の同等物は、私がパラメータ注入と呼ぶものです。関数型プログラミングのもう1つのことは、モックなどを使用しない傾向があることです。
Scott Wlaschin
英語はこちら
Basis. So you can't really mock things in the same way. You just all everything in your domain just called correctly, so it tends to be just a lot less. And you don't need to mock because you're passing a function in as a parameter. You don't need to mock an interface, you just pass in a different function. You pass in a test function rather than the.
同じ方法でモックすることはできません。ドメイン内のすべてが正しく呼び出されるため、はるかに少なくなります。モックする必要はありません。関数をパラメータとして渡しているからです。インターフェースをモックする必要はなく、別の関数を渡すだけです。実際の関数ではなくテスト関数を渡します。
Ed Mann
英語はこちら
Actual function stub, one that just returns true or whatever, yeah.
実際の関数スタブ、単にtrueを返すものなど、はい。
Scott Wlaschin
英語はこちら
You don't need. You don't. There's no Mocking is an O kind of thing. It's not really a functional.
必要ありません。モッキングはOOのものです。関数型のものではありません。
暗黙的な例外について
Ed Mann
英語はこちら
Thing and I think something we're on the error side again. I wonder what your opinion like, what is your opinion on like these implicit exceptions?
エラーの側面について、暗黙的な例外についてのあなたの意見は何ですか？
Ed Mann
英語はこちら
Because again, this whole if we were to handle exceptions like go like this is one thing. We go, it's like, hey, you have to handle these. Is it? If there's an error, I do this. Whereas in other languages to make things clean, we just throw an exception all the way down the stat and then it bubbles all the way up. No one handles it maybe till the end or.
Goのように例外を処理する場合、これらを処理しなければなりません。エラーがあれば、これをします。他の言語では、物事をきれいにするために、例外をスタック全体に投げて、それが上まで泡立ちます。最後まで誰も処理しないかもしれません。
Scott Wlaschin
英語はこちら
So I'm just wondering like, yeah, what is your opinion on, right. So there's a, there's, I think exception. There's. Well, first of all, there's different kinds of errors. So there's not one size resource. So the first kind is what you might call a panic where you've got a null reference or you've got a divide by.
あなたの意見を聞きたいです。例外について、まず第一に、異なる種類のエラーがあります。1つのサイズがすべてに適合するわけではありません。最初の種類は、パニックと呼ばれるもので、nullリファレンスや除算、
Scott Wlaschin
英語はこちら
Zero or you've got out of memory or something, it's basically a bug or something out of your control and there's nothing you can do about it. And the answer then is to basically crash. Or in that case, exceptions are very useful because I don't care. There's nothing I can do about it. I can't really recover. So typically in that case, I would recommend throwing an exception and handling it at the top level of your app. And maybe you don't crash, but you restart or whatever you do. And then there's what I call domain exceptions, which are something that you need to plan for because it's, you know, if you've got a word.
ゼロ除算やメモリ不足など、基本的にバグまたは制御できないもので、何もできません。その場合の答えは基本的にクラッシュすることです。その場合、例外は非常に有用です。何もできません。回復できません。通常その場合、例外をスローしてアプリのトップレベルで処理することをお勧めします。クラッシュしないかもしれませんが、再起動します。そして、ドメイン例外と呼ぶものがあります。これは計画する必要があるものです。
Scott Wlaschin
英語はこちら
Processor and you try to open a file, the file's not there. You should expect that to happen. You know, you shouldn't just crash because the file's not there. So in that case, that's something you would expect to happen. So in normal, you might have something as simple as a boolean like does the file exist? So rather than just returning a boolean, and we're used to saying if the father doesn't exist, I wouldn't throw an exception, I'd say true or false. And then if true, do this if false, do that. You do the control flow is expected and you would handle it in your codes. So what the result kind of thing is basically a more fancy.
ワードプロセッサでファイルを開こうとしてファイルがない場合。それが起こることを期待すべきです。ファイルがないからといってクラッシュすべきではありません。その場合、それは期待されることです。通常、ファイルが存在するかのような単純なブール値があるかもしれません。ブール値を返すだけでなく、ファイルが存在しない場合、例外をスローせず、trueまたはfalseを言います。trueならこれを、falseならそれを行います。制御フローは期待され、コードで処理します。結果の種類は基本的により洗練されたものです。
Scott Wlaschin
英語はこちら
Of doing billions rather than just saying true or false, it's like success with this data or error with this data so just like you wouldn't throw an exception every time you have a boolean, right you just return you'd return the boolean. So it's just a more fancy version of doing that. And so in that case I would definitely you know not throw exceptions because that's something you expect to have expect to have happen as part of the design. And so I want to have that documented and not just some random thing that I.
単にtrueまたはfalseと言うのではなく、このデータで成功またはこのデータでエラーのようなものです。ブール値があるたびに例外をスローしないのと同じように、ブール値を返します。それをより洗練されたバージョンです。その場合、例外をスローしません。それは設計の一部として起こることを期待しているからです。それを文書化したいのです。
Ed Mann
英語はこちら
Have yeah, no, it makes sense. I think it also makes an infrastructure as.
はい、理にかなっています。インフラストラクチャとしても、
Scott Wlaschin
英語はこちら
Right. So the third, the third kind of error type is crossed between those two things. So it might not be something you expect to happen in the domain, but it's also.
そうです。3番目のエラータイプは、これら2つの間です。ドメインで起こることを期待していないかもしれませんが、
Scott Wlaschin
英語はこちら
You know, not, not some weird thing that you can't handle. There's typically the infrastructure you try and read a file, the file system is wrong or the database, you know, you've got an authentication error, you've got a timeout error on the network. And what should you do? And the answer is it depends. And sometimes there's nothing you can do. But sometimes if you get a network error or timeout error, for example, you can retry a couple of times. So but you don't want to retry forever and you maybe you've got an authentication error to the database. Maybe that's something you might expect because.
処理できない奇妙なものでもありません。通常、インフラストラクチャで、ファイルを読もうとしてファイルシステムが間違っている、データベースで認証エラーがある、ネットワークでタイムアウトエラーがあります。何をすべきか？答えは状況によります。時々何もできません。しかし時々、ネットワークエラーやタイムアウトエラーの場合、数回再試行できます。永遠に再試行したくありませんし、データベースへの認証エラーがあるかもしれません。それは期待されることかもしれません。
Scott Wlaschin
英語はこちら
As they, you know, for whatever reason. So yeah, if you expect to have it happen, then you should probably handle it in your code. So time out. I probably handle it as a results like success or failure, but then I would retry it 3 or 4 times and then if I still failed then maybe I'll turn that into an exception because at that point there's nothing I.
何らかの理由で。それが起こることを期待するなら、コードで処理すべきです。タイムアウト。おそらく成功または失敗として処理しますが、3〜4回再試行し、それでも失敗した場合は例外に変換するかもしれません。その時点で何もできないからです。
Ed Mann
英語はこちら
Can do now that makes a lot of sense and maybe just kind of summarising up with the functional programming kind of part of this is that what why do you think and this may be my understanding is that why do you think folk programming languages are still less common compared?
理にかなっています。関数型プログラミングの部分をまとめると、なぜ関数型プログラミング言語はまだ一般的ではないと思いますか？
なぜ関数型プログラミング言語は一般的でないのか
Ed Mann
英語はこちら
To like OO based ones. You know like the the Javas, the C sharps, the JavaScript of the.
OOベースのものと比較して。Java、C#、JavaScriptのような。
Scott Wlaschin
英語はこちら
World well it's interesting think a lot of it is coincidence actually what you might call what do they call it a something path thing like well it's the same reason why keyboards have QWERTY keyboards because that's how it was you know so I remember I'm old enough to remember when oh programming was not common when Java came around and.
世界的には興味深いことに、多くは偶然だと思います。キーボードがQWERTY配列なのと同じ理由です。私はJavaが登場したときにOOプログラミングが一般的でなかったことを覚えるほど年を取っています。
Scott Wlaschin
英語はこちら
Everything was basically C and maybe a bit of C but I remember when C started becoming popular and I was doing, that's when I was doing small talk. And I remember with small talk and people were saying what is this newfangled object oriented programming stuff? And again, you get exactly the same arguments that you get with functional programming today. It's like was too weird. Nobody's going to understand it. It's too different from what I used to. And I think what happened is that as the time when.
すべては基本的にCで、少しC++がありました。C++が人気になり始めたとき、私はSmalltalkをやっていました。Smalltalkで、人々は「この新しいオブジェクト指向プログラミングとは何か？」と言っていました。今日の関数型プログラミングと全く同じ議論です。奇妙すぎる。誰も理解しない。慣れているものとあまりにも違う。そして何が起こったかというと、
Scott Wlaschin
英語はこちら
When computing, that was in the 90s.
コンピューティングが、それは90年代でした。
Scott Wlaschin
英語はこちら
When the Internet took off, where personal computers took off and where businesses really changed their business processes to work with computers because prior to that most businesses still use paper and pencil, you know. And so that kind of got stuck. So Java took off and all the things from the noise is what we're stuck with today. And so functional programming, which has been around just as long as C mean.
インターネットが普及し、パーソナルコンピュータが普及し、ビジネスがコンピュータで動作するようにビジネスプロセスを本当に変更したとき、それ以前はほとんどのビジネスがまだ紙と鉛筆を使っていました。それが定着しました。Javaが普及し、その騒音からのすべてが今日私たちが抱えているものです。関数型プログラミングは、Cと同じくらい長い間存在しています。
Scott Wlaschin
英語はこちら
ML functional programming language was invented in 1972 at the same time.
ML関数型プログラミング言語は1972年に同時に発明されました。
Scott Wlaschin
英語はこちら
That C was invented, you know, these language, they're not newfangled techniques at all, but they just weren't there at the time. I think they were very academic and I think that OO, I think that OO thing was easier for people to understand at the time because it was again, it was using the.
Cが発明されました。これらの言語は全く新しいテクニックではありませんが、その時にはなかっただけです。非常にアカデミックで、OOの方が当時の人々には理解しやすかったと思います。
Ed Mann
英語はこちら
Words that normal people used. I was going to say the fact that objects is like you have a, I mean the you have a car and a car has.
普通の人々が使う言葉を使っていました。オブジェクトは、車があり、車にはエンジンがあるというように、
Scott Wlaschin
英語はこちら
An engine exactly feels, you know, exactly. And I think that's the thing about the functional programming people at the time of very academic and very mathematical and.
エンジンがあるという感じです、その通りです。当時の関数型プログラミングの人々は非常にアカデミックで数学的で、
Scott Wlaschin
英語はこちら
They weren't interested in domain modelling, you know, in a functional way. So definitely the OO people kind of got there first. And the perception of functional programming is something very academic and very unfriendly has persisted. And so I'm trying to do my bit to sort of change that perception. But yeah, unfortunately that's sort of there. But I mean, personally, I think, you know, having done both, I think I'm one of the few people I think, who has done both small talk and functional programming. And I can, you know, confidently say which is good for which.
関数型の方法でドメインモデリングに興味がありませんでした。間違いなくOOの人々が先に到達しました。関数型プログラミングが非常にアカデミックで非友好的であるという認識が続いています。私はその認識を変えるために少しずつ努力しています。残念ながらそれがあります。個人的には、SmalltalkとFunctional Programmingの両方をやった数少ない人の一人だと思います。どちらが何に適しているか自信を持って言えます。
Scott Wlaschin
英語はこちら
Situation and I mean I love small talk, it's one of my favourite languages ever but for business programming I think that a pragmatic functional, statically typed functional programming like F is great I think it's the best enterprise development language and ionically I really do think all businesses should be using it as a standard thing because it's very pragmatic it's not you know it's not an academic language at all but I mean yeah, it's I think it's just taken a while I mean what's interesting is that a lot of the.
状況によります。Smalltalkは私のお気に入りの言語の一つですが、ビジネスプログラミングには、F#のような実用的で静的型付け関数型プログラミングが素晴らしいと思います。最高のエンタープライズ開発言語だと思います。皮肉なことに、すべてのビジネスが標準として使用すべきだと本当に思います。非常に実用的で、アカデミックな言語ではありません。時間がかかっただけだと思います。興味深いのは、多くの、
Ed Mann
英語はこちら
Stuff has filtered in. I was going to say that the fact that all these concepts, these paradigm.
ものが浸透してきました。これらすべての概念、パラダイムが、
Ed Mann
英語はこちら
Paradigm is in all these languages.
パラダイムがすべてのこれらの言語にあります。
Scott Wlaschin
英語はこちら
Yeah, using lambdas and I've seen people talking about the result pattern now in all the, you know, well, we want to programme in other languages, um.
はい、ラムダを使用し、Resultパターンについて話している人々を見ました。他の言語でプログラムしたいと思います。
Scott Wlaschin
英語はこちら
I think it's it's it's gradually filtering in, but I can say exactly option types is coming in. The problem from my point of view is the defaults like I say things like immutability are not there. So it's it's kind of ugly. Trying to do functional programming in Java is possible, but it's ugly. And so and then that gives people a bad experience with it because it's like, well, why it's so ugly? Why would I do that instead of the non ugly which is the built?
徐々に浸透していますが、オプション型が入ってきています。私の観点からの問題は、不変性のようなデフォルトがないことです。それは醜いです。Javaで関数型プログラミングをすることは可能ですが、醜いです。それが人々に悪い経験を与えます。なぜこんなに醜いのか？なぜ組み込みの非醜いものの代わりにそれをするのか？
Ed Mann
英語はこちら
In way of doing things. What else is the worst case of you're now, as you say, shoehorning in stuff and then you've got.
やり方で。最悪の場合、押し込んでいて、
Ed Mann
英語はこちら
Blender both where this you've got a language code base that has a bit of, oh, a bit of functional. You're like, well, what are we doing?
両方を混ぜ合わせて、少しのOO、少しの関数型を持つ言語コードベースがあります。何をしているのか？
Scott Wlaschin
英語はこちら
Here and it just, yeah, yeah. Well, I can actually give you some real, a real example of that is which is Scala, which is a very good function of programme language, but it's also designed as a good object oriented language. And what happened in Scarlet, there was this massive split between the people using as a better version of Java versus other people using it as a Haskell on the JVM and those two groups of scholar programmers.
ここで、はい、はい。実際の例を挙げることができます。Scalaは非常に良い関数型プログラミング言語ですが、良いオブジェクト指向言語としても設計されています。Scalaで起こったのは、Javaのより良いバージョンとして使用する人々とJVM上のHaskellとして使用する人々の間で大きな分裂がありました。
Scott Wlaschin
英語はこちら
Completely different and they.
完全に異なり、
Scott Wlaschin
英語はこちら
You know, talked past each other all the time, but the problem is you now have these Scala code bases where people can't understand the code you have. The Haskell people started writing the weird Haskell code with free monads and stuff, and then the Java Scala people couldn't understand a word they'd written because Scala didn't have a single. The problem with Scala is because it was multi paradigm. It truly is multi paradigm. It didn't have exactly. And that's a bad thing because it means that you have so many, it's so easy to do things in so many different ways that it's very hard for.
お互いに話が通じませんでした。問題は、Scalaコードベースで人々がコードを理解できないことです。Haskellの人々はフリーモナドなどで奇妙なHaskellコードを書き始め、Java Scalaの人々は彼らが書いたものを理解できませんでした。Scalaの問題は、マルチパラダイムだったことです。本当にマルチパラダイムです。それは悪いことです。なぜなら、多くの異なる方法で物事を行うのが簡単すぎて、
Scott Wlaschin
英語はこちら
Someone else to come along and maintain that code.
他の人がそのコードを保守するのが非常に難しいからです。
Scott Wlaschin
英語はこちら
So actually, and that's another reason why I like languages which have a particular strong paradigm. Now Python is classic for having like there's the Python way of doing things and there's the F# way of doing things. There's the Haskell way of doing things. But the Scala that caused the button problem, but I think most of the OO Scala people have.
実際、それが特定の強いパラダイムを持つ言語が好きなもう一つの理由です。Pythonには「Pythonの方法」があり、F#には「F#の方法」があります。Haskellには「Haskellの方法」があります。しかしScalaはその問題を引き起こしました。ほとんどのOO Scalaの人々は、
Ed Mann
英語はこちら
Now switched to Kotlin instead. I wonder what the reason. I don't know why. I feel like the reason why these objects or you know, the class based stuff was in there and the O stuff was. It was a transition. It was a way of being able.
今はKotlinに切り替えました。理由は何でしょうか。わかりません。オブジェクトやクラスベースのものがそこにあった理由は、移行だったと感じます。それは可能にする方法でした。
Ed Mann
英語はこちら
To transition people to more of a functional mindset, I think. I think the original idea.
人々をより関数型のマインドセットに移行させるためだったと思います。元のアイデアは、
Scott Wlaschin
英語はこちら
Well, it was. It meant to be.
それは意図されていました。
Ed Mann
英語はこちら
A multi paradigm language Was it be the best of everything? That's maybe a use case for saying this is.
マルチパラダイム言語、すべての最良でしたか？それは言うための使用例かもしれません。
Scott Wlaschin
英語はこちら
What happens if you have the best of everything? I mean, another good example of that is something like Pearl, the language where you can do all sorts of weird stuff. I personally, I don't like that. And that's one of the things I actually, I don't like the way that C# is going because it's trying to do too many things at once and you're trying to maintain the code base. If I'm looking at C# code, if I look at C code from 10 years ago, it's going to be completely different from C# code written today. Now if I look at F# code from 10 years ago.
すべての最良を持つとどうなりますか？別の良い例はPerlのような言語で、あらゆる種類の奇妙なことができます。個人的には好きではありません。C#が向かっている方向も好きではありません。一度に多くのことをしようとしていて、コードベースを維持しようとしています。10年前のC#コードを見ると、今日書かれたC#コードとは完全に異なります。10年前のF#コードを見ると、
Scott Wlaschin
英語はこちら
Looks exactly the same. I mean very very minor differences, but I guarantee I could maintain an F# project from 10.
全く同じに見えます。非常にマイナーな違いですが、10年前のF#プロジェクトを保守できることを保証します。
Ed Mann
英語はこちら
Years ago. Well, it's also strange with that because it's some of Clr, like I understand if you've got different stacks completely, like if I'm using the fact that they're compiled down and they're running on the same virtual machine, I don't understand why we would bother trying to make like, hey, you've got, oh, oh, you've got C# for that and hey, you've got.
年前。CLRの一部であることも奇妙です。完全に異なるスタックがある場合は理解できますが、同じ仮想マシンで実行されているのに、なぜわざわざ、OOにはC#があり、
Scott Wlaschin
英語はこちら
F# for that you've and they can pole down and you can manage them and people can run them fine. Why would you want to blend the world? Because people.
F#があり、それらをコンパイルして管理し、人々がうまく実行できます。なぜ世界を混ぜたいのですか？人々が、
Scott Wlaschin
英語はこちら
Themselves in terms of their programming languages. That's right. It's like people are very anti and that's something which has got worse. I think when I was learning programming, people took pride in knowing multiple languages and it was they all knew you know, so when I would learn all these different languages when I was starting out, but I think nowadays people just learn one language and they stick with it. So you know, I think.
プログラミング言語の観点で自分自身を定義するからです。その通りです。人々は非常に反対で、それは悪化しています。私がプログラミングを学んでいたとき、人々は複数の言語を知ることに誇りを持っていました。始めたときにこれらすべての異なる言語を学びましたが、今日では人々は1つの言語を学び、それに固執します。
Ed Mann
英語はこちら
Well, they go. I need to learn JavaScript or TypeScript because it runs everywhere. Is the world, isn't it? It's like exactly.
彼らは行きます。JavaScriptやTypeScriptを学ぶ必要があります。どこでも動作するからです。世界ですね。その通りです。
Ed Mann
英語はこちら
And I guess it's the biggest ban for their buck. I don't know. That's another thing. Maybe people think it's like, if I learn this, it's going to.
最大の投資対効果だと思います。わかりません。もう一つのことかもしれません。人々はこれを学べば、
Scott Wlaschin
英語はこちら
Apply to a lot of different areas. Yeah, except that the programming language is actually pretty easy to learn. The actual language is typically easy to learn. Now, it is true that the library that goes with the language is hard to learn. Like if you learn, you know, for example, C# and Java, pretty much the same language, but the libraries that go with them, the C# collection class is different from the Java collection classes and so on. So if I've invested a lot of time in learning the Java collection classes, it's still going to.
多くの異なる分野に適用されると考えるかもしれません。はい、プログラミング言語自体は実際にはかなり簡単に学べます。実際の言語は通常簡単に学べます。しかし、言語に付随するライブラリを学ぶのは難しいのは事実です。例えば、C#とJavaはほぼ同じ言語ですが、それらに付随するライブラリ、C#のコレクションクラスはJavaのコレクションクラスとは異なります。Javaのコレクションクラスを学ぶのに多くの時間を投資した場合、
Scott Wlaschin
英語はこちら
Going to be a bit of a hurdle to switch to C# and vice versa. So but in general, people think people think learning a language is, you know, mostly it's not that hard to learn a new language really. I mean, like, I know how paradigm is harder, but paradigm exactly. The paradigm is really hard languages. It was much harder for me to learn a functional programming as a way of thinking than it was that learning the syntax for doing F# or something. Absolutely.
C#に切り替えるのは少しハードルになります。しかし一般的に、人々は言語を学ぶことは、実際にはそれほど難しくないと考えています。パラダイムは難しいですが、その通りです。パラダイムは本当に難しいです。F#の構文を学ぶよりも、考え方として関数型プログラミングを学ぶ方がはるかに難しかったです。絶対に。
(2)-2 はこちら
(2)-3 はこちら
Discussion