  |
はてなキーワード: 手続き型言語とは
なり方、スクールの是非や費用、未経験エンジニアの年収、将来性とかばっかりググってない？
コード書いてみた？
今からググって、標準のメモ帳とかテキストエディタ使って、コーディング初体験するまで五分もかからないよ？
自分語りになるが俺は1970年に生まれ、中学時代にジャンクショップを巡ってMSXパソコンを組み立て、雑誌の手続き型言語を写経しては書き換え写経しては書き換え、ゲームを作り自作基盤でカートリッジ化しては界隈で知り合ったオタクと交換し合っていた。その後MS-DOS搭載のIBM-PCを手に入れてからも、まずは動かしてみることから始まった。電通大の講義で学んだことより、図書館の論文やオタク仲間とのやり取りで学んだことの方が大きい。
とりあえずコーディングしてみようよ。書き換えてみようよ。電卓でも作ってみようよ。シンプルな電卓ができたら機能を追加してみれば良いし、サンプルコードを色々書き換えてみれば良い。プログラマやエンジニアへの一歩目はスクールに対する評価や是非を見ることじゃない。
別に職歴の有無、大卒かどうか、文系理系かどうか、専攻が情報系だったかなんて関係ない。コンピュータサイエンス至上主義者が現れたらジョン・カーマックの名前を出してやれ。間違ってもスティーブ・ジョブズの名前なんて出すなよ。計算機科学の素養なんて歩き始めた時点ではない方が良かったりする。手を動かしてコーディングやエンジニアリングに取り組んでれば、その内嫌でも複雑性やアルゴリズムなど計算理論に関する書籍を漁ることになるはず。
さあ！コードを書け！
（私は入門書（象の絵のやつ）を読んだことがあるだけで、使ったことはまだありません。）
で、関数型言語の良さをアピールするひとからは、いい意味でのの宗教性というか敬虔さを
私は感じるんですよね。
本題。「関数型プログラミングが『銀の弾丸』である という非常識な常識 2022」 と題された長い文章をみつけました。
ここ。https://kentutorialbook.github.io/functionalprogramming2022
まるで熱心な信者による経典なので、ほとんどちゃんと読んでないし読む気も起きませんが、
流し読みをしていて、目に入った 次の一節 がとても私の心に刺さりました。
ーー我々が暮らしている「現実世界」はミュータブル（mutable）なのです。
を撤回させていただいて、
( https://kentutorialbook.github.io/functionalprogramming2022/#n0.19337518569281165 )
ちなみに、ミュータブルは「可変」、 イミュータブルは「不変」の意味。
まあ私も世俗的なSEをやってるので、まっさきに、↓くらいのことは、思うわけです。
多分、プログラミングの世界での、世間一般の反応も似たようなものかと。
ところがですね。
ところがですね。これ、意見戦わせても、たぶん議論でどうにもならず、宗教間の対立みたいなものになる気がするんですね。
というのも。上の文章でとりあげられている数学やら物理やらというのは、おそらくレトリックでしかなくて。
そのレトリックで、伝えられようとしているものは何かというと、
ビジネスの世界だろうが何だろうが、本来、世界は不変なものとして記述されるべき」
なぜなら、私が隠し持っている信念が、まさにそれに近しいものだからです。
物理学の法則が成り立たとうが、物理学の通じないアナーキーな世界であろうが
世界は不変であり、私自身による世界への介入なぞありえない、と直観的に思っています。
だから 「やればできる」 「世界は変えられる」 「努力は裏切らない」 みたいな言葉は大嫌いなわけです。
この直観を私は自分で勝手に、「離人症的世界観」と名付けています。
この世界観の持ち主は多分少数派で、社会から見れば異端どころか、害悪とみなされるかも。だから、隠し持っている。
関数型言語が好きな人も、おそらく私が似た直観と似たものを隠し持っているのでは、と、
私は思うのですね。
もし、離人症的世界観に基づくコミュニケーションが社会に浸透し、
「自分の意志や感情」すら、あたかもファーストクラスオブジェクトとしての関数のように、
客観的に表明されるようなコミュニケーションが、もしこの世の中に広まれば
そうでもならないと、関数型言語は流行らないだろうな。というのが私の予想。
ま、宗教てものは、広まるときは、あっと言う間らしいですから。
ひょっとしたら20年後くらいには、手続き型言語が滅びているかも。こればっかりは分かりませんけどね。
以上！
1についてだけ。
＞分かるけれどこれでどうやって動画や音楽のエンコードをしたり画像処理をしたりするソフトウェアになるのか
エンコードに関してはプログラムはエンコードの理論に従って作られているだけ。大事なのは研究者の考えた理論
画像処理は定型の処理の塊でこれも代替やり方は決まってる。"python 画像処理"とかでググれば多分出てくる
＞あるいはWordとかExcelとかがどうやってこんなので作られているのかが分からない
まず基本的な、ウィンドウシステムがどのように実現されているかをWin32アプリベースでも
よいので理解するべき。ユーザーのマウス操作、キーボード操作をどのようにプログラムが認識し、
処理するかが理解できる。この仕組みは基本的にすべてのアプリで共通と思われ。
＞プログラミング入門書を読んでも、一般的に知られているソフトウェアの作り方みたいな事が書いてない
多くの人が共通的な作り方に挑み敗れているわけで、プログラムは10個あれば10通りの作り方がある。
また、クラスレベルで抽象化してソフトウェア構造を整理しようとする、オブジェクト指向(最近は
クリーンアーキテクチャに昇華させる流れもあり)もあるけれど、オブジェクト指向に向かない
対象領域があったり、なんでもクラス病にかかる等して、銀の弾丸とは言い難い。
また自説だが、順次処理を基本とする、手続き型言語はデータと処理が入り乱れることになるため、
全てを設定しきることが極めて困難なため、きれいにすべてを設計するのであれば関数型言語を使う必要が
あると感じている。
＞だからそのフレームワークがどういう風になっているのかって説明からして欲しいって思う。
そのフレームワークが内包するベストプラクティスの量を鑑みれば、中身を意識せずに
＞つまり言いたいことは、実際に動くアプリケーションというのを作りたいのにも関わらず
＞プログラミング入門書は、これで判定と繰り返しという基礎ができますと言うだけ。
＞これがもう滅茶苦茶イライラする。
天才的な人はコードを書きながら、考えられるけれど、常人はまず詳細設計と言われる
フローチャートを書けるようになったほうがよい。
次に"抽象化"を覚える。"抽象化"を使うことで少なくとも、処理は全体をざっくり設計できる
＞つまり完成しているプログラムを参考にしようと思っているにも関わらずそれがないのでよく分からない。
githubに山のように転がっている。
ただそれを見て理解できるかは別問題。モチベーションを保って継続学習可能な形に
消化できる人間の登場が待たれる
何かの参考とかにしたらダメです。書き始めて半年経つんだけどこっからどう直したらいいんだか（何をゴールにしたらいいのか）わからない。。
追記：合流性とか強正規化可能性とか停止性とか、全部チューリング不完全で、事前の静的解析で使うメモリの最大量が確定できる、とかそういう風に読み替えられる人を増やしたいのです、数式の添え字とΣと∫にびびらない人を増やしたいようなもので
数理論理学の一分野である証明論から成長した、数理論理学と理論計算機科学の境界領域の研究領域である型理論(type theory)は、大規模なプログラムの内的な整合性のチェックを行うための方法論を必要とする情報処理技術の分野で関心を集めている。
そもそも「型」(type)とは何か。プログラミング言語は一般的にはレコードや関数といったプログラムを構成する「値」(value)の定義をする道具である(*1)。その言語のコンパイラ作成者はこれらレコードや関数などの値、もしくは第一級の対象(first-class object)の種類を区別する型システム(type system)を必要とする。抽象代数学の観点からすると、「型」とはこれらの値もしくは第一級の対象が属する高階の対象(higher order object)としての空間(space)ないし代数系(algebraic system)で、型システムはそれら「型」とそれら相互の関係(relation)つまり型のなす順序構造(order structure)ないし束構造(lattice structrure)であるといえる。
プログラムを構成する値すべてに型が付くためには、曖昧でない(*2)こと、自己矛盾していないこと、悪循環を含まないこと、それぞれの値の内容をチェックするために無限の時間を要しない(*3)ことなどが必要で、これらを満たすなら、プログラムは有限時間で実行を終え、停止する。手続き型言語では無限ループ、型無しラムダ計算では無限再帰によって型付け不能なプログラムを書くことができるが、型理論はこれらのチューリング完全な計算機を意図しない停止しないプログラムから守る装甲でもあり、再帰やメモリ確保で好き勝手をさせないための拘束具でもある。型が付くプログラムには単に停止するというだけでなく、可能な実行経路（訂正：経路→方法）のすべてで同じ結果を出すなど種々の良い性質がある。
1)この定義は現実に使われているプログラミング言語の特徴を覆い切れていない、狭い不満足な定義だが本稿では都合上この定義に立脚して限定的に議論する。例えば変数(variable)というものを持つプログラミング言語もあり広く使われているが、これについてはレコードや関数と同じように性質の良いものとして扱うことが難しい。難しさの原因は次の注の内容と関連する。近年は変数を扱うかわりに値の不変のコピー(immutable copy)やその参照に名前を付ける機能を持つプログラミング言語が増えている。
2) 現実の情報システムでは、COBOL言語のレコード再定義やC言語の共用体、一般的な関数ポインタやVisual Basic言語のvariant型変数のように、同一領域に異なる型の値が共存する共用型(union type)の値がしばしば必要となる。共用型の値はgoto文を排除した構造化／オブジェクト指向プログラミングにおいて条件キャストやクラス分岐などによる実行経路の複雑さの主要な原因になるが、これは和型(sum type)すなわち相異なる型の非交和(disjoint sum)として定義することで曖昧さなく定義できる。
3) ゲームプログラムやネットワークサービスにおいてしばしばみられるように、入力として無限リストや任意に深い木のようなものを想定する場合には明らかに（条件を満たさない限り）停止しないことが正しい動作となり、この場合は最外周のループを（←どうする？）メモリリークを起こさないなど別の考慮が必要となる。
Javaはやめとけ、ってのは同意。だけど、Javaも手続き型言語だぞ、と訂正は付け加えておくとく。
プログラマじゃないけどプログラミング完全に理解した（）おばさんが理解してる基礎知識書くよ。
（追記 この文章はプログラミングの勉強をしたいけどその周辺にある基礎知識になかなか触れる機会がない人向けに書きました。これらの基礎知識があると、困ったときに調べ方すら分からないという状況は回避しやすくなるはず）
ターミナル、いわゆる黒い窓からCUI（コマンドユーザーインターフェース）でコンピュータを使う方法を覚えよう。これは大学のコンピュータリテラシーで習った。MacOSXで復習すると捗った。（追記 すごく間が抜けてたけどMacOSXはUnix系OSです）
まずはファイル操作。Macでターミナルを使って、cd Desktopって打ってからecho ohayou ＞ aisatsu.txtって打ってみて、cat aisatsu.txtってやる。そうすると何が表示されるのか？とりあえずやってみよう。ここで＞は増田の都合上大文字全角にしてるけど、ちゃんと半角にしてね。なんで増田の都合上半角がダメなのか、そのうち想像できるようになろう。（追記 ブコメ指摘感謝）
そして、実際にデスクトップを見に行ってみると、aisatsu.txtってファイルがあるはずなんで、開いてみよう。これで何が起こったのか７割くらいはわかるはず。
こういうファイル操作の基本をまず覚えよう。これこそ空気みたいなものだから。
（追記 ここも間が抜けてたけど確かにhogeって何かわからないね。直しました）
最近は何も考えなければ文字コードはとりあえずUTF-8でなんとでもなるようになってるけど、バックスラッシュとかは環境設定で出てくるように設定しないと出てこないし、その意味合い、つまりエスケープとしての使い方を頭に入れておくと後々困らないと思う。あとEOF（エンドオブファイル）とか改行コードとかもそういうものがあるよ程度には覚えておこう。これ頭の片隅にはいってないと分からん殺し的な罠にはまることがある。
これは使いたいプログラミング言語の公式サイトに行くと大抵書いてある。
でもMacだとだいぶ楽。とりあえずターミナルからgccって打ってみるとなんかCUIツールとか書いてあるものをインストールしろって言われるのでインストールする。これだけでCとかC++とかRubyとかPythonとか一通り使えるようになる。もしかしたら最近はこのインストールすらいらないかもしれないけど。
あと、シェルのコマンドとかプログラミング言語を実際に使うときはいろんなライブラリをインストールする必要があるけど、そのライブラリは管理がすごく面倒なので管理をまとめてくれるコマンドがあったりする。aptとかhomebrewとかがそういうのだから、そんなものの使い方も覚えておこう。
（追記 言語の文法を追うだけなら環境構築なんてしなくてCloud9とか使ってもいいかもだけど、プロダクトを作ろうとした時にはまだまだ手元で環境作って必要なライブラリを入れてとやった方が後々応用がきくと思うのですよ。それにそうしていくとDockerの有り難みなんかも理解できるようになっていくのではと思います）
最初に勉強するプログラミング言語は、Javaだけはやめておけ。
なんでかっていうと、Javaはオブジェクト指向言語ってやつなんだけどオブジェクト指向的にしか書けないから。古い人間だと言われそうだけど、最初は手続き型言語から始めるべきだと思ってる。少なくとも、手続き型的に書ける言語から始めるべき。
なぜそう思うのかも含めて、とりあえずおばさんが理解しているプログラミング言語の発展の経緯を軽く解説する。
最初の頃のプログラミング言語は、手続き型と呼ばれるものが多かった。
この〇〇型ってのはプログラミングをするときの考え方によって名前がついているんだけど、手続き型はまず0を作って、0に1を100回足して、最後にその結果を表示してください、みたいな、上から書いた順番通りに動くのが基本のルールである考え方。プログラムは基本的にはこうやってデータをアルゴリズムを使って変化させていって望む結果を得ている。でもこのやり方は問題も多かった。プログラム全体がひとかたまりになってしまっているので、数千行とかになるともう普通の人では手がつけられないし、人間のミスでデータを間違って扱ってしまうことがバグの温床になった。
なので、この手続き型の考えに構造化という考えが加わって、関数というものが生まれた。関数っていうのは料理のレシピに例えるとわかりやすいかも。
5:豚こまを入れて色が変わるまで炒めます。
9:火を消して8をお皿に盛り、野菜炒めの出来上がりです。
B:肉に味付けをします。
2:Bを入れて色が変わるまで炒めます。
3:Aを入れてしんなりするまで炒めます。
4:火を消して3をお皿に盛り、野菜炒めの出来上がりです。
って書ける。ここではAとBが関数。
この程度だとあまり意味を感じないかもしれないけど、これがもっと複雑なものを想像してみると、なんとなくありがたみが分かって来ないだろうか？こうすると、多人数でプログラミングをするときに、Aを書く人、Bを書く人、1〜4にまとめる人って感じで作業分担ができる。それに、バグが起きた時もAの領域でバグったのか、Bの領域でバグったのかとか、全体にまとめると上手くいかないのかとか、原因の切り分けがしやすい。
でも、プログラムがとっても複雑化すると、これでも手に負えなくなる。料理の例えを拡大すると、料理店を運営することを考えるといいかも。
料理店でたくさんの料理をさばくときに、レシピを完全に1から作ることってないと思う。Aさんが野菜の仕込み担当、Bさんがスープの仕込み担当、というように各人に仕事が割り振られているはず。AさんもBさんもそれぞれの仕込みのレシピを持っていて、最終的に出てくる仕込みがちゃんとしてればAさんBさんの仕事の詳細までいちいちシェフが細かくチェックしない体制になっていると思う。大雑把にいうとそういう考え方をプログラムで再現したのがオブジェクト指向型言語。
なので、本気で料理の初心者がいきなり厨房の仕切りを任されて上手くいくのは難しいように、構造化プログラミングのありがたみすらわからない段階でオブジェクト指向型プログラミングに手をつけても意味がわからんだろうと思うのがおばさんの立場です。
（追記 おばさんはRubyを勧めておきます。オブジェクト指向型言語ですが、手続き型的に書き下すことも出来るからです。一つの言語で手続き型構造化オブジェクト指向、全部勉強できます。メソッドも便利なのが一通りあるし、日本語を扱うのにも問題が少ないです）
次に問題を分解できるようになろう。
例えば、クイズゲームを作りたいと考えたときにクイズゲームを作りたいです、って問題は大きすぎる。
クイズゲームに必要な要素は、問題文を表示する、回答を入力してもらう、正誤判定をする、正誤判定の結果を表示する、ということだなぐらいにまず分解する。
これを実際にプログラミングしようとすると、もっと分解できてさらに問題が見えてくると思う。
コンピュータってのは創造的なことはできない代わりに、とても簡単なことをとても階層的に重ね合わせて大きな問題を解けるように作られてる。それを心するといいと思う。
これ超大事。プログラミングって本当に自分で1からものを考えなきゃいけないことってあまりない。大きな問題はあなただけの問題かもしれないけれど、それを構成する小さな問題は大抵他の誰かが解いている問題なので、調べてみれば答えが見つかると思う。
エラーメッセージが出てきたらまずググってみる。翻訳しても初心者には意味がわからないし、ググったら誰かが解説付きで紹介してくれているのでその解説を読んだりしながらエラーメッセージとの付き合い方を覚えていけばいい。
メソッドの使い方がわからなかったら言語の公式サイトに行ってみる。メソッドの使い方で大事なのは呼び出し方、返ってくる値の型とかそういうのだから、こういうところはググるよりも公式サイトに書いてあることをしっかり読んで理解する。
あと、アルゴリズムの勉強もしてみるといいと思う。アルゴリズムとデータ構造と計算量の勉強。大学の学部レベルの教科書をちゃんと読んでみると、例えばデータベースを操作するSQLというものを書くことになった時とかに効いてくる。あとは作ったプログラムが遅すぎてどうしようとかいうのを解決する時とか。
なんか深夜までいろいろ書いてしまったけど、あくまでもプログラマじゃないおばさんが書いたものなので、みんなでツッコミとか入れてくれると大変助かります。
日本のPG/SEの60万人のうち、オブジェクト指向らしいコードを書けるのは1割以下だと思うわ。
もっと少ないかも。
オブジェクト指向言語やオブジェクト指向のフレームワークを使っていても、クラスにどんどんメソッドやメンバ変数を追加していって、クラスの中で手続き型言語風にコーディングしてるだけだし。
まだ手続き型で、ちゃんと構造化プログラミングしてればいいけど、一個のクラスにやたらとメンバ変数を作って、各メソッドから適当にアクセスしてるから、手続き型言語でグローバル変数を多用したようなコードが量産されてるし。
普通の人間には手続き型で「サブルーチンを使いなさい」「グローバル変数は多様しないように」と教育するくらいが限界だと思われ。それでも対応できるのは何割かしらんけど。
何か関数型言語しか触れてない新卒が手続き型言語を見て意味がわからないから手続き型言語辞めてもいいかみたいなツイートがやたらRTされてるんだけど、これって日本語知らない外国人にスラング教えて、それを言わせて盛り上がってるみたいな感じに見えて面白く感じないんだよね。
どちらの言語にもメリットがあって、片方しか知らないんだからそう答えるだろ普通って。
でも散々今までイジメられてた、リア充爆発しろとか言うくせに公開リポジトリ漁ってセキュリティがいけてないリポジトリを晒してみたりとか、それってイジメじゃん？ってこと時々やるよなあいつらって。
何なんだろうね。
真面目なこと言ってごめんな。
何か関数型言語しか触れてない新卒が手続き型言語を見て意味がわからないから手続き型言語辞めてもいいかみたいなツイートがやたらRTされてるんだけど、これって日本語知らない外国人にスラング教えて、それを言わせて盛り上がってるみたいな感じに見えて面白く感じないんだよね。
どちらの言語にもメリットがあって、片方しか知らないんだからそう答えるだろ普通って。
でも散々今までイジメられてた、リア充爆発しろとか言うくせに公開リポジトリ漁ってセキュリティがいけてないリポジトリを晒してみたりとか、それってイジメじゃん？ってこと時々やるよなあいつらって。
何なんだろうね。
真面目なこと言ってごめんな。
