【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コードに展開させてみて、はぁそういうもんかと理解した >>99
C とか C++ とかって大勢でプロジェクトを張ってると、
なんか真っ裸で職場をうろついているような気分になるんだよね。
昔の先輩（女性）は「毎日端末の前で脳内ストリップをやっているのよ！」
と仰っていたし。
> 勉強しなさい
修羅場で場数を踏みなさい。 >>103
当然C++の方がJavaより幅広い分野をカバーできる
どちらも徐々にRustに置き換わっていくだろうが 今まで色々なプログラミング言語が注目されては下火になるのを繰り返してきた。
そして、結局なんだかんだ言われながらC/C++が残っていくのでしょうね。
米粒みたいなワンチップマイコンから富岳まで、ほぼ全てのレンジでCコンパイラは用意されてるし。 >>105
C/C++と同じことが出来て、なおかつ、メモリ安全性を保証できるプログラミング言語Rustが登場したので
C/C++は各分野で徐々にRustへと置き換わりつつある >>106
今まで色々な言語が出る度にそういう主張は目にしてきたわ。
まあ、そういうかなり乱暴なこともできるのがCのいいところでもあるんだけどね。
とりあえずLinux互換のOSをRustで記述して、Rustならこんなにシンプルで高速になりますって見せてみたら良いんでない？ >>107
今までそのようなプログラミング言語は存在しない
初めて出現したのがRust
Linux OS開発でもCからRustへ徐々に置き換えて行く方法について議論がなされている Rust推しウザい
議論じゃなくて実際に置き換えてから来てくれ >>107
Linux互換OSどころかLinux自体がRustで記述されるプロジェクトがLinux開発チームで動いてるよ
トップのLinusもそれに対して対応すべき項目を挙げたのでその対処が進められているよ GoogleもAndroid OSをRustベースにしたいと言って色々やってるしな。 願望だけでまだ何一つ置き換えられていないRust
まるでチョン君の永遠の10年後と一緒だなw Facebook、開発言語に「Rust」採用 次期ビルドシステムの開発で
https://www.itmedia.co.jp/news/articles/2107/28/news152.html
Rustを用いることで、どのような利点があるのか。Facebookは記事の中で次の4つの項目を挙げています。
①Rustのasync/awaitシンタックスは、非同期のコードをとてもスムーズに記述できますし、Rustは複雑な並行処理の詳細を正しく理解するのに役立ちます。
BuckのJavaの計算を一つ一つ並行処理に移行するのは数カ月に及ぶ困難な作業でしたし、シングルスレッドの大きなボトルネックがまだ存在しています。
②Rustには、開発をより簡単で楽しいものにしてくれる多くの高レベルな言語機能があります。
それらはenum、パターンマッチング、trait、手続き型マクロなどで、Rustの開発者の多くに愛されています。
③Rust はメモリの割り当てをより細かく制御することができます。
ガベージコレクションのある言語では、たとえジェネレーショナルコレクションであっても、Buckが行うようなインクリメンタルな演算に対応するのは困難です。
④Rustは高性能です。
Rustに移植することで劇的な性能向上を私たちは見てきました。 半年付き合って親御さんと顔合わせを済ませて婚姻届に署名捺印して金庫にしまってからでないとコンパイルできないRustちゃんは男女の抱えるトラブルのかなりの部分を解決するけど
浜辺で出会って月明かりの元すぐコンパイルできるCちゃんがいることで維持できる物語もあるんだよ Rust推しは確かにウザいが、大手での使われ方が今までの言語とはっきり違うので
無視して良いものではないけどなあ >>116
実際に書いてみると慣れだけの問題でそんな違いは出てこないよ
むしろRustは後発言語なだけあって他の言語のそれぞれ良い部分を洗練して取り入れた面もあってプログラミングはCより遥かにしやすいね Rustはしばらく半信半疑で様子見されてきていたけど、ここにきてようやく試験に合格したような雰囲気があるな。 今現在C/C++はほぼあらゆる場で使えるしなあ。リアルタイムOSもLinuxもとりあえずCを身につけてたら読めるしね。
SystemCでハードウェアまで含めたシミュレーションや論理合成まで繋げられるから、C++でアルゴリズムを検証した後、負荷の重い部分をSystemC環境に移してFPGA化して高速化するなんていう具合にハードウェアとソフトウェアをシームレスに繋げられるのも利点だよね。
Cの悪名高きポインタも、あれのおかげでハードウェアのレジスタアクセスなんかが簡単に記述できるんで、とってもありがたい存在なのよね。 Visual Studio が標準で Rust をサポートしたら本気出す
まあ公式がこんなドキュメント出してるくらいだからそのうち標準になるんじゃないかと楽観視してる
https://docs.microsoft.com/ja-jp/windows/dev-environment/rust/setup 1970年代に生まれたC言語が現在でもよく使われているのは、ハードウェアに直接アクセスできる基礎的な言語であるためだが、
メモリー関連の脆弱性が発生しやすいという問題も抱えている。
Mozillaが支援し、開発されたRustは、システムプログラミングでC言語の代わりになる言語として期待されている。
例えば、Googleが一部で「Android」の開発にRustを導入しつつあり、
RustをLinuxカーネル開発の第2言語に採用しようとする活動も進んでいる。
またAmazon Web Services（AWS）はインフラ開発にRustを使用しており、
Microsoftにも「Windows」や「Azure」の開発にRustを使い始めている。
このようにIT業界が一斉に同じ新たなプログラミング言語を採用するのは史上初のことであり、
メモリ安全性を保証しつつC言語が担ってきた分野を完全に置き換え可能なRust言語が新たに時代を変えつつある。 着替えが上手ければ更衣室行かなくてもいいよねというCちゃんが胸チラマンチラしながら教室で着替えるからこそ
ガードの固いRustちゃんの振る舞いが周りに受け入れられるんだよ
CちゃんがいなければRustちゃんはただのめんどくさい子 >>125
え？？プログラミングしたことないでしょ？
Cが自分でメモリをalloc/freeしなきゃいけないめんどくさい子だよ
Rustは安全に自動で解放までしてくれるから手間のかからない良い子 >>127
> Cが自分でメモリをalloc/freeしなきゃいけないめんどくさい子だよ
ANSI標準 C のでは確かにその通り。
文字列も含めて配列はただのポインタでしかないので、その先にある
データ領域は明示的にサイズを示すかSIZEを指定して alloc しなきゃ
いけないし、領域外参照も自動的にチェックしてくれないから
pop/push 時に自分で監視しなきゃいけない。
まだ Mac が古い OS だったころの C では、文字列は
ポインタではなくてハンドル（ポインタへのポインタ）で、
文字列もヌル・ターミネートの C 文字列じゃなくて、
先頭に文字列調を持った Pascal 文字列だったように記憶している。
そういう点に配慮した、初心者にとって扱いやすい C 言語は、
学習用にあってもいいと考えた人もいて（たしか T 社）、
「C のインタプリタを C コンパイラで書く」という地味な仕事を
かなり昔にやったことがある。 ちなみに FORTRAN 60 も配列はただのポインタだったので、
「配列の添字に負数を指定してシステム領域に手を伸ばす」
とかいった猥褻な手法が使えたという。 はい頑張って勉強します
/* very simple daytime client */
#include <stdio.h>
#include <stdlib.h>
#include <strings.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
int main() {
int sockfd, n;
char buf[127];
struct sockaddr_in servaddr;
sockfd = socket(AF_INET, SOCK_STREAM, 0);
bzero(&servaddr, sizeof(servaddr));
servaddr.sin_family = AF_INET;
servaddr.sin_port = htons(13);
inet_pton(AF_INET, "127.0.0.1", &servaddr.sin_addr);
connect(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr));
n = read(sockfd, buf, 126);
buf[n] = 0;
fputs(buf, stdout);
exit(0);
} >>131
頭っから stdio.h が入ってマクロアセンブラのヘッダが並んでいて、
終わりが exit(0)っつーのが通な感じだな。
Java で exit すると JVM のプロセス自体が落ちちゃうので、
C だと上のプロセスからコールされて、longjump みたいな
感じの大域脱出をするパターンで使うのが吉かと。
まぁ、最近の Java だったらキャッチ＆スローで処理するところだけど、
上の方のルーチンで例外を握りつぶしていたりするので、
大きなプロジェクトではときどきトラブルが起きたりはするのだが。
>>130
> いやんエッチ！
Mb といえば「ブラックアートの沼津秘宝館」、
Mr.Moto といえば「ギミックの玩具箱」、
所長といえば「アルゴリズムの生辞引（ウォーキング・ディクショナリー）」
と云われたものなんだがな（笑）。
まぁ、とりあえず何でも訊いてくれ。
C コンパイラに、なんか仕掛けるとかいったネタは、
チューリング賞の受賞講演とかであったように思う。
「ブートストラッピング開発には、
セキュリティ上の穴がある」というのは、
Ｌinux 使いには念頭に置いておいてほしいと思う。 そういえば、ヘッダファイルの巡回参照で
コンパイラを落とすとかいうのはよくあったなぁ（笑）。
あとは返り値が文字列だったりするときのバッファは
レジスタには収まりきれないのでメモリ上のレジスタの
アドレスで返ってくるわけだが、その領域外のアドレスを
狙ってプログラム領域を書き潰すと、他人の書いたコードの
ところでエラーが出る（ミニコンとかだと、アドレスカウンタガ
表示される）ので、けっこう惨い目に遭ったという話を
聞いたことがある。 >>129
え？？プログラミングしたことないでしょ？ >>134
大文字の FORTRAN（FORTRAN 60）はさすがに無ぇな（笑）
Fortran 77 は勉強したけど動かせる環境がなかった。
仕事で使ったのは学生時代にカシオのプログラマブル電卓とBASIC、
修飾してからはアセンブラだった。
趣味では Pascal と C を触っていたのと、BASIC で FORTH の
インタプリタとか書いていた。
その後は C で仕事をするようになり、ちょっと病気でブランクがあった
ので Java を勉強し、SQL で仕事を貰ってから Java が本職に。
その後 Web の仕事が多くて、言語じゃないけど HTML と CSS と JSPを
勉強。なぜ SQL が入っているかというと、再帰とか木構造データとかが
得意な人がおらず、非数値処理屋だった私にお鉢が回ってきたから。
Oracle 9i からは「CONNECT BY」という再帰呼び出しが可能になり、
これを使って二つの木構造データを比較たいという仕事をアサインされたから。
SQL はつまんなそうな言語だけど、テーブル設計とかのシステム寄りの
観点からみるといろいろ興味深いところがある。 >>136
>>137
おまえらコテハンつけて正面から喧嘩売ってこい。
「かかって来いよ。相手になるぜ？」
（Go ahead. Make my day.）
読み筋は「ダーティ・ハリー」。 きょうは参考書のソースをいじってpenサーバーつくったよ
socketの段取りマンドクセ
/* telnetでport 20000につないでみてください */
#include <stdio.h>
#include <string.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>
int main()
{
int listenfd, connfd;
struct sockaddr_in servaddr;
char buff[4096];
listenfd = socket(AF_INET, SOCK_STREAM, 0);
bzero(&servaddr, sizeof(servaddr));
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
servaddr.sin_port = htons(20000);
bind(listenfd, (struct sockaddr *)&servaddr, sizeof(servaddr));
listen(listenfd, 1024);
for (;;) {
connfd = accept(listenfd, (struct sockaddr *)NULL, NULL);
snprintf(buff, sizeof(buff), "%s\r\n", "This is a pen, That is a desk.");
write(connfd, buff, strlen(buff));
close(connfd);
}
} >>139
なんかしら見ていて気色わるいコードだな(-_-;)。
「main()」はかなり昔（もう二十年以上も前）のスタイルで、
昨今は「main(argc, argcnt)」だったような ……
Java だと配列はオブジェクトなので、「main(args)」で
済んじゃうんだが。
「for (;;) {」もどういうコードに落ちるか不安になるが、
C にも Java にも「LOOP - UNTIL - DO - REPEAT」構文がないので、
「for (;;)」とか「while(true)」とか書いておいて途中で break するしか
方法がないので致し方あるまいと思う。
あとは、商業プログラマだと、入力のチェックとか入力文字列の
サニタイズとかで無暗に手間を喰うので、入力は別ルーチンに
しておくと、あとあと保守が楽だぞ。 node-red使いだしてから長ったらしいコード書くのが面倒くさくなってしまったな。
とりあえずC/C++はどこでも使えるから知っておいて損はないかな？
あと、AI系はPythonがライブラリの充実ぶりで圧勝で、あちらの世界で話をするときの共通言語って感じだし、AIは当たり前のものになってきているから避けては通れないかな？
過去に何度も「将来、これが主役になる」と言われたものはあったけど、結局主役になることもなければ完全に消えるでもなくカオスになっただけって感じだし、他のものは必要に応じてってところかな？ >>141
OS/2 の時代に VisualAge C/C++ と使っていた世代としては、
とても得心がゆく。
VisualAge はかなり優れた IDE だったが、Java に対応するように
なってから、「IBM」ブランドだと警戒されそうだと思ったか、
「Eclipse」として独立させて成功した。
Node-Red については知る機会がなかったが、
ツールとして興味深いので勉強しようと思う。 >>141
> AI系はPythonがライブラリの充実ぶりで圧勝
ディープ・ラーニング（深層学習）とか言ってる時点で
マシンの高速化に頼ったパターン認識の焼き直しでしかないと
考えている。
並列処理に関してきっちり向かいあうかどうかが今後の課題だな。
名ばかりの AI は、邪魔なので道をあけてほしい。
読み筋はトヨタ・チェーリカ。 数値計算もSQLも両方書けて初めて一人前な感じはするよね >>140
cはコマンドライン引数いらんかったらint main(void)って書けるよ
c++ならint main()の書き方でおｋ >>146
呼ぶ側の都合と呼ばれる側の実装の擦りあわせを考えると、
「言語仕様として、それが可能だ」よりも
「業務レベルで考えると、保守しやすい可読性の高いコード」
というのが重要になってくる。
「ダサいコード」も、誰もがダサいと感じるわけじゃなくて、
それなりに経験を積んでいるプログラマだと、
ニヤっとすることもある。
「つまらないコード」というのは、誉め言葉だったりもする。
>>145
「勉強」という言葉を間違って覚えた典型的な例だな。
他人から言われて「勉強」するんじゃない。
自分が自（みずか）ら自分に科すから “勉強” なんだ。
虐待経験があったのは痛ましいと思うが、
それは別板にゆくかカウンセリングを受けろ。
とはいえ、昨今の精神科っていうと薬物療法が主体なので、
ちゃんとしたカウンセリングを受けようと思うと、
なかなか難しいんだよなぁ …… >>146
Java に慣れちゃうとなぁ ……
引数を握りつぶしちゃうのもいまひとつだし、
オプションをチェックするのも仕事のうちだし、
引数なしで呼ばれたら、「usage()」ルーチンに
飛ぶのが礼儀のような気もするので、
パイプ処理前提の C とは、若干感性が違うかもしれない。
GUI 全盛の現在では、そのあたりはなかなか
理解してもらいづらい点はあるのだが。 アセンブラとかマシン語とか言ってる奴。
解ってんだろ、実務ではこのご時世、ほぼ糞の役にも立たないって。
余程特殊な業務でもない限りまず使わない。それこそパチンコとかの組込みとか、ゲーム作る際に余程特殊なことやる場合とかだ。
あまり実用的ではないし、理屈だけ知ってればまずアセンブラやマシン語は使われることはない。
昔ゲーム作る際に使ってて、それ以降全く使っていない俺が言うんだから間違いない。 >>150
それらもRustでプログラミング可能
どうしても一部アセンブラで書かなければならない部分があったとしてもRustはその部分だけをRustプログラムの中にアセンブラで記述可能 >>149
デシジョンテーブルとかよくやってたなぁ。
昨今の「かな漢字システム」でもいまだに使っていたりする。
少なくとも MicroSoft は、「私、馬鹿でーす」と
顔に貼っているから、もう IME も信用できない。
日本 IBM はどこへ行こうとしているのかが分からない。 >>150
> 解ってんだろ、実務ではこのご時世、ほぼ糞の役にも立たないって。
> 余程特殊な業務でもない限りまず使わない。それこそパチンコとかの組込みとか、
> ゲーム作る際に余程特殊なことやる場合とかだ。
> あまり実用的ではないし、理屈だけ知ってれば
> まずアセンブラやマシン語は使われることはない。
そういう技術者を消費していた派遣業者が問題であって、
「技術屋」を使い潰してきたバブリーで
脳内アッパラパーな連中に対する
憤（いか）りはもちろんある。
で、「高齢者」「障がい者」とか雇おうとしても、
雇傭者側にも怯えがあたりする。
ちゃんと教えられる人はまだしも救いがあるのだが、
ちゃんと説明できちゃうとバブリー頭の経営者に排除されたるするんだよな。 >>155
> BNF
BNF ことバッカス＝ナウア記法というのは
Pascal の文法記述に使われたのが有名だが、
図で表現しようと思うと、やたら面積を喰うので
大型（A 全とか B 全とかの）のプロッタとかがないと
全体が見渡せないんだよな。 >>156
うちの所長が日本語の形態素解析の仕事をしたときに、
B 全の方眼紙を近所で何枚も買ってきて
日本語の形態素に関する文法を描いてたことがある。 あと、カルロス・ゴーンさんが
日産のスカイラインGTを復活させるという話があって、
それ用の新しい製造ラインを構築するという話があって
所長が三菱総研の話で入ったことがある。
そんとき所長はSQLの話で入ったのだけど、
ER図（エンティティ・リレーション図）という
Java のオフジェクト図みたいなのを見たらB全で、
とても分かりやすかったという話を聞いたことがある。 >>158
> きみ頭悪いって言われるでしょ
馬鹿と鋏は使いよう
馬鹿と金槌は使いよう
きみは決して経営者になるな。
子供に金槌を持たせると何でも叩くから。 >>145
>>146
現代ではネットワーク・コンピューティングが一般的だが、
CPU が一個（待合わせの必要がない、ワンプロセスの処理系）の
処理系だと、いわゆる「フォン・ノイマンのボトルネック」という話に
なるんだわ。
どっかのメモリ領域から引っ張ってきた値を処理して、新しい
値を格納する間に、他のプロセスが元の値を書きかえちゃったら
辻褄が合わなくなるだろ？ そのために「排他制禦」っつーものが
あるんだけれど、いちいちそれをやっていると実行効率が下がるんだ。
C 言語はハードウェアべったりの「超高級アセンブラ」
（要するに、いわゆる「高級言語（第三世代）」ですらない
第二世代の言語）と云われていたし、Haskell は
「遅延評価」というコンセプトに基づいているので、
「どこに位置づけたらいいのかの判断が難しい」という話になる。
「『竹内の tarai 函数を』 Haskell で書いて実行する」
とかいった話は、掘り下げておいて損はないと思う。
「入山のアルゴリズム」も参考になると思う。 結局は「一番距離の近い周りが使っているもの」になるんだろう。 >>162
> 結局は「一番距離の近い周りが使っているもの」になるんだろう。
いや、昨今はそのあたり、昨今は切実な話だぞ？
守秘義務契約でガチガチに縛られてて、
テレワークで同じ職場の人間と会話する機会もなくて、
自粛要請のせいで同業者と飲み会をすることもできん。
コーディングで詰まったときに誰にも相談できんというのは
しみじみキツいので、まだしも使っている人間が多い Java は
選ぶ価値があると思う。
ただ、昨今は言語について深く掘り下げようという人間は
少数派なので、けっきょく C 世代の年寄りばっかりが集まって
愚痴を垂れるばっかりになってしまうのだが ……
せめてもの救いは、家庭用のビアサーバーが普及したことくらいかな。
ウィスキーやレモンサワーだと、糖分が少ないせいか悪い酒に
なりがちだ。 仕事ならなおさら、チーム内で使っていない言語を勝手に選ぶわけにもいくまい。 >>151
可能かどうかより、周りが使ってるかどうかだろうけどね。
電子工作系でもRust使った作例はごく僅か、ほとんどC/C++とアセンブラだもんね。 >昨今は言語について深く掘り下げようという人間は 少数派なので、
プログラミング言語の栄枯盛衰が激しいからね。掘り下げるなんて言ってる間に次の流行りが来る。
その多くがC/C++の欠点をあげつらってこんなに素敵なんだ、これからはコレが主役だ！とか言ってたけど、結局その他大勢の中の一つになっていったしね。
まあ、新しい言語を作る側の人間もまたC/C++使いだったりもするんだろうけど。
てか、人生ズボラ派としては、いい加減、文字をずらずら並べてプログラムを記述するというスタイルそのものがどうにかならんのかな？と思ったりはするわ。 >>167
> 文字をずらずら並べてプログラムを記述するというスタイルそのものが
> どうにかならんのかな？
それは「ノンテクスチュアル・プログラミング」といって、
わりと人類の夢みたいなところがあるんだが、実現しようと思うと
JIS フローチャートとかで育った人が話をややこしくするのだ。
SPD とか ＮS チャートとか、構造化に向いたものもあるんだけどな。
早稲田大学（日立？）の二村先生は、「この世から JIS フローチャートを
撲滅したい」と公然と主張していらっしゃった。
いちど筧先生の研究室のお邪魔したときに、外廊下のどんづまりが
二村研究室で、仕事で日常的にフローチャートを書いていた私は
逃げ帰ったことがありました。 もう言語から作っちゃうのが早いような気がしてきた。
昔の Fortran 77 で、「最短のプログラム」というのがあって、
「END.」だそうだ。
Pascal だと begin ～ end がやたら目についたし、
C や Java だと「main()」で始まるし、
Java で「exit()」とかやると JVM そのものが落ちて面倒な
ことになる。
そのあたりを整理して、変数スコープをはっきりさせて、
強い静的な型付けを強制して、swap とか
loop ～ until ～ do ～ repeat とかも導入して、
void だったら 「repeat.」とちゃんと書かないと文法エラーになるような、
かっちりした教育用の言語があったら、
遅かろうがなんだろうが使う価値がありそうに思う。 IBMメインフレームのアセンブラなら、最短のプログラムは
ST__EQU＿*
____SR__15,15
____BR__14
____END_ST
IEFBR14だ >>171
さすがに濃すぎてわからん。うちらは通信用のスーパーミニ
（たしかハネウェルのコピーの NCOS）だったので、
いわゆるメインフレームは触ったことがないのだ。
ひょっとして、「白い机の 360」とかの世代の方ですか？ さすがに…
360、370の後継の z/OSです
ですが、IEFBR14 は360の頃から使用されていますね
何もしないで戻り値として 0を返すだけのプログラムです
intelで戻り値をaxレジスタにセットするように、レジスタ15に0を設定しています >>173
私も「NCOS」といっても「スーパーミニ（MS140以降）」の時代なので、
「NCOS 1 アセンブラ」はちょっと齧っただけ。
入間基地の FADP にメインフレーム級の NCOS が
あったのは見た記憶がある。
ミニコンピュータといっても、「PDP」シリーズは写真でしか
見たことがなく（あのカラーリングの感性はいかがかと思う）、
PDP-11 の仮想記憶版の拡張型であるVAX-11（いわゆるブルー・バクスン）は
NEC の府中事業場の隅っこで埃をかぶっていたのを見たことがある。
つーても、あれってサイズが高級車一台分くらいあるんだよなぁ …
「“ミニ” コンピュータ」っつーんだから、せめて大型冷蔵庫くらいの
サイズにしてほしい。
自宅にサーバールームを用意して、17 インチのラックを設置するとかいうのは
さすがに控えようと思うのだが、ケース買ってきて自作マシンというのは、
若気の至りで一度やらかしたことがある。 ぶっちゃけ、高級アセンブラとしてのC。
その上はいろんな哲学を学ばないといけないから。 >>176
>その上はいろんな哲学を学ばないといけないから。
C は記述の粒度が小さいもんだから、
小さいプログラムを自分ひとりで書いているうちは
いいんだけど、なんかしら全体構造が見えづらくなっちゃうんだよな。
若いうちはそれでも力業でなんとかなるんだけど、さすがに
三十代半ばを過ぎると「三日前の自分は他人」というのが
身に染みてきて、ちょっと大きなプロジェクトでチームを組むと
なにかしら行き詰まりを感じたりする。
私の場合は、その先のポジションが Java だっただけで、
C♯とかいう人もいるかもしれない。 >>177
それならばRustが良いですね
Cと同じく低水準な記述も可能でネイティブコンパイルされGCも無し
C言語がとっても便利で強力になったものがRust言語 最初に学ぶというからには、手っ取り早くでなくということではなく、体系的に学びたいということなんだよね
僕はC押しだったけど、たしかにCはかならず一度は通らなくてはならないと思うのだけど、最初にCで挫折してしまうより、もう少し取っつきやすい、アルゴリズムに集中できる言語から入るのがいいのかなとも
順番に拘らないというか どうせやるんだから(やらなきゃ話にならないんだから)
最初からやったほうがいいに決まってる
後からで良いって逃げてる香具師は使い物にならない(レベルで満足してるのが多いイメージ) どうせやることになる言語はrustやhaskellに限らずたくさんあるんだから、何もそれらを最初にやる必要は全くなく、基礎的なもの分かりやすいものから順に積み上げるのは妥当だろう >>181
おかしかったワ:
最初に学ぶというからには、手っ取り早くということではなく体系的に～ >>183
妥当というか当然だよね
このスレにいる奴は頭のおかしい社会不適合者ばかりだから世間とずれすぎてる >>185
> このスレにいる奴は頭のおかしい社会不適合者ばかりだから世間とずれすぎてる
それは×かなぁ。
「こんなマイナーなスレをわざわざ荒しにくる奴は、どっか心を病んでいる
『精神的な社会不適合者』ばかりだから、プログラマ文化からずれすぎてる」と
いうのが適切だと思う。
先天的に脳がおかしい（ということは、「頭がおかしい」）けれど、
「自閉なんだけどフツーに有能なプログラマ」は電算業界には普通にいるし、
理数系の研究者に関しては、むしろ「自閉系である」というのが
強みであったりする。
「世間とずれすぎてる」というのは、同調圧力に負けているんじゃないかなぁ。 >>174
PDP、なんかレトロフューチャーみたいでかっこいいじゃんと思う。 >>188
漏れもそう思う。紫とか使っちゃうところがパンクチュアルだと思った。 DECがロゴの色をバーガンディに変えたのは1990年代のことだがな。
PDPの時代はいわゆる"Small Blue" そうだったんだ。
仮想記憶システムをフォローした VAX-11 は、
「ブルー・バクスン」と云われていたのは憶えている。
Prolog で有名な中島（「ナカジマ」ではなく「ナカシマ」）
秀之さんは Prolog 処理系の VAX への移植で有名だが、
未見だけれども「秘境 Prolog に名前呼びの修羅場を見た！」
という論文があるとかないとか（もうすぐ『bit』の電子版が
出るらしいので、興味があったら購入して探していただきたい）。 そういえば思い出した。
DEC はパソコンにも手を出して、ケース型のパソコンを出して
いたんだよな。それで「DEC なら信用できるだろう」と思って
秋葉原で買ったら、パソコン業界からいきなり撤退しやがった(T_T)。
以来、「DEC」というブランドは信用しないと決めている。
同様に、「Microsoft」「アスキー」とかいったブランドは、
基本的に信用しないと（個人的な意見だが）決めている。 DECの関東工場で生産されるパソコンはMade in TOKYOと銘打ってHPが販売してる。 最速ならvscodeでもダウンロードしてきてjavascriptでもてきとうにいじるのが良いかもね。
そのあとは知らんが。 vscodeだと汎用的すぎて開発ターゲット決めるところからだし敷居が高い
よくあるシミュレータ付きの適当なIoTデバイス用IDEでJS対応してるのがオススメ
遊ぶ分にはデバイス購入不要
他にもUserscriptの改造とかすぐ目に見えて動かせるものが良いはず >よくあるシミュレータ付きの適当なIoTデバイス用IDEでJS対応してるのがオススメ
で、具体的に何？初めての人はそれがわからんから苦労するんだろ。 >>197
有名どころで取っつきやすいのだと
https://www.microsoft.com/ja-jp/makecode
ここのArcadeかmicro:bitのチュートリアル
いっそ初手ならここのブロックプログラミングで良い気もする >>193
>>194
そうなのか orz
「がっちりマンデー」の報道は嘘だった（法律上は「嘘」とは
言えないだろうが）んだな。
「Made in TOKYO」といっても、
「東京都内で組み立てています」というだけの話であって、
たとえば餃子の餡と餃子の皮を中国から輸入して日本で包めば、
「Made in Japan」の餃子になっちゃうわけだからなぁ …… 組み上げたあとの検品をちゃんとしてくれたら文句はないんだけど
最近は国内メーカーの冠ついてても信用ならんのよね マウスコンピュータの評判はどうなんだろう。
本来ならば、いわゆるノートブック・パソコンは
姿勢が辛（つら）くなるのでお勧めはしたくないのだが、
新型コロナウイルス感染症の流行明けだと、
「矯正出社」というのがあってリモートワークも
ままならなくなっているらしい。
昔は「読書机」というものがあったのだが、
昨今はパソコンも小型化しているので
なんかしらそういう環境があってもいいと思う。
「最初の言語に何を選ぶか」というのも重要なんだが、
まず開発環境を整備しないといけないと思う。 >>202
基数的定義と序数的定義があって、N88 の BASIC では
OPTION BASE という構文があって、0 と 1 のどっちで
始めるかが指定されていたりする。
このあたり、真面目に議論すると長くなるので、
待て続報。 >>202
> これってfortranってどうやって配列添字アクセス実現してるんや？
「fortran」と一括りにするのは先達に失礼なので、
「FORTRAN 60」（別名「大文字のフォートラン」）と
「Fortran 77」（別名「ナナナナ」）と、
NC旋盤とかで使われている「ハチマル」というのがある。
「フォートラン」というのは、フォームラ・トランスレイター
の略語で、もともとは「F-1（フォームラ・ワン）」と同じように、
「サーキット上の怪物」として数値計算（＝科学技術計算）として
君臨していたのが「大文字のフォートラン」だった。
さすがにレガシーコードなので、見たことはあるが動かしたことはない。 屑な IME が、「フォーミュラ」のつもりで打ったら「フォームラ」と
変換しやがった(-_-x)。
くたばれマイクロソフト。 formuraかfo-muraとでも打ったか
ローマ字設定でlaをラにしてて予測が負けたか 投稿前の見直しを怠った言い訳にはならない
素直にごめんなさい言えない奴はいらない >>286
「formura」を変換すると「ふぉｒむら」になったりする。
「program」を変換すると、「ぷろｇらｍ」になったりする。
こんな屑な IME に慣らされちゃったら後生が悪かろう。
このあたり、「デジタル庁」がなんとかしてほしいと思うが、
「ディジタル庁」でない時点でけっこう減滅しているし、
「digital」を「ぢぎたｌ」と変換する Microsoft の
IME が憎い。
「microsoft」は「みｃろそふと」だそうだ。
「alfa」は「あｌふぁ」で、「beta」は「べた」だという。
デジタル庁は、国家予算を使ってでも、まともな IME を
作ってほしいんだが。 formula translator の formula は数式って意味じゃなかった？
数式を変換して書きやすい文法になってるからFORTRANという名前になっているのだと。
あとフォーミュラカーは、F1は怪物かもしれないけど、形がレギュレーションで規定されている車ぐらいの意味しかないと思うし、いろいろ勘違いしてない？
formulaの綴りも間違ってるし。
大体、betaはベタと変換してくれなきゃ困るよ。日本語でもよく使うんだから。
ローマ字入力と変換に英語入力を期待する方がおかしい。
気になるなら使うものを辞書登録しておけば解決すると思うが。 >>209
> 大体、betaはベタと変換してくれなきゃ困るよ。日本語でもよく使うんだから。
それは個人の語彙の範疇との間で勘案すべき問題であって、
「日本人」の範疇で括っちゃうのは乱暴じゃないだろうか。
観賞魚マニアだったら、「beta」だったら「闘魚（ベタ）」と変換して
くれれば有難いけれど、「β」とか「ベタネタ」とかいった用法は、
それぞれのユーザに配慮してほしいと思う。
学習機能で、ようやく使い勝手がよくなってきた辞書が、いきなり
更新されてチャラになったりしたら泣けるだろう？ >>209
> 気になるなら使うものを辞書登録しておけば解決すると思うが。
うん。速記タイプとかリアルタイム字幕放送とかについて調べてきてから、
もう一回来てくれ。 formulaのスペル間違いの言い訳はどうして飛ばしたの？
ちゃんとして？ >>211
それらとプログラミング言語になんの関係が？
IMEはキー入力を日本語文字列に変換する写像であって、その写像の優劣は目的によって異なった物差しで測られることになるだろう。
速記タイプとかリアルタイム字幕放送のIMEでプログラミングの話題がしやすいとは思えないけどな。
ちなみに自分は色々兼ね合いとってDvorakJPぐらいに留めてる。漢直を覚えようとしたこともあったが諦めた。
あと、フォーミュラカーの件はスルー？ >>214
ガイガイガイガイｗ
あそれｗガイｗあそれｗガイｗ
ガイガイガイガイｗあそれｗガイｗ 仕事辞めてやることなくなった爺が話し相手欲しくて居ついちゃってんだよ。相手しちゃダメ。 あ、やっぱ自分のことだって気づいてたんだ
みんなドン引きしてるよ 初心者向けというのなら、
実行効率はそんなに重視しなくていいし、
メモリサイズも大きくても構わないだろ。
あとは構造化プログラミングに向いた
ステートメントが整備されていて、
そこそこモジュール化にも考えてくれていて、
処理系が普及しているもの …… となると
あんまり思いあたらないなぁ。
高校の数学の先生とかだったら N-BASIC かなんか
使いそうだし、小中学校では（タートル・グラフィクスは
あまり普遍的ではないけど）LOGO になっちゃいそうだ。
文科省あたりが旗振って、教育用言語の規格を作ってくれれば
いいと思うんだが。 こどもの学校配布のiPadにはScratchがはいってる
構造化・イベント駆動プログラミングで現代的だし
Playgroundだから本質的でない問題に悩まされずに済むし
Eテレの番組まであるんだから実質標準じゃないかな >>223
「MicroSoft」と聞いただけで怖気（おぞけ）を揮（ふる）うのだが、
正直な話、「ビル・ゲイツは印足して改心したかもしれないが、
マイクロソフトという企業体が、今後何をやらかすか」に
ついての意見は保留しておきたい。 >>223
由来とかについて調べてみたところ、
Scratchはそれほど悪い言語ではないかもしれない、と
思った。
ちょっと近所の大きい本屋に行って、Scratch の処理系を
インストールしていろいろいじってから、コメントしたいと
思う。 マジで変な奴居着いたな
もうコメントしなくていいよ 正直な話、荒らしが出てくるのはどうでもいいんだが、
頼むから sage 進行をお願いしたい。
連続してプログラム技術板の上位で出てくると、
古参の民に嗤われちゃうんだよ (T_T)。 Microsoft を MicroSoft と書くだけで、うまく認識できないというか、インチキくさいというか… 子ども向けならマイクラのコマンドで遊ぶのもいいと思う。んでスクラッチだと思うけどマイクラのワールドにプログラムで動くエージェント召喚して働かせる事もできる。
スクラッチで作ったフローはJavaとPythonで表示されるから、高学年はコード編集して遊んでる。 スクラッチはJavaじゃなくてJavaScript 製だよ >>231
『プログラミング演習における シンボルの名前付けに対する指導』
（https://gakkai.univcoop.or.jp/pcc/2018/papers/pdf/pcc034.pdf）
とかを読んでからまた来い。
Java に慣れちゃうと、そうなるんだよ。 >>237
詭弁に過ぎない
固有名詞の話とは関係ない > 詭弁に過ぎない
とかいって逃げる奴が多いから、短文系の BBS は
「便所の落書き」とか言われちゃうんだよなぁ。
そもそも、「固有名詞」じゃなくて、「命名規則」の
話をしているんだが。
「N0013」とか「X0023_05」とかいった命名規則を
強制されてみると、その苦労は感得できると思うが。 >>231 は固有名詞の書き方について突っ込んでいるのに
君が >> 237 で勝手に命名規則の話をしているだけだよね 話を整理しよう。
>>240
> 固有名詞の話とは関係ない
というのは、何の話をしているんだろう。 なんかのJavaクラスに、マイクロソフト実装で処理をするか自前実装で処理をするか切り替えるメソッドがあったとして、
useMicrosoftImplementation(bool)ではなく、
useMicroSoftImplementation(bool)と命名されてたら、
プログラマーの質を疑っちゃうね。固有名詞もちゃんと書けないのかと。 「荒らしもスレの賑わい（読み筋は「枯れ木も山の賑わい」）」と
いうネット俚諺もあるのだが（あるのか？）、
スレが停滞すると楽しみがなくなっちゃうので、
ザコネタでもいいから投稿があると活気が出そうに
思う。 スレが停滞しているのはMbさんが住み着いたからだぞ >>245
まぁ、落ちなきゃいいじゃん（笑）。
墜ちそうになったら、age てくれるひとがいるかもしれない。
確かに書き散らかしたという点では反省するしかないのだが、
なんかしら「まとめ」的なものを提示しないと卑怯だ、
という話はありそうに思っている。 >>246
つーか、FORTH の処理系から書いた（笑）。
社会人になってから一年目に NEC に就職したのだが、
そのとき防衛関係の「RMA」っつーのの担当だったので
航空自衛隊の各サイトのアベイラビリティを計算しなきゃ
いけないので、それ用の言語を作っちゃったんだわ。
で、そのコンパイラの中間言語として、
FORTH もどきのシステムを組んだことがある。
だから、ネイティブな FORTH を扱った経験はないんだわ。 あと、「Make 10」っていうパズルがあるじゃん。
「0 を含まない四つの異なった数字で、加減乗除だけで
10 を作れる」っていうやつ。
あれの全数解を求めるのに、「いっぺん逆ポーランド記法に
落として、FORTH みたいな仮想機械の言語で片づける」と
いうのはやったことがある。
IT の電卓も根強いファンがいそうだから、「逆ポーランド記法」と
いうのは、けっこう（日本人限定かもしれないが）人気があるのでは
ないかと思う。 >>250
FORTHがないので手近な言語でやってみますね
まず逆ポーランド記法(RPN)を計算する関数を(加減乗除の)二項演算子のみ対応でこんな感じ？
function execRPN(rpn) {
const stack = [];
for (const x of rpn) {
if (typeof x === 'number') {
stack.push(x);
} else {
if (stack.length < 2) {
return NaN;
}
const a = stack.pop();
const b = stack.pop();
const c = eval(`${b} ${x} ${a}`);
stack.push(c);
}
}
if (stack.length === 1) {
return stack[0];
} else {
return NaN;
}
}
これなら小学生にも作れそう >>250
その「Make 10」パズルを逆ポーランド記法を計算する関数で解くには
総当りで逆ポーランド記法を生成して計算して10になるのを探せばいいんですよね？
加減乗除は重複組み合わせ(combinationsWithReplacement)で使ってよくて
それと数字を合わせて順列(permutations)を生成すれば総当りになりますね
結果10以外にも使えるように引数answerと数字も任意の長さで引数numberListとして
const { combinationsWithReplacement, permutations } = require('iterator-tools');
function make10(answer, numberList) {
const opList = ['+', '-', '*', '/'];
for (const ops of combinationsWithReplacement(opList, numberList.length - 1)) {
const list = numberList.concat(ops);
for (const rpn of permutations(list)) {
const val = execRPN(rpn);
if (val === answer) {
return rpn;
}
}
}
return null;
}
これも順列組み合わせを習った小学生ならすぐ作れそう 実行してみました
> make10(10, [1, 3, 3, 7])
[ 1, 7, 3, '/', '+', 3, '*' ]
> make10(10, [8, 4, 7, 3])
[ 8, 3, 7, 4, '/', '-', '*' ]
> make10(10, [6, 9, 6, 5])
[ 6, 9, 6, '-', '/', 5, '*' ]
> make10(10, [9, 6, 7, 4])
[ 9, 7, '+', 4, '/', 6, '+' ]
> make10(10, [3, 6, 6, 9])
null
> make10(10, [0, 0, 0, 0])
null
後ろ2つは解けない問題なのでnullで正解です
解けた方は逆ポーランド記法を普通の記法に戻して検算してみると
(1 + (7 / 3)) * 3 = 10
8 * (3 - (7 / 4)) = 10
(6 / (9 - 6)) * 5 = 10
((9 + 7) / 4) + 6 = 10
ちゃんと解けているようです
いきなり(7 / 3)とか(7 / 4)とか一時的に分数にしちゃうのですね
小学生向けの素敵なプログラミング課題だと思いました >>255
「255」っていうのがステキだな。
「Make 10」は、「0 以外の、相異なる 4 つの数字」なので、
[1,3,3,7]や[6,9,6,5]や[0,0,0,0]は考えなくてよくて、
[1,2,3,4]から、[6,7,8,9]までの組合せまでを生成すればいいので、
「もうちょっと頑張りたい」というプログラミング欲を
ソソる部分がある。
で、加減算は交換法則が成立つので、
「1+2+3+4」は、「4+3+2+1」と同じ、と思うと
いろいろチャレンジしたくなる。
さらに、「全部試す」以外に解法がなさそう、というのが
笑える。
「小学生から大学生まで楽しめる問題」として、
もっと普及してくれてもいいと思うのだけれど、
「いちど逆ポーランド記法に落とす」とかいった
技法があるので、あんまりプログラミング教育の現場では
嫌われているように思う。 >>252
いや、ぜんぜんすごくない（笑）。
NEC っていっても、当時は「住友金属のお荷物」みたいな
扱いで、その中でも「日本電気グループ」と
「日本電気ホームエレクトロニクス」という派閥争いがあって、
NEC 本体は「NES」というソフトウェア部隊があったのだが、
通信系グループは自前のソフトウェア部隊がなかったのだよ。
それで、NEC の通信系グループが立ち上げたソフトウェア会社が
あって、いろいろ社名を考えたんだけど、当時の田中社長が
「そんなんじゃ人が集まらない！」というので、
「日本電気航空宇宙システム株式会社」という会社ができたんだ。 >>259
単純計算で、1 から 9 までの数の順列は
9 × 9 × 9 × 9。いまどきのパソコンでは、
なんてことのない数字だ。
これを 9 × 8 × 7 × 6 に減らしたい欲がでてきたら、
ちょっとプログラマ向きの人だろう。
逆ポーランド記法で考えると「加減乗除」という
四つの演算があり、「四桁」という縛りがあるので、
数が四つで演算子が三つ。計七個のスタックがあればいい。
で、0 と 1 要素は数字で、６要素は演算子、ということが
わかっている。これを（一意に）網羅できるようなプログラムを
書くのには、どんなプログラミング言語が欲しいだろうか？
で、＋とか×のような、交換法則が成立する演算子については、
ちゃんと順序づけをしてほしい。さらに、「１０になる」という
縛りがあるのだけれど、途中で無限小数になっちゃうとややこしい
ことになってしまう。そうなると、「分数は分数のままに扱える
言語」であってほしい。そうなると、自分のプログラムの中で
作った式を処理系に渡して計算してもらわなくちゃいけないので、
LISP の EVAL 関数のようなものが欲しくなる。
「じゃあ、実際にどうやって実装するか？」まで考えると、
かなり興味深い話だと思う。 ↑にProlog向けと書かかれているのはスルー
おっさんのくせに引き出しが少ない 土曜日池袋のジュンク堂行ってきたけどあの規模の書店でもPrologの本なんて１種類しか置いてなかったぞ
しかも質が低い
こんなのどうやって勉強しろってんだ
最初の言語に選ぶなんてとんでもない >>261
本当にプログラミングできるならばmake 10でいいからコードを出してみてよ
>>262
Prologである必要性はないでしょ
例えばその問題を>>254はJavaScriptで簡単に解いている 必要性はないがevalがないと雑多なコードが増えるのは気づけてるのに
組み合わせはいいの？みたいな >>261
> 本当にプログラミングできるならばmake 10でいいからコードを出してみてよ
上げてもいいけど …… 長いよ？
「Java の宿題ここで答えます」スレとかだったらいいんだけど、
これからプログラミングを学ぼうとする人のためのスレである
「【C？】最初の言語に何を選ぶか【Haskell？】」
に、延々とコードを上げるのはどうかなぁ。
まず、「Java の宿題ここで答えます」の昔のスレとかを
見てくれると嬉しく思う。いちおう「Mb」の名前で
出てますから。
> Prologである必要性はないでしょ
竹内さんの「tarai 函数」なんかは、Haskel で書く価値がある。
「入山のアルゴリズム」も、Haskel で実装するなら
必要がなくなるかもしれない。
「必要性」というより、「処理系としてのコンセプトの多様性によって、
『必然性』の話になりつつある」という話じゃないでしょうか。 >>263
> 土曜日池袋のジュンク堂行ってきたけどあの規模の書店でもPrologの本なんて
> １種類しか置いてなかったぞ
どうせ中島さんか小谷さんの本だろう。
Prolog というコンセプトは、そんなに悪いもんじゃないので、
処理系から作ってみるのが正しいアプローチのように思う。 よく考えたら初心者に不親切でスマンカッタ m(_ _)m。
共立出版の「bit」に、Prolog の処理系のソースコードが
掲載されていたことがあるのだ。
たしか NEC の PC 8801 シリーズ以来の「N88 BASIC」
のコードだったが、いわゆる「Prolog 処理系の動作を
シミュレートするコード」というのは、LISP を使うと
わりと単純なコードに落ちるのだ。ただ、当時は
LISP にしろ（Apple LISP はあったが）Prolog にしろ、
パーソナルコンピュータ環境では実行が難しかったのだ。
それくらい貧弱な処理系環境だったので、
「カット・オペレータ」云々というのが「いかがなものか」
みたいな話があった。
とはいえ、Prolog の基本構想は悪くないと思うので、
Haskell がスレタイに入っている。
高嶺の花だった。 Java は言語処理系のインタプリタを実装するのには
悪くないので、「無ければ作れ」という視点もある。 >>271
> 何言ってんだこのバカ
それは、
「何を仰っているのでしょうか？
貴方は知的障害者ですか？」
と同義だと解釈して宜しいでしょうか？ バカ、アホの定義が地方やコミュニティで異なるからの確認だとおもうけど
BBSだからこそのレトリックなんよ
聞くのが野暮 >>273
つ 松本修『全国アホ・バカ分布考 ― はるかなる言葉の旅路 』(新潮文庫)
関西の一部地方の出身者には、「『アホ』や許せるけど『バカ』は許せない！！」
という人がいらっしゃったりもする。そうすると、「馬鹿馬鹿しい」とか
「バカ穴（ネジを切っていない、ワッシャーとビスで止める、位置決め用の
若干大きめの穴）」とかは、一部の関西地方の文化圏の方々に配慮すると、
「使ってはいけない言葉」だということになりますよね？
じゃあ、「バカ騒ぎ」もいけないんだ。「人を馬鹿にする」も
いけないんだ。「馬鹿貝」もいけないんだ。「あんた馬鹿？」は、
「あなたは智的障礙ではありませんか？」と言わなきゃいけないんだ。
あははー。
そんな粗雑な思考をしている人に、プログラミングを語られたくは
ないなぁ。 レスが冗長で誤字も多いしそもそもつまらん
誰からも相手にされないからネット上で承認欲求満たしたいんだろうな 自分の知識披露したいだけで
有益な議論をしたいわけではなさそうだしな
コード例とか出せないみたいだし(エアプでコード書けない？) 最初にやる言語で速さとか気にする必要ない
そんなことでマウント合戦して、これからプログラミング始める
美少女を迷わすようなことを言わないようにしましょう 全く美少女じゃないけど私もrubyから入ったわ
職場のrubyの本借りれたし先輩に詳しい人いたのが大きい 引数書くのやブロック書くのに括弧を多用する言語は疲れる でもカッコがある方が
エディタが助けてくれるからなあ
pythonとかタブの位置を合わせるのが大変 # Make10面白いな Elixirの勉強がてらに思わず仕事さぼって全解探索作ってしまったわ
defmodule Make10 do
@nums 1..9 |> Enum.map(&{:num, &1, Integer.to_string(&1)})
@ops [{:plus, "+"}, {:minus, "-"}, {:mul, "*"}, {:div, "/"}]
|> Enum.map(&Tuple.insert_at(&1, 0, :calc))
@initial_stack []
@initial_usednumbers []
@initial_state [{@initial_stack, @initial_usednumbers}]
@accept_duplicated_number false
def do_action({stack, used}, action) do
case {stack, action} do
{_, {:num, val, symbol}} ->
if !@accept_duplicated_number and Enum.member?(used, val) do
{[{{val, 1}, "#{symbol}"} | stack], []}
else
{[{{val, 1}, "#{symbol}"} | stack], [val | used]}
end
{[{{c1_n, c1_d}, exp1} | [{{c2_n, c2_d}, exp2} | tail]], {:calc, op, symbol}} ->
expression = "(#{exp2}#{symbol}#{exp1})"
case op do
:plus -> {[{{c2_n * c1_d + c1_n * c2_d, c1_d * c2_d}, expression} | tail], used}
:minus -> {[{{c2_n * c1_d - c1_n * c2_d, c1_d * c2_d}, expression} | tail], used}
:mul -> {[{{c1_n * c2_n, c1_d * c2_d}, expression} | tail], used}
:div -> {[{{c2_n * c1_d, c2_d * c1_n}, expression} | tail], used}
end
end
end # 続きだよ
def action_candidates(stepcount_remain, {stack, _}) do
stack_depth = Enum.count(stack)
case stack do
[] -> @nums
[_ | []] -> @nums
_ when stack_depth > stepcount_remain -> @ops
_ -> @nums ++ @ops
end
end
def expand_each_state_node(stepcount_remain, state) do
action_candidates(stepcount_remain, state)
|> Enum.map(&do_action(state, &1))
|> Enum.filter(fn {stack, used} -> !Enum.empty?(used) end)
end
def step_one_action(stepcount_remain, statelist) do
statelist
|> Enum.map(&expand_each_state_node(stepcount_remain, &1))
|> List.flatten()
end
def run(num_of_cards \\ 4, {target_val_n, target_val_d} \\ {10, 1}) do
(num_of_cards * 2 - 1)..1
|> Enum.reduce(@initial_state, &step_one_action(&1, &2))
|> Enum.filter(fn {[{{lastval_n, lastval_d}, expression}], used} ->
lastval_n * target_val_d == target_val_n * lastval_d
end)
# |> Enum.each(fn {[{ {lastval_n,lastval_d} ,expression}] , used} -> IO.puts expression end)
end
end iex(96)> Make10.run
[
{[{{10, 1}, "(1+(2+(3+4)))"}], [4, 3, 2, 1]},
{[{{10, 1}, "(1*(2+(3+5)))"}], [5, 3, 2, 1]},
{[{{10, 1}, "(1-(2-(3+8)))"}], [8, 3, 2, 1]},
{[{{10, 1}, "(1+((2+3)+4))"}], [4, 3, 2, 1]},
{[{{10, 1}, "(1*((2+3)+5))"}], [5, 3, 2, 1]},
{[{{10, 1}, "((1+(2+3))+4)"}], [4, 3, 2, 1]},
{[{{10, 1}, "((1*(2+3))+5)"}], [5, 3, 2, 1]},
{[{{10, 1}, "(1-((2-3)-8))"}], [8, 3, 2, 1]},
{[{{10, 1}, "(1-((2-3)*9))"}], [9, 3, 2, 1]},
{[{{10, 1}, "((1-(2-3))*5)"}], [5, 3, 2, 1]},
{[{{10, 1}, "((1-(2-3))+8)"}], [8, 3, 2, 1]},
{[{{10, 1}, "(1*((2*3)+4))"}], [4, 3, 2, 1]},
{[{{10, 1}, "((1*(2*3))+4)"}], [4, 3, 2, 1]},
{[{{30, 3}, "((1+(2/3))*6)"}], [6, 3, 2, 1]},
{[{{10, 1}, "(1+(2+(4+3)))"}], [3, 4, 2, 1]},
{[{{20, 2}, "(1/(2/(4*5)))"}], [5, 4, 2, 1]},
{[{{10, 1}, "(1-(2-(4+7)))"}], [7, 4, 2, 1]},
・・・ 分数も対応（数字4つで129/8）
iex(102)> Make10.run(4, {129,8})
[
{[{{129, 8}, "((1/8)+(7+9))"}], [9, 7, 8, 1]},
{[{{129, 8}, "(((1/8)+7)+9)"}], [9, 7, 8, 1]},
{[{{129, 8}, "((1/8)+(9+7))"}], [7, 9, 8, 1]},
{[{{129, 8}, "(((1/8)+9)+7)"}], [7, 9, 8, 1]},
{[{{129, 8}, "((3*5)+(9/8))"}], [8, 9, 5, 3]},
{[{{129, 8}, "(3*(6-(5/8)))"}], [8, 5, 6, 3]},
{[{{129, 8}, "((5*3)+(9/8))"}], [8, 9, 3, 5]},
{[{{129, 8}, "((6-(5/8))*3)"}], [3, 8, 5, 6]},
{[{{129, 8}, "(7+((1/8)+9))"}], [9, 8, 1, 7]},
{[{{129, 8}, "((7+(1/8))+9)"}], [9, 8, 1, 7]},
{[{{129, 8}, "(7+(9+(1/8)))"}], [8, 1, 9, 7]},
{[{{129, 8}, "((7+9)+(1/8))"}], [8, 1, 9, 7]},
{[{{129, 8}, "(9+((1/8)+7))"}], [7, 8, 1, 9]},
{[{{129, 8}, "((9+(1/8))+7)"}], [7, 8, 1, 9]},
{[{{129, 8}, "(9+(7+(1/8)))"}], [8, 1, 7, 9]},
{[{{129, 8}, "((9+7)+(1/8))"}], [8, 1, 7, 9]},
{[{{129, 8}, "((9/8)+(3*5))"}], [5, 3, 8, 9]},
{[{{129, 8}, "((9/8)+(5*3))"}], [3, 5, 8, 9]}
] ちなみにeval使わず分数計算自前だよ
Elixirも楽しい！ Prologって簡単な深さ優先・探索列挙はともかく動的に細かな探索の制御をしようと思うと途端に面倒になるからな
他の言語で書いた方が小回りきくわ、ってなる
実用上、組み合わせの少ない練習問題的な全解探索にしか使えないゆえん ■ このスレッドは過去ログ倉庫に格納されています
