宣言的と手続き的の基本概念
マヂカル.fmは関西人のプロダクトマネジャー(?)のみちるだと、関西人のソフトウェアエンジニアのファミンが、なんだっけ、やってるプロトキャストです。
プロトキャストってなんだよ。
私なんで覚えてないの。
読んでないからだよ。
その変な、(?)の位置をアレンジすることで後半読めなくなるっていう。
でも合ってますよね。
私は関西人、私は関西人。
間違ってる。
だいたい合ってるじゃん。
そもそもが間違ってるから。
この人、話通じない人だよ。
たまに言う。
そこを感化する、その論点を感化するわけにいかないから。
街のなんか厄介な有名人の。
厄介な有名人?
なんで?
街の。
あの人ダメダメ。
おばあとかじゃなくて有名人。
有名人迷惑おばあみたいなことってこと?
そうそう、街にいますよね。
いなかった?
どういうこと?
一人で喋ってる。
名物人間みたいな。
名物おじおばあみたいな。
私の地元にはおじさんが、
助走して、
家から最寄りのコンビニまで
30キロあるんですけど
自転車で往復して、
通りすがる、知ってる
毎日通るような車には
手を振るっていう
人が、名物おじさんがいました。
名物ですねそれは。
これ話した気がするけど。
なんか聞いたことある話です。
中学校の時清掃活動を
外でやってたら
ゴミとか捨てたら
中学校の近くの
すごい泥だまりみたいな
ところから
クレジットカードの迷彩出てきて
見たらその人の
名前書いてた。
何の話?
どういう出来事?
今日は
オープニング?公式オープニング?
オープニングです。
今日のテーマは
これ何シリーズ?
みちるだテックシリーズ
ミチル初心者が学ぶ
テックシリーズ
前回はベキトーセがありましたけど
だいぶ難しいよね最初から
でもベキトーセも理解したし
忘れたらエピソード聞き直せばいい
完璧
今日は宣言的と
手続的の違い
です。
なんだそれ?
今日はですね
宣言的と手続的って聞いて
聞いたことありますか?
開発チームの
ベキトーセよりはだいぶ頻度低い
ですけど
文字面で見たことはある
って感じかも
うぱさんからなんかで聞いたんだよ
なんかで?
宣言的は素晴らしいみたいな
みたいなんとか
前の人が毎週やってるLTの中で
これは宣言的だから
かっこいいやつだからいいとか
そういう文脈で
みんな当然のこととして
ふむふむみたいになってるけど
なに?みたいな
だいたいプログラミングって宣言的じゃないのかなっていう
じゃあまず
今日もベキトーセと同じように
宣言的と
手続的の
ざっくりした意味から始めて
いくつかの領域での
宣言的と
手続的だったらどうか
っていう話をしていこうかなと思います
料理の例による違い
はい
まず基本的な概念
なんですけど
宣言的はどっちも
基本的に
プログラミングの手法
ではあるんですけど
宣言的なプログラミング
手続的なプログラミング
もっとプログラミングよりレイヤーを上げて
そもそもそういう
宣言的な手法とか
手続的な手法
みたいな感じで
プログラミング以外のことにも
使います
この間言ってた
宣言的に記述できるんですよね
っていうのはもうちょっとプログラミング
上というか
レイヤーの話ですと
そもそも宣言的
と手続的の記述
どう違うねんっていう話
なんですけど
宣言的は
何をしたいかっていうことだけを
書きます
まぁ一旦受け入れてください
手続的は逆に
どうやれんっていう話なんですけど
どうやって
それを実行するか
っていうことを書く方法です
と
なんかそうか
そういう意味で言うと
私がイメージするプログラミングは
校舎っぽい
その理解は多分あってる
手続き
howを指定してアウトプットを出す
ものなイメージです
そうですね
なんで宣言的は何をしたいかだけ
宣言的っていう
言葉の通り宣言だけ
宣言だけします
いやでもあってる
でもなんかその
あそうかhowの流度次第かもしれない
まぁそうかも
宣言的は何をしたいか
っていうことだけを記述する
つまり支持するんで
そのhowはどうでもいいんですよ
手続き的は逆に
そのhowの方にどっちかというと
フォーカスを当ててるというか
当てる
当ててしまっている
手法ですと
そうしたくないのにってこと
ケースバイケースですけど
そういう時もありますね
多分
ちょっと話を進めると
現実世界の例なんかないかなと思って
ちょっとChatGPTに考えてもらったんですよ
例ありますかって
うん
そしたらあの料理の例があって
あの
カレーを作りたいみたいな
時に宣言的な手法は
まぁ両方なんか
コックさんみたいな人がいると
しましょう宣言的は
コックさんにカレー作ってって言うだけ
で手続き的な
アプローチは
コックさんに玉ねぎ切って
鶏肉炒めて
ルー溶かして
逐一指示して
作っていく方法が
宣言的と手続き的の
違いです
ざっくりイメージ
宣言的に
宣言的なアプローチ
だと
システムが
最適な方法で実行してくれます
この場合コックさんですね
コックさんがいい感じにやってくれます
逆に手続き的だと
すごい自分にこだわりある
場合とかに細かい制御が
できる鶏肉は
片面何分で焼いてとか
いうのが
できます
細かい制御ができるので
最適化しやすい
みたいなメリットがあります
SQLの説明とその特徴
で
ここから具体例に
入っていってもいいですかね
例えば
みちるださんはプロダクトマネージャーなんで
日々SQLと
タームれてる時間が
あると思うんですけど
SQLってどっちか分かります
ハウの方じゃね
手続き
ちなみに
SQLっていうのは
データベースの
中身の値を集計したり
分析するための
あれは何ですか
グリランゲージですね
はい
今
今月経費生産を
上げたユーザーは何人いますか
とか
何業以上で申請した人は
何人いますかみたいなのを
集計とかができる
方法のことですね
私はそれを使うときに
それこそ
例えば
どういう条件のお客さんに
絞ってくださいとか
それを
月単位で
何件の申請が上がっているかを
お客さんの環境ごとに
集計して出してください
みたいなのを
決まった文法で書いて
結果を取得しています
なのでそれは手続き的
なんじゃないかなと
正解は
SQLは宣言的な代表例です
はぁ
なんでかっていうと
例えばその経費生産を
使っているユーザーを取得して
みたいなクエで書くときに
どういうものが欲しいか
だけを記述するじゃないですか
どういう結果が
欲しいかっていうこと
howは書いてないんですよね
どうやって取るか
どうかっていう
経費生産を使っているユーザー
isの条件とは
例えばこの
カラムに値が入っている
人です
このカラムの値が入っている
レコードの数を数えてください
みたいな感じで書きますね
こういう結果が欲しいんだよ
っていうのを
何が欲しいかだけ書いて
実際にどうやって
検索するのが早いかとかは
どうやってインデックスとか
呼ばれるものを
使うのがいいかっていうのは
全部データベースが選択するんですよ
基本的には
なんでSQLは宣言的な
例になっていて
これを手続き的で書くって
言ったらめんどくさい
SQLだと書けない
と思いますけど
まずデータベースが保存している
ファイルを全部
開いていって
その中からカラムが
トゥルーになっているってものを
全部一行一行見たりして
条件マッチしていたものだけを
マークして
後から全部まとめて
返すような
プログラムを書かないといけない
地獄ですよね
そうですね
もはやその
裏で勝手にやっていることが
何かのイメージがつかないから
どれぐらい地獄なのかもわからない
SQLなかったら
毎回これも一応言語ではあるんですけど
プログラミングして
取る必要があるっていう感じですね
例えば何の
プログラミングを書くってことなのか
何でもいいですけど
例えばなんだろうな
データベースだとSQLで操作される前提
になっているので
データベース自体が
直接取るってことは
普通はプログラミング言語でやらないんですけど
例えば
もっと簡単な例で言うと
スプレッドシートとかに
データベースと
同じような見た目になるじゃないですか
はい
ユーザーがいっぱい並んでて
けいせいさんが
使ってるユーザーは
チェックマークがついてますみたいなやつだったら
ガスって使ったことあります
ありますね
あれで書く行を見て
ここがチェックだったら
結果のやつに
入れるみたいなのを
一行一行見てやっていかないといけない
のが手続き的
なるほど
何が欲しいか言ったら
勝手にデータベースが任せろって
やってくれる
けどそれが最適な
データの探索なのかは
データベースにお任せなんで
細かい最適化とかは
しづらいっていう
それって
SQLって
文法みたいなやつが
決まってて
この
対象のコラムを
セレクトしてくださいとか
その対象のコラムをこの条件で
絞ってくださいっていうのも
ウェArcみたいなのでつけて書いたり
するんですけど
他に文法
他に文法
ないかもしれないけど
セレクトなんちゃらで書いてるとか
そこにウェアーをつけている
ってことが手続き的
ということではないんですか
ないですね
あれはどういう行のものが
どういう条件にマッチするものが
ウェArcはあんまり例が良くない
セレクトしてください
っていうのが手続きではない
なるほどね
セレクトはこういうものが
欲しいですってただお願いしてるだけ
なんで
それが宣言的で逆にセレクトを
使わないと
さっき言ったみたいな
ここのファイルとこのファイルとこのファイルを
読んで
結合して中に
入っているそのカラムの
ここが
1だったら
結果として残すみたいなのを
全部書いていかないといけないんですよね
セレクトでお願いしたらデータベースが
手続き的プログラミングの理解
データベースの内部で
いろいろなんか実行計画みたいな
SQLをどうやって
解釈して
実行していくかっていうのを計画を立てて
なるべく早く返せるようにやってくれるんですけど
それを全部
自分でプランニングとかして
データベースの
エンジンに渡してあげないといけないのが
手続き的
ちょっとSQLの例ピンときてない
そうですね私の多分背景知識は
なさすぎて
じゃあもう一つの
ちょっとUIの話
まだ馴染みがあるかもしれない
Reactって聞いたことありますか
単語だけ
Reactっていうのは
そのUIの
ざっくり説明すると
UIを開発するための
ライブラリなんですけど
Reactでは
宣言的なアプローチが
取られてるんですね
つまりどういうことだってばよ
っていう
今までの
手続き的な例での
話をすると
例えば
よく
サイトにある
ハートボタンみたいなのがいいねボタンがあって
ハートボタンってポチッと押したら
ポチッと押したら
色が変わりつつ
横にあるだいたいカウンターみたいなのが
ポコッて
上がるんじゃないですか
その例を考えてみると
手続き的な例だったら
めっちゃめんどくさくて
まず
ボタンに対して
クリックされたら
1ってプラスして
難しい
まず
クリックされたらカウンターの値を
1増やしますよね
増やしただけじゃだめで
カウンターの値を
テキストに反映させないといけないんですよ
例えば9って書いてたら
今9だな
10にしよう
10になったじゃないですか
10をWebのUIの方に
反映しよう
次はそれも反映できたから
次は色も灰色から
赤色とかピンク色に変えよう
っていう風な
1個1個やっていかないといけません
これOK?
多分
なのでそういう感じなんだと思ってました
違うんですよ
宣言的な例の話は
ここでまた
状態っていう話
うわー苦手なんだよな状態
でも状態は
めっちゃ簡単で
いいねを押してない状態と
押してる状態っていう2つの状態が
あります
押してる状態
押した後の状態
最初ページに来たら
いいねを押してない状態ですよね
それポチッと押したら
いいねを押した状態
っていう風に変わるとしましょう
そしたらさっきまでは
それぞれ頑張って更新してたんですけど
それぞれこの
いいねっていう状態を
見ることにしますと
そしたら
ハードの色が
ピンクかグレーかっていうのは
いいねの状態が
押されてたら勝手に
もしいいねが
押されたっていう状態だったら
ピンクにするみたいな
わかります?
なんとなく
灰色になった
宣言的アプローチの利点
押されてないってなったら
こっちも勝手に灰色になるみたいな
感じにできるんですよリアクトの時は
リアクトは
どういう状態の時に
何を表示するかっていうのを
書けばいいんで
例えば
めっちゃいいねの例は簡単だけど
例えば
いいね押されてないとこから
いいね押されたとしたら
例えばですよ
100個の項目があって
いいね押されたら全部の色を変えないといけない
っていうのが
手続き的な例だとめちゃくちゃめんどくさいじゃないですか
最初から最後まで
ループで
回して
色変える色変える色変える色変える色変える
色変えるってやらなきゃいけないですよね
けど
宣言的な場合は
それぞれのやつらが
いいねっていう状態を
表示して
これが変わったってなったら
こいつらが勝手に変えるんですよ
だからこの状態だと
こうなってほしいっていうのを
記述するのが宣言型
そうなんだ
なんか楽
そうだし
ミスとかも減りそうって感じ
そうそうそうそう
シンプルになりそうではある
そうそうそう
それって
イメージになっちゃうんですけど
いいねの
押した
押す前と後の状態で
色が非文字とかはそうだなって感じなんですけど
数が増えるみたいな
カウントみたいな部分は
押したら
押した分だけ増えるとか
あると思うんですけど
それも宣言的に定義できるんですか
できます
数も状態として表すんですよね
例えばページ読み込んだ瞬間は
例えばみんなが
いろんな人が押せる状態だと
押せるんだとしたら
読み込んだ瞬間にまずそのウェブから
今いいね何個分付いてるみたいなのが
取ってきてまず初期状態として
10個だったら10っていう状態が
表示されてます
である
ハートのボタンをクリックしますと
でそのハートのクリックしたら
そいつがやることは
このいいねの数っていうのと
ハートの今の状態っていうのを
変えるだけ
で
いいねの数を1個プラスします
例えば10だったら11
でいいねの状態は
いいねされたっていう状態になります
でこのクリックしたやつの仕事は
もうこれでおしまい
で他のやつが
いいねの数が10から
11になったからその表示も
10だったけど11に更新しなきゃっていうのを
やったり他のさっきみたいな
コンポーネントたち
他のやつらが
いいねされたっていう状態になったから
自分の色変えなきゃみたいな感じで
変わっていくっていう感じです
さっきミスが減るみたいに
言ったのは
いろんな
ものの挙動を
例えばいいねの状態に応じて
独立的に持てるからみたいな
のもありますか
そういう感じではないですか
状態に
状態に起こすことで
いいねの状態に応じて
事象
項目ABCは
それぞれ
αβγになるけど
それは
別事象として
定義できるみたいな
一連の連続したロジックだと
どれかがこけたら他も
こけちゃうとかあるけどみたいな
そうですね
手続き的なやつだったら
1個更新したいやつが
例えばこの要素もいいねされたら
更新したいんだよねってなったら
クリックされたときの処理にまたそれも
加えないといけないから
クリックされたときの処理がめっちゃ長く
なりそう
宣言的だったら
この状態がこう変わったら自分はこうなるべき
っていうことだけを記述するから
ここのロジックが増えないんですよ
クリックされたときは
こいつがやることは数を増やすのと
いいねの状態を
記述するだけ
だからさっき言ったみたいな
宣言的なUIによって
前まではJQueryっていうやつとか
頑張って
要素を取ってテキスト書き換えて
色変えてとか
いっぱいやったんですけど
それがいらなくなりました
どうしようかな
ここの例だったらまだ
ECサイトのショッピングカートの例とか
あるんですけど
状態管理の自由度
もう理解できたかな
アズイズがあんま分からないから
2Bの素晴らしさを
自観できてないかも
素晴らしいものという評価なんですか
宣言的に
宣言的に書けた方が
嬉しいですか
嬉しいですね
状態を定義というか
状態はこれですよってやったら
各
コンポーネントって呼んでるんですけど
見た目たちが
実質的にその状態に
自分を合わせるように動いてくれる
ショッピングカートの
UIとか
ボタンをカートに入れるって言ったら
カートの中身が増えて
例えばカートのアイコンに
何個入ってるよって言われてる
数字が増えたりとか
合計金額が変わったりとか
色々変わるじゃないですか
それを手続き的に書いたら
めちゃめんどくさいもん
例えば
カートに追加ってなって
カートに追加したってことは
数字のアイコンの
数字をプラスして
例えば2個入ってるところに1個追加したら
3っていう風にしなきゃいけないし
開いたときの
だいたいカートってほばしたら
商品が1個
今入れたやつが追加されたり
合計金額とかも
表示されてるじゃないですか
それをクリックしたらこれを更新して
これを更新して
っていうのを全部
指示してあげる必要があります
クリックされたときの挙動を
手続きだから
最初は大丈夫だと思うんですけど
レファクタリングとかで
変えたときに
すごい極端な例ですけど
更新処理をいい感じにしました
なんですけど
ある特定の呼び出し方だと
金額の更新が
実行されないみたいなことがあったら
ちゃんとカートには追加されて
カートは2つから3つに増えてるのに
金額だけ新しくならない
みたいなバグが
発生する可能性もあるんですよね
呼び出し忘れとかで
すごい極端な例ですけど
これは宣言的な
例にすると
どうなるかっていうと
カートの中身の状態っていうのを
定義してあげて
今はある2つのものが
入ってますと
3つ目追加しますってなったら
いろんな奴らが
このカートの状態っていうのを
見てて金額は
このカートの状態の
それぞれのものの合計金額を
表示するだけだし
カードのアイコンバッジみたいなやつは
このカートの中身に
入ってる
合計の個数だけを
表示するだけみたいな感じで
カートに入れるって
クリックした瞬間は
この状態を一個ポコって追加するだけ
そしたら
他のコンポーネントが自律的に
自分の金額書き換えないととか
やってくれるってことですね
あれですね
それを聞くとますます
なんだろう
なんか
その状態ドリブンな宣言的に
こう作る書く
方が
やりやすそうすぎて
手続き的に
書く
のが
そうじゃないやり方とはみたいな
確かに
初見で聞くとそういう感じに
思います
そのやり方しかなくね
一番効率的じゃねっていう
そうですね
あとその状態の定義って
どんぐらい
自由度高くできるんですか
なんでもできます
なんでもできます
数字もできるし
オブジェクトみたいな
なんでも入れられるんで
望むがままに状態の定義できます
状態の定義の
抽象化レベル
どんだけ抽象化して
状態にするか
だいぶ作りやすさとかの
ポイントという感じですか
はい
明日からエンジニアになりますか
そうなんですよね
この状態を
何を状態にすべきかっていうのも
難しい
何でもかんでも
突っ込みすぎたら
なんだろうな
宣言的と手続き的の違い
状態が更新されたよ
っていうのが
本当は関係ないんだけど
バカデカ状態を見てるせいで
自分関係ないけど更新する必要があるのか
みたいな感じになっちゃったりして
よくない
普通にプログラミング的にもパフォーマンス的にも
よくない
あと
なんでこれ昔からなかったんだよ
なんで昔手続き的だったんだよ
みたいなのは
前はこの手法が現実的じゃなかったんですよね
もちろん
技術的制約があって
なんだろうなというのは
本当は前までは
いろんなやつが
状態元に自分を更新するってなったら
更新するって
めっちゃコスト高いんですよ
自分の
見た目を更新するってのが
コスト高いんですよね
更新するいず
ウェブの見た目が変わるみたいな
感じですけど
その手法を普通に真似すると
例えば
いいねボタンの例で考えると
ポチッと押すじゃないですか
ポチッと押した瞬間に
関係ない全てが変わるみたいな
だから全体の
レンダリングが毎回走る
みたいな感じで
めっちゃ遅い手法だったんですよ
あんまり現実的じゃない
それをカゲスさんが
リアクト
例えばさっきの例だったら
位置増やして色変える
だから全体じゃなくて
どこを書き換えるべきなのか
っていうのがリアクトを計算してくれて
その差分だけを書き換えてくれる
っていうのが出てきたんで
例えばさっきの例だと
ハートをピンクにするところと
数字を増やすってとこだけの
このちっちゃい部分を
サイレンダリングするっていうのがあって
宣言的に書けるようになった
へー
じゃあ
そうなんだ
私フロントエンド明るくないんで
リアクト以外の言語だと
手続き的にやっている
昔はそうでしたけど
今はリアクト的なアプローチが
多い
そうなんですね
偉大ですね
そうなんだ
私はあんまりやったことないんですけど
例えばさっきの話とか
逆に手続き的なもの
どこに必要だねん
っていう感じですけど
複雑な
サーズでめっちゃ複雑なアニメーションとか
ないと思うんですけど
そういう複雑なアニメーションとか
ゲームの実装とか
パフォーマンスをめっちゃ最適化したみたいな時は
はいはい
宣言的なやつだと
結構リアクトにお任せとか
そういう感じになっちゃうんで
自分で手続き的に
カリカリにチューニングしたいみたいなやつは
そういう
手続き的なアプローチも
使いますよっていう感じですね
テラフォームの革新
手続きは
Howの部分
どうやってこれを動かすかっていう方に
フォーカスして
宣言的はどう見せたいかっていうところに
フォーカスしてるっていう感じ
Howはあんまり
いい感じに
手続き的に書くと
複雑な挙動みたいなのが
正確に再現できるみたいなのは
そうやなという感じで
傾向として
宣言的の方が上手くなりやすい
とかもあるんですか
そんなことも
ないですけど
手続きの方が
よりこだわれるというか
自分チューニングできる
だからといって手続き的に
やった方が宣言的より
早いとは別に限らない
コックさんにお任せでカレー
作ってって言ったやつが自分が
細かく
指図して作ったカレーより
早くなるとは限らないみたいな
逆も言える
ちなみにその手続き的な
アプローチと宣言的なアプローチが
例えば一つの言語の中で
混在することもあるんですか
混在することもあります
それはなんか
サービス内で混在するとかも
そうなんだ
だからさっき言ったみたいに
普通は宣言的なアプローチで
書くんですけど
普通に書くとパフォーマンスが
悪いということが分かっているから
ここは手続き的に書くとか
そうなんだ
そうですね
じゃあ
SQLとUIの話をして
最後にあんまり
みちるださんが
馴染みないかなと思うんですけど
前のトピックも絡めて
インフラの話なんですけど
これもなんかすごい
ここ最近といっても10年ぐらいだけど
宣言的と手続き的の
パラダイムの革新が
あったのが
インフラなんですけど
テラフォームって多分聞いたことありますよね
よく分かんなかったやつなんだよな
テラフォーム
2014年
10年ちょい前か
結構前なんですね
結構前ではないの
2010年って
14です
でも10年前ぐらい
例えば
作って
めっちゃめんどくさくて
それ以前
それ以前って
オンプレみたいなことさせてますか
クラウドでも大変
例えばAWSで
デブ環境と
ステージング環境
本番環境みたいなのが
大体あったりするんですけど
3系統みたいな
デブ環境と同じ構成を
ステージング環境に作りたいな
AWSにログインして
サーバーが何個必要で
今ゼロ個だから3つ作って
データベース1個作って
ポチポチポチポチ
やっていく必要があったんです
バリめんどくさいじゃないですか
そりゃそうだろうって
思いました
手続き的な
まさに手続き
なんですけど
これを解決したのが
テラフォームなんですね
テラフォームは
このファイルに
例えば
サーバーは
3台欲しいとか
データベースは1台でいいとか
そういうのを書いておくんですよ
そしたら
それをそのままAWSにペロって
投げ入れるようになります
そうすると
AWSが3台必要だろうねっていう風に
解釈して
3台分作ってくれたり
1個作ってくれたりします
ここで大事なのが
適当性が効いてくるんですけど
テラフォームには
結果的に何が欲しいかを書くんですよね
そこで
3台欲しいってなったとするじゃないですか
それで実行するたびに
3台増えていったら困るんですよ
今1台だけあったら
3台欲しいっていったら増やして欲しいのは2台なんですよ
うん
それも
できるように
適当性がないと
何回実行しても
初回の実行したのと同じ結果が得られる
っていう適当性があるから
テラフォームが扱えて
1台あったら
2台だけ追加するし
3台あったらソロコマは何もしないみたいな感じで
宣言的に
結果こういうスペックのサーバーが3台欲しいし
こういうスペックのデータベースが欲しい
っていう風に書いておくだけで
それをAWSに適用
してくれるのが
テラフォーム
それが何が便利かというと
その時点で便利なんですけど
デブ環境の設定と
ステージング環境の設定って
結構名前が違うだけとか
あとはデブ環境は1台でいいけど
ステージング環境は3台
本番環境は10台
ちょっと数字が違うみたいな
それもこのファイルを
それぞれちょっと違う
差分だけいい感じにすることで
それを
デブステージングプロダクション
本番環境で
全部毎回作り変えることなく
宣言的なアプローチで
操作の簡素化
全部いけるっていう
今のその
適当性があることで
安心であるっていうのはそうだな
っていうので
そもそもの
プロフォームができて嬉しいっていうのは
GUIでポチポチにしないといけないのを
スクリプトで書けるから
嬉しいってことなんですか
それがもうちょっと知りたい気がします
スクリプトじゃなくて宣言的に書ける
何が欲しいかっていうのを
書いとけばその通りになるっていうのが
肝ですね
今まではインフラも
ポチポチ以外に
スクリプト的なやつもあったんですよ
勝手にこれを実行したら
3台分作ってみたいな
それって
毎回そういう
自作で何か
適当性のチェックのアプローチが
必要だったんですよね
3台作ってって言ったけど
本当に作るべきは
0台なのか1台なのか
2台なのか3台なのか
追加で3台作るのか
結果3台欲しいのかが
AWS側で分かんないみたいな
だからスクリプト
自分の書いたスクリプトで工夫しなきゃいけなくて
まず今の状態を
取ってきて
それもユーザーで定義しないといけない
気をつけないといけないポイントがあったってことですね
それを全部
AWSだったらAWS
GoogleのGCPだったらGCP
みたいな感じで全部スクリプト
書くのめちゃくちゃ大変じゃないですか
けどテラフォンは内部でそれを隠蔽してくれて
隠蔽って言うんですか
隠蔽
何を隠蔽
面倒くさいこと
例えば今何台ありますか
1台です
じゃあ差分で必要なのは2台ですね
ユーザーがいちいちスクリプトで書かなくても
何が欲しいかっていうことだけ書いておけば
面倒くさい仕事は
全部テラフォンがやってくれるんで
テラフォンを使うユーザーからのインターフェースとしては
何が欲しいかだけを書けばいい
なるほど
インフラの例は
確かに便利だってなること予測してたんだけど
そうならなかった
あれですね
多分バックグラウンドないすぎるせいな
気がしますね
ユーザーで気をつけないといけない
元のそのスクリプトが
どんだけ大変かみたいなのを知らないから
あんまりピンときてない
ような気がします
何が欲しいか書いておけば
全てもう
あとはやっといてくれるっていうのは
めっちゃ便利じゃないですか
本来ならどうしたいかを
全部書かないといけないんですよ
現在何台ですか
2台です
その時は1台追加しましょうみたいなのを
なるほど
条件分岐みたいな
ある時ない時を書かないといけないんですね
関西人ですか
はい
そういう条件分岐みたいな
なるほど
よく言われる制御公文みたいな
もしとか
ループ
繰り返しとか
そういうのを
テレフォームでも書くときはあるんですけど
そういうときは
もし本番環境だったら
10台にするとか
基本的に
もし2台だったら
今2台だったら
なんとかするみたいなのは
基本的にはいらない世界になってる
何が欲しいかを書くだけ
どうしたいか
めっちゃhowを書かなくていい
っていうのが
インフラの例に限らず
UIでも
SQLも
同じ
それが手続きとして宣言的な違いですね
プログラミングの基本的な違い
なんか
自分があんまピンとこない理由が
なんとなく分かって
なぜかっていうと
私は
基本情報
情報の資格を一瞬取ろうと思ったんですけど
でも
後半に
実技じゃないけど
プログラミングの
行動を
ドキュメントでやる試験
謎の問題があるんですけど
たぶん
それって手続き的な
ですよね
なんか
全然分かんなかったんだよ
なんで分かんなかったか
で
SQLとか書いてるけど
全然ピンとこないなと思って
どっちで勉強やめちゃったんですけど
それはたぶんSQLが
宣言的に書けるもので
でもその
手続き的に間を
それこそめっちゃ条件分岐とかを
考えて書かないとだめで
そのアプローチが全然よく分かんなくて
ちょっとコスパ悪いなと思って
普段使わない考え方だなと思って
やめちゃった
なんていうのを思い出しました
そうですね
だから宣言的だったら
ハウの部分はどうでもいいから
俺が欲しいのはこれだって
教えてる
めっちゃそれの局地って
いわゆる今のLLMで
こういうものが欲しいよって
言ったらLLMがめっちゃいい感じにしてくれる
っていうことで
あってますか
あれは宣言的ではないんですか
そうですね
宣言的ではないからなのかな
それはあんまり宣言的っていうのは
その感覚ではないんだ
言ってる人いるのかな
出力が一定じゃないじゃないですか
それはそうかもね
確かにネオ宣言的
局地
宣言的局地
例えばブラウザーエジェントとかで
ここのサイトの
ここのログインして
ここのカードメーサーに
取ってきたみたいなのって
以前までってスクレーピングとかだと
このURLの
この要素のここに
IDパスワード入れて
ここをクリックしてこのメニューに遷移して
まさに手続き的な
感じだったけど
ブラウザーエジェントみたいなやつだと
このURL渡して
カードメーサー取ってきた
って言うだけで
ハウがお前に任せるけど
ちゃんと取ってきてね
って感じになるから
宣言的
でもやっぱ難しいかもあんま分かんないや
違う
今の手続き的やな
って言ってたスクレーピングの部分も
なんかなんだ
そのこのhtmlの
ここを取ってって別に結果を指定してる
くねとも
思ってしまいました
結果を指定してる?
欲しいものを指定してるっていうか
ハウを指定してるんですよね
でもハウもなんかある種の
なんか
欲しい結果をめちゃくちゃ
要素分解した
部分の結果ではある
そこがあんまピンときてない
気がするな
どういうことだ
カレー作りで言う
鶏肉を炒めてみたいな
でもそう
炒めた鶏肉が欲しいっていうのも
カレーをめっちゃ要素分解したときに
ユーザーが得たい結果じゃないですか
うんうんうん
めっちゃ細かく宣言してる
ということ?
そうですね
なんか外のインターフェースから言ったら
なんかなんだろうな
一番なんだろうな
外のインターフェースがどうなってるかっていうところで
リアクトとかでも
外のインターフェースとしては
この状態が変わったら更新してみたいな
宣言的な
例ですけど
内部でやってることは
意識的なことで
一番外のインターフェースを
隠ぺいしてるだけなんで
例えばブラザーの話とかも
一番外のインターフェースは
その
howが知らないけど
これやっといてみたいな感じじゃないですか
一つのスクレーピングのやつは
めっちゃhowにこだわってる
というか
howを指定せざるを得ない
どこのなんだろうな
リュードで
見るかみたいな話
この要素を取ってきてっていうのを
そのスクレーピングのレベルだったら
かなり宣言的じゃなくて
そのhowを指定してるけど
それを突き詰めると
どうやって取ってくるか
そのドムをどうやって探索して取ってくるかっていうのは
そのライブラリーの中に
隠ぺいされたりするんで
そのリュードで見たらそうだけど
もっとなんだろう
上のレイヤーとか
例えばSQLとプログラミングの例も
SQLで何が欲しいか記述するだけ
っていうそこのレイヤーで見たら
SQLは宣言的だし
もう一つのプログラミング取ってくるっていうのは
手続き的だけど
プログラミングの方も
まずこのファイルを開いてみたいな感じで書き始めるんですけど
そのファイルをどうやって開くかどうかって
結局OSに任されてるんで
そこのファイルを開くHowは
OSに任せるっていう風な感じになってるんで
そこは別に
完全になってるかって言われると
そうじゃないんで
突き詰めていくと
そうですね
そうですね
LLMの宣言的アプローチ
手続きをしたいリュードに結構よるっていうか
別にめっちゃ分解したら
何かしらみんな宣言してるとか
あるいは手続きをしてるというものがあるが
ちょっと塩梅なんだなっていう
ところまでしか分かりません
どこまでのリュードで言ったら宣言的なのかみたいなのは
多分前提の知識がないと分かんない気がしました
厳密なものはないと思います
みんながじゃあこれは宣言的なリュードだなって思えば宣言的なんだ
そうですねここの間隔はプログラミングやってないと難しいかもしれない
なるほど
スクレーピングの例はめっちゃ手続き的やなと思ったけど
そうではないんだ
でもプログラミングやってる人が手続き的なんだって言ってるから
手続き的なんだと思うんですけど
割とここ取ってきてみたいなのが魔法的な
第2回目敗北しました
難しいっていうか
多分これを聞いてプログラマーの人はなんでミチューだこれが分かんないんだって
思ってると思います
前提自分も多分手続き的なコードを書いてから
望んだらおおってなったと
多分1回手続き的な辛さを体験して
手続き的実習が
ジェイクエリーやってからリアクトやるとおおいいねボタン
そうなんだ
はい
なんで今回の分かった度間隔は30%ぐらいです
まじか
ミチューだが敗北します
なんで
宣言的に確認
宣言的な違う手続き的に書く言語って
でいい感じのやつってもうないんですか
言語では堂々でも書けますよ
自分がどういうアプローチで挑むか
難しいことを言いますね
なんでその例えばプロゲートとかで
ザ手続き的なやつをやってからリアクトを書いたらめちゃおおってなるのかな
確かにちょっと何か見てみよう
何かいいやつないか探しておきます
ありがとうございます
私は去年全部やったのに全部忘れちゃった
なのでちょっとこの回を聞いて
一加減ある人はお便りを
そうですね私フロントエンド詳しくないから
確かに
結構間違ってる動画あるかも
フロントエンド詳しいニキニキ言ったらお便りをください
感想質問フィードバックは
Xのハッシュタグマヂカル.fm全部小文字
または概要欄のタイトルフォームまでお寄せください
Spotifyのベルマークを押すと
更新通知が届きますのでそちらもお願いします
ありがとうございます
ありがとうございました
