【C？】最初の言語に何を選ぶか【Haskell？】
■ このスレッドは過去ログ倉庫に格納されています
初期学習コストが高い言語を最初に学ぶというのは如何なものか すべての機能を一気に学ぶのではなく
段階的に学べば大丈夫? >>1
それならベストな選択はRustです
RustはHaskellの型システムやモナドを取り入れたプログラミング言語です
そしてRustはメモリ安全性が保証されてGCも無くモダンな書き方で便利にプログラミングできるC言語の超越進化版でもあります 1.機械語
2.FORTH
3.LISP
4.C
この順がベスト 1000 名前:デフォルトの名無しさん [sage] :2021/09/09(木) 18:41:37.72 ID:wE7qph1K
ぶっちゃけ始めるのにいい言語って言ってんのに、CだのRustだのHaskellだのってバッカじゃねぇのおっさんども
お前らの好みなんか聞いてない。
こんなクソスレはもういらん
初学者はPython、Javascript、Ruby、PHPの中から選べばいい。 >>7
その中から一つ選ぶならばJavaScriptかな
ウェブがらみは当然JavaScript必須であるし
スマホアプリやデスクトップアプリもJavaScriptだけでプログラミング可能 >>4
Tarai 関数を Haskell で書いた例が、
前スレで紹介されている。 >>3
それは、前の世代である我々に訊かれても返答に困る。
「いま」の世間に生きているあなたがたとは、
生きていた時代が違うのだから。 >>6
言いたいことはよくわかるような気はするのだが、
> 1.機械語
の部分はニモニックなのかアセンブラなのかという
話はある。
Z80 とか M6809 とかのエミュレータがあったら
ちょっとお奨めな気はするんだが、
C 言語の「コンパイラ言語→アセンブラ→バイナリ」という
コンセプトに立ち戻ってみるのもよさそうに思う。 まず仮想機械を実装して、
それ用のアセンブラを開発して、
コンパイラを書くというのはどうだろうか。
その仮想機械には、少なくとも
・フラグ
・アキュムレータ
・B レジスタ
・プログラムカウンタ
・スタックポインタ
があるとして、フラグには
・キャリー
・ボロー
・オーバーフロー
・エラー
があって、
メモリ空間は 64Kb。
で、それぞれの（フラグ以外の）レジスタのサイズは
16 ビットで、戻り値は 16 ビット固定でアキュムレータに
入っている、みたいな（ANSI-C になる前の）C 言語みたいな
教育用言語があったら面白そうな気がする。 >>7
Rust は Forth の焼き直しだし、
Haskell は LISP の焼き直し。
C や C++ はアセンブラの焼き直し。
「温故知新」という言葉を思いだしてほしい。 >>13
RustにForth言語の要素は一切ない
その分類ならばRustのベースはC言語
そこへHaskellの型システムなどを持ち込み強力な静的型付けとするとともに
静的リソース管理によりメモリ安全性を保証したのがRust言語 >>14
> RustにForth言語の要素は一切ない
「とりあえずスタックに積んどけばスタックポインタを
書きかえれば面倒臭くない」という思想が
FORTH っぽいように思うのだけれど気のせいか？ >「とりあえずスタックに積んどけばスタックポインタを
>書きかえれば面倒臭くない」という思想が
どこがRustと関係あると？ >>15
その点はCもC++もRustも全て同じ
いずれもスタック上に確保される変数(領域)は関数呼び出しが終わってスタックが解放される時に消えて使えなくなる >>18
すまん日本語略しすぎてたｗ
以下へ訂正
関数呼び出しが終わって
スタックポインタを元に戻す時すなわち
スタック上の領域が解放される時までに
消えて自動的に使えなくなる >>20
日本語難しいな
スタックポインタを戻すことを「スタック上で領域を解放」と呼んでよいと思う
なぜなら最初にスタックポインタ変更することで「スタック上で領域を確保」と呼ぶのだからその対義語 クレート？ていうかライブラリのコード規約で選ぶのはどうだろう。
最初なんだから、あんまスペルを省略されると判りにくい。
慣れると冗長で面倒になるかも知れないけど。 最初はCじゃないか？
メモリの扱いが見えるようになってると、メモリの扱いが隠されてる言語でも良いプログラムが書けるようになる >>25
スタックポインタの復帰にpopを使う方法もありだが
例えばメジャーな86系でメジャーなやり方なら別レジスタに退避させるのがメジャーな方法なのでmovになる
他にも完全にコントロールできるならスタックポインタの数値加算(スタックが0方向に伸びる場合)で復帰もあり
いずれにせよスタック上にローカル変数などの領域確保はスタックポインタの数値減算(同上)で行うのがメジャー
そしてスタック上のその領域の解放はスタックポインタの復帰(上述)で終わる 説明に必要な抽象度を調節できない人ってプログラマーに向いてないよね スタック上で関数ローカル変数の領域は
・スタックを伸ばして領域を確保
・スタックを戻して領域を解放
極めてシンプル つまりまず最初にC言語をやるべきだな。
次にアセンブリ言語というよりCPUの共通的な概要仕組み。
そのあとHaskellかRustなどの強力な静的型付けプログラミング言語へ進むのが良いだろう。 じじぃが最期の言語に何を選ぶか
にしたら
どうしようもない耄碌ばかりだ >>26
SP復帰はLEAVE命令だろ
と思った俺は古過ぎるのか 1.Python
2.Haskell or Go
3.Rust or やりたいことに応じてjsとか
これやろ >>33
Pythonみたいなクソ言語はありえない
残りの4つはアリ 関数型が全然わからない
ocamlやhaskell触ってみたけど手も足もでなかった
あれってすべて適用した引数ベータ展開しながら簡約していった結果をコーディング中に頭の中でシミュレーションしていかないと書けない代物なのか？
それじゃあワイできないよ
後型システムの振る舞いがなんにもわからないわ
あれってocamlは型推論あるけど型が明示的に表記されない代わりは自分自身で頭の中に型付け規則を当てはめながら追っていくしかないんか？
それじゃあワイできないよ
以上のような理由からワイは例えばfixという不動点コンビネータの高階関数とかわからなかった
とにかく自分にはお手上げやわ >>35
Haskellの型クラスやモナドを採り入れつつCと同じ手続き型言語のRustからまずは入ってみたらどうでしょうか？
Rustのコンパイラは賢くフレンドリーなので型のミスも細かく教えてくれます >>36
rustは式指向って言ってもラムダ計算ではないのでそっちはかろうじて理解できます
理解できないのはラムダ計算ベースの関数型です >>26
pop というのは機械語（ニモニック）レベルではなかったような。
sp（スタックポインタ）から sub するか（できるのか？）、
sp の値をアキュムレータに持ってきて sub して書き戻すか
（フラグの中身が変わったり、アキュムレータの中身を堆肥させたり
ちょっと面倒臭そうだ）、
小さい言語処理系を開発するときは、FORTH のインタプリタを実装して
その上にコンパイラを被せるとかいうのは二度ほどやったことがある。
「Make 10」パズルの全数解を求める、とかいった場合だと、
けっきょくそれをやるのが素朴だと思う。 関数型とかラムダ計算とかいっても、
遅延評価がないと実行効率がそんなに上がらないんだよね。
「これ、前にやったことがある」「だから、前にやった結果を
そのまんま使おう」というのが遅延評価なのだけれど、うーんと
末端のほうだと、「前にやったことがあるんだっけ？」という
探索に時間がかかっちゃうので、探索効率と組合せ論的な爆発の間の
トレードオフになっちゃうので、手続き型と関数型のどっちを
選ぶかというのは、ある程度実効機序が解ってないと難しいんだよね。
そういう意味では C 言語とか FORTH とかいった、コンピュータ・
アーキテクチャべったりの言語から始めたり、古いタイプの高級言語から
入るのもひとつのやりかただと思う。
そういう意味では Java とか C♯とかは、プロ用には向いてるけど
基礎を知らないと難しいかも。
昨今は F1 のトランスミッションもオートマチックだそうだしなぁ。
昔のマニュアル車やゴーカートから始めてみるのもいいんじゃない？ マニュアル車は、
少し低めのスピードで高速ギアにしたり、エンジンブレーキかけたりできるからね。
渋滞時だけは、面倒。
少し加速して、すぐニュートラル。
ようするに、燃費をいかに少なくするか？なのだけど。 スポットから始める、練習から始める、ってことかな？ >>38
嶋正利さんが設計したインテル8080からスタック操作のpush/pop命令はずっとあるよ
もちろんZ80でも86系でも同様
実はアセンブラ使ったことないの？ >>42
昔、『I/O』の附録だった、Z80 とか 6809 のお経本
（インストラクション・セット・サマリ）とか久しく
見てないからなぁ。
push とか pop とかの引数をどこから取ってくるのか、
といったところまでは思い出せない。 >>44
引数ってなんだ？？
当時のpush/pop (6809だとpush/pull)は
レジスタをスタックへ退避と復帰のみだぞ >>42
68000からアセンブラやり始めたとかかもw sp をインクリメント／デクリメントするだけで１命令なのか …
それは大変だな。 >>34
じゃあ
1.Go
2.Haskell
3.Rust or やりたいことに応じてPython, js, C# >>44
I/Oとかクソ懐かしいな30年以上ぶりに聞いたわ
高校の時にZ80やった
ちなみにオススメはプロでやりたいならJavaかJSかC#
言語マニアの話とか聞いてもマニアになりたいんじゃない限り意味ないぞw >>51
オートマだとドライブ一直線だが、
神岡ターンではクリッピングポイントをクリアしてから
「一瞬、ギアをリアに入れる」というとかいったコトをやっている。
C 言語でも、C のコンパイラが吐いたアセンブラのコードを見て、
「ここはステート数が縮められる」みたいなマッドな野郎どもが
昔はいたんだよ。
そういう言語マニアにとっては C 言語なノスタルジックな言語では
あるんだけれども、C++ というのは、マネージャーとかいった
そのあたりの美学を理解しない連中が権勢を揮っているので、
「いい言語」と言っていいとは思わない。 >>54
> Javaでプロωとかωω
> 土方まっしぐらωωω
あんた病んでるよ。
だけど反社会性パーソナリティ障害障害って、
治療法がないんだよね。
最近の精神科のクリニックは薬物療法が主なので、
カウンセリングはあんまり主流じゃないから期待しないほうがいい。
松沢病院とか受診してみれば？ >>53
「I/O」は今でも書店に並んでるぞ？
「らんだむ・あくせす・でぃくしょなりぃ」とか懐かしいな。
宮永さんが、ナショナル・セミコンダクタ（通称ナショセミ。
以下 NS）の「SC/MP」（通称「スキャンプ」）の２が出たときに、
煙草の箱サイズの自作パソコンを作って製作記事で紹介していたのだけれど、
「入力はスイッチ一つでいいんだけれど、タイミングを取るのが
大変だからスイッチを二つに増やした」「出力は、ラインを触って
ビリッときたら 1 で、こなかったら 0 だと思ったけど、涙を呑んで
電球をつけた」（当時は LED は一般的ではなく、出力は 5.5 ボルト
だったので電球もついた）とかいう生々しいレポートがあった。
あのころは楽しかったなぁ。
> ちなみにオススメはプロでやりたいならJavaかJSかC#
> 言語マニアの話とか聞いてもマニアになりたいんじゃない限り意味ないぞw
なるほど。マニアになりたい奴には意味があるし、開発の現場では
言語マニアにも居場所があったりする可能性は認めてもらえるんだよな？ >>49
そういえば、オペコード（オペレーション・コード）って言葉を
久しく聞いていないな。
いまどきアセンブラとかやってる奴がいないせいだろうか。 ネイテイブコードでかかれたゲームクライアントが少なくなったせい？
ゲーム解析でアセンブラとかOSの動作を覚えたｗ >>60
それはフロッピーディスクのコピープロテクトが
一般的でなくなったからだと思う。
あの頃の激戦区は、（参戦はしなかったけど）
楽しかった記憶がある。 >>58
まだ売ってるのか良くもったな
例えばJavaの現場でHaskellとかできてもどうにもならないが趣味でマニアな分には
その場合Javaさえできるなら当然問題はない
ただそういう人は変な事する場合があるから言語以外の普通の開発手法とかデザインパターンとかはちゃんとしてね このスレで書き込みしている人達ってやっぱ平均年齢50超えてる？ やっぱなんだかんだ言ってもCが1番
ダイテル本みっちりやればよろし >>63
> このスレで書き込みしている人達ってやっぱ平均年齢50超えてる？
よくわからんが三十代か六十代の、いわゆるスキマ世代が多いんじゃないかな？
読んでるひとは十代とかだったりしそうだけど、
おっさん世代の愚痴やら説教やらを聞いてくれるヒトがいるというのは、
喜ばしいことだと思う。 高級言語から始めてもいずれ「ポインタって何に使うの？」って絶対に聞くんだから最初からアセンブリやっとけよ
つまんない意地はんなや >>67
「C プログラミング初心者あるある」だな。
「値呼び」とか「番地呼び」とか「名前呼び」とか
文字列を含む可変長データの管理とかで悩んだときに
アセンブラにまで立ち戻って考えると確かに理解しやすい。
クヌスの「コンピュータ・プログラミングの技法」とかは
手がかりになりそうだ。 習得順序がBASIC→アセンブリ→Cであった頃は何の問題もなかった
最初の言語はコンピュータの仕組みや計算機科学べったりでない方がよい
そんなのは2つ目以降で考えればよいこと >>69
> 習得順序がBASIC→アセンブリ→Cであった頃は何の問題もなかった
> 最初の言語はコンピュータの仕組みや計算機科学べったりでない方がよい
> そんなのは2つ目以降で考えればよいこと
その点については全面的に同意する。
たぶん三十代の遣える方だと思う。
ただ、Pascal の P-System とか、
BCPL とかいった「仮想マシンのアセンブラ」とかいった
いったコンパイラ言語を経験している若者が少ないんだよね。
「コンパイラ → マクロアセンブラ → アセンブラ → 機械語」
とかいった経験を積まないと、システム屋としては未熟だと思う。
そういった経験を積んだ人にとっては、「イマドキの若者」っていうのは
腹立たしいとは思うんだけど、そこは生温かく見守ってあげようよ。 >>69
多分高級言語こそ全てのプログラミングの基本であり真髄みたいに考えてるんだろうけど逆だよ
そもそもプログラミングってコンピューター使わなくてもできるからな？ >>71
コンピュータ使わずにできるプログラミングとBASICは似てるって主張ではないのかな？
つまり、Cやアセンブリはコンピュータに相当忖度しなくちゃ動かないけど、BASICはアルゴリズムを記述したら動く、と。
ローカル変数ないじゃん、とか、構造化プログラミングできないじゃん、みたいのはBASICだと流石に出てきちゃうけど
ソフトウェアエンジニアでC書けない人は本物じゃないと思うけど、プログラミングはソフトウェアエンジニアだけのツールじゃないからねえ。 そのあたりは、REAL BASIC の開発者の意見もあるだろうと思う。
行列の積とかもフツーに計算できる機能もあったはずだ。
Ｆortran 77 じゃないけど、複素数演算もできたと思う。
つーても、演算子の拡張というのはあまり必要がなかったようで、
現在では使われていないようだ。 >>72
> ローカル変数ないじゃん、とか、構造化プログラミングできないじゃん、
> みたいのはBASICだと流石に出てきちゃうけど
だからこそ悪辣な面白いこともできる、というのは C と同様だぞ（笑）。
文字列領域にマシンコード突っこんで直接コールするとか、
グラフィック用のビットマップ領域を利用してプリンタ用のバッファに使うとか、
「今から三十年くらい昔にはよくやったもんだ（笑）」という話は
先達からいろいろ聞かされている。
昔の「I/O」とか「THE BASIC」とか読むと、その手の話はけっこう出ていると
思う。 >>71
初心者が真髄なんてものに触れる必要はないというのが論旨なのだが たとえば、無条件ジャンプ（いわゆる GOTO 文）と
条件ジャンプ（たとえば CALL文。BASIC では GOSUB）は、
番地フラグとして、同じ「ラベル」というのを指定できる。
そうすると、飛び先が同じでも GOTO なのか GOSUB なのかで
挙動が追いにくくなる。
BASIC ならまだしも高級言語だから追いやすいが、アセンブラで
これをやられると、本当にややこしくなる（実際に、追っかけているうちに
訳がわからんことになり、しかも途中でプログラムの自己書換えとかが入って
いて、「一ヶ月くらい悩んだ」という奴がいた。じつはタイマ割込みがセット
されていて、それは単なる「ゲームのイニシャルローダが発売されてから
解読されないための時間稼ぎ」でしかなかったのだが）。
これで「八人の女王」プログラムを書いて褒められたことがある。
C 言語やアセンブラだと、ROM に焼くのと RAM 上に置くのでは挙動が
違うので（ROM に焼くと自己書換えができないが、RAM 上では書換えができる）
とかいった より悪辣なことができるので、C やアセンブラはとても愉しい
言語だと思う。
だけど ANSI-C は牙を抜かれて飼いならされてしまったので、
「ANSI-C は家畜化されて牙を抜かれたブタであって、オリジナルの C は
猪だ」という意見はあったりもする。 業務で書く分にはわかりやすさ重視で凝ったアルゴリズムは敢えて使わないな
今や凝らなくても余裕があるし、メンテしようと自分で見返したときに思い出すのに時間がかかるし
詳細仕様とか文書を書き起こす方に時間がかかって大変だからｗ >>69
自分もこのルートだったけど、なんでもアセンブリとかメモリマップに落として考えるようになってしまい、その後クロージャとかコルーチンとか出てきたときにかえって分からなくなってしまった
いい年になってから計算機プログラミングの構造と解釈を読んでようやく前に進めた >>78
規模の大きいプロジェクトで、支援で突っ込まれると、かなり地獄です。
だいたい、『人月の神話』で「途中で人を突っこまれると余計に
プロジェクトの進行が遅れる」というのは常識のはずなんですけどね。
>>77 さんは『ソフトウェア作法』のほう（構造化）に向かっていて、
前に進めたあなたは（本来の意味での）システムエンジニアへの道が
拓（ひら）けた、ということではないでしょうか。
> いい年になってから
と仰（おっしゃ）いますが、三十五歳を過ぎてからが働き盛りですよ？ >>69
一理あるな。アセンブラはさすがに現代すっ飛ばすとして、VBAあたりから
入門して「これ、・・・・・駄目じゃない？」レベルまで行けたら
Cは仕組み知るには素晴らしいけどなんか組むには素朴すぎるし、C++は
増築繰り返して化け物化したWin3.1みたいだし、オブジェクト指向バリバリの
JAVAとC#は時代に遅れそうになって増築しすぎの兆しが見えるし…。
Rust？ >>80
漏れも同じことを考えたので禿同なのだが、
Rust は局所変数の扱いを文法で縛っているという
印象があるので、言語処理系（自然言語処理ではなく、
いわゆるインタプリタやコンパイラ）を「意識しない」
という方向性については いまひとつ疑問がある。
「うちらは幸せな時代に生きてきたんだなぁ」とか思ったりする。
マイクロプロセッサの黎明期に秋葉原をうろついていて、
p-code Pascal とかを体感してきたんだから。 >>81
私の世代の場合、まだ世間がNiftyとか言ってるあいだに大学でインターネット、emailに触れ、
Windows95が出た頃には自宅でBSD unixをPCで動かしてXWindow立ち上げてvi/emacsでプログラム書いてgccできたので、まぁ面白い時代だったです >>82
うらやましいな。
おれは unix には触ったことがないので、rogue もプレイしたことがない
（知らない人のためにひとこと。rogue のアクション操作はエディタ vi と
いっしょ）。
そういえば、パロディ判アスキーに、「UNI+」（ユニプラス）という
unix 風のシェルが載ってたな。 >>7
PHPはHTML必須なので進めない
javascriptはさほど汎用的でない（javascriptでないと使わない独特技法がある）
学習情報が整理されてるpythonかrubyがおすすめ
それらで基本構文などを習得してからweb行くならJS、PHP
アプリならjava-kotlinなど選べばいい >>83
職についちゃうとその業務で極めようとするからなかなか＞＜
今の人だとスマホで劇的な変化を体験したんだろうか
rogueというかSunOS/Solarisだとhack?
マシンごとにランキングが残るんだけど、誰もやってなかったｗ JUNETでUUCPでmailとnetnewsが来てfj.*を読み書きしてた頃か
インターネット接続になってそれら便利になるとともに多様化で消えていった uucpの頃がuuencode/uudecodeか
base64に飲み込まれたな もうおじいちゃん達の懐古主義はお腹いっぱい
昔を懐かしみたいのなら別スレ建てたら？ 当時似たような unix 風のシェルがあって、
「UNI十（ユニクロス）」とか「UNI×（ユニッペケ）」とかあったんだよ。
たしか当時はまだインターネットが普及してなくて、公衆回線を
使った草の根 BBS のころで、
うんと底のほうのルーチンで回線断されると、longjump で上の方に戻ろうと
するといろいろとトラブルが起きたんだ。
そんなわけで、キャッチ＆スローみたいなことをやろうというときに、OS で
コプロセスを起動するということを考えたひとがいて、それがシェルもどきに
なったという経緯があったりする。
知人の unix 使いが「Mimic」というシェルもどきを書いてたっけなぁ。
「mimic」とタイプすると、「It's Me!」と返してくる。
いや、おれは rogue やってないから知らないっつーの (^_^!)。
いまどきの若者は『ダンジョン飯』とか読んでいるので常識っぽい
らしいが。 >>93
数学だなあ。今モナドの説明読んで理解しようとしてるけど
頭がパンクしそうだ。
ただ、「圏論学ぶと人生観が変わるくらいものの見方が変わる」
らしいからなんとかそこまでたどり着きたいなあ。
最初の言語としては全くお勧めしないｗ
そもそも「他の言語を何か使えること」がほぼ前提の言語だし。 >>96
まぁ……数学がわかんなくても遅延評価がうまいこと
やってくれるので、運がよければ組合せ論的爆発を
避けることができる、というのが取り柄かな。
トランプや麻雀のプログラムとか、選挙の議席数によって
どれくらい影響力があるか（シャープレイ＝シュービック
指数という。単独過半数だと面白くもなんともないが、
二大政党の議席数が拮抗してて野党がキャスティング・ボウトを
握っていたりすると、いろいろ面白い結果が出たりする）とかの
話だと、Haskell は強力かもしれない。 C や C++ って、記述の粒度が細かすぎて
全体像が掴みにくいんだよな。
オブジェクト志向になると、モジュール化がしやすいから
全体構造はいくらか見えやすいんだが、こんどは
いろいろと制約っつーか縛りがきついので、C とかから入ったひとは
「これでホントにシステム組めるのか？」とか面喰ったりする。
何人くらいのチームで、どれくらい知識が共有できててスキルがあるのか、
とかいった観点から言語を選ぶのも、ひとつの選択だと思われる。 >>98
その点はJavaと全く同じ
Javaしかやったことないからそんな意味不明なことを言ってる
勉強しなさい >>98
> 「これでホントにシステム組めるのか？」とか面喰ったりする。
以前LavVIEWをちょこっと触ったときには少々面食らったw
Cコードに展開させてみて、はぁそういうもんかと理解した ■ このスレッドは過去ログ倉庫に格納されています
