ぶっちゃけ始めるのにいい言語て何 part7
■ このスレッドは過去ログ倉庫に格納されています
>>446
君が初心者に対して、プログラマで行くのなら
こんなことも知っといたほうがいいよっていうのを
君が初心者に教えられる言語 言語でできることは、ほぼ同じだけど、
そこに各言語特有の開発環境やライブラリ(フレームワーク)とかを入れちゃうとややこしくなる >>446
アセンブラとかFORTRANとかCOBOLとかPascalとかHaskellなんて仕事ろくにないので無視して問題なし あわしろ氏がお勧めする数学志向プログラミング言語Haskell。 >>449
機械語・アセンブラ・マクロアセンブラという系列は、
C とか C++ につながるのでちょっとは齧っておくといい。
Fortran とか COBOL とか Pascal とかは、
最近は Java で代替可能だけど、そのせいで Java の
言語仕様が取っ散らかっちゃった部分がある。
Haskel はトランプとか麻雀とかのゲームプログラミングに
向いているかもしれないが、それ以外に業務に使うケースは
あまりないな。
「向いている」とはいっても、余所見やら目配りやらを含めて
いうと、「それ一択!」という言語はないな。 >>423
基本、Bootstrap, ElementUI, Tailwind などの各コンポーネントは、
コピペして、カスタマイズする >>446
基本的にCやっとけば問題無いけど
重要なのは言語そのものじゃなくて
OS(ファイルシステムや入出力やプロセスやその他)とその周辺の技術
そっちをおろそかにしてる限り入門教科書レベルのプログラムしか書けない 中学生以下の若者は数学志向プログラミングに慣れておくべき。
あわしろ氏がお勧めするHaskell。 そんなことしたら
数学脳に育ってない子供が数理判断に苦手意識を持つ
そんなバカげた主張はするな、幼児教育も知らんで言うな
子供は環境や成長段階がそれぞれ違う
基礎教育はそういう観点からするもんなんだよ
子供には、まずは論理思考を育む
プログラミングは好き好きにすればいい 子供にゆくゆく数学的思考させたいなら普通に算数やれって話だわなw そこでHaskellの素晴らしい特徴である型クラスやモナドからプログラミングにおいて美味しい部分だけを上手く取り込んだ言語Rustがオススメです もっとかなり成熟したらRustでも良いよ
Rustだけ学んだ初学者なんてどうにもならん HaskellもRustも今話題の教え魔がいるから気を付けてωωω もうみんなGoogle様が全部教えてくれるから人はいらんのか C言語勧める人が多くいるみたいだけど、それだとオブジェクト指向プログラミングが
身に付きにくいという欠点がある 初プログラミング言語がRustで成果物作れる初心者がいるなら
どうにでもなると思うがな
他言語習得とか余裕だろ なんだかんだ言ってやっぱCだな
これやっとけば潰しが利く まあ最初は手続き型から入った方が挫折する確率は低くなるな、確かに
取り消すわ、「時間に余裕がある人が最初にやるなら」Cなどの手続き型言語が
いいかな 必ず習得できるってのを前提で話すのと
初心者が挫折しにくいってのを考慮するのとは違ってるわな
ほとんどの人がプログラミング言語は挫折するんだから
この板に居るやつらはある意味選ばれてる 挫折するってのは適性がなかったってだけだろ
プログラムだけじゃな技術職も一緒
技術的な事を覚えるには時間がかかる それを適性が無いやつでも派遣みたいな形で使おうとするから無理が出る
某銀行みたいに >>465
> ほとんどの人がプログラミング言語は挫折するんだから
その微妙におかしい日本語はなんとかならんのか… >>461
オブジェクト指向大好きならSmalltalk
とかね >>455
> 数学脳に育ってない子供が数理判断に苦手意識を持つ
言いたいことはよく分かるし賛成もするが、多少の誤解もあると思う。
日本語で「数学」というと、「純粋数学」を指すんだよね。
だけど、本来の「数学」には純粋数学以外にも数学基礎論とか
計算数学というものがあって、プログラミング言語というのは
計算数学寄りなので、他の二つよりよっぽど歴史が古い、というか
もう史料が残っていないくらい昔から存在する。
いわゆる「数学」に属す純粋数学や物理数学や数学基礎論なんていうのは、
近世以降に登場した「若造」でしかなく、二十世紀に入ってようやく
襁褓が取れた程度の学問でしかない。
そういう観点からいうと、「算数よりも数学のほうが上」みたいな
差別をなくすのがまず課題だと思う。 例えばHaskellでの数学の圏論(モナド)の仕組みをRustが採り入れて応用例の一つが
>>184のthrow/catch例外処理を無くして代わりに"?"オペレーターで機構も表記も簡潔にしたものです
つまりプログラミング手法&機構そのものにも大きく影響を与えているのです 言いたいことはさっぱりわからないから誤解も賛成もへったくれもない try-throw-catchという特別な枠組みを持ち込まなくても、同等の処理を複雑な記述することなくプログラミングできるようになったRustは凄いですけど、大元のモナド(圏論)を知らずとも成果を享受できる点が良いですね。 その、君たちの捏ねて捏ねて暗黒になるほどに
捏ねて捏ねていくのって性格なの?
なんかすっごいネットりしたものが
肌にべったりくっついてしまった感を感じ得るのだけれど 代数的にはEitherモナド型の一種だけど
Rustでは値付きEnumすなわちタグ付きユニオンで表現されているからね
それにより正常時返り値T型とエラー時返り値E型を包み込んでResult<T,E>型としている ひとこと言わせてもらうと、
そういった議論は非常に興味深いんだが、
「ぶっちゃけ始めるのにいい言語て何」というスレッドで
議論するような話題ではないように思う。
別スレを立てて、そっちに誘導したほうが
生産的なんじゃないだろうかと思う。
たとえば、「これからプログラミングを始めたいと思っているひとに、
何を学んでほしいか」みたいな話(上から目線で申し訳ないが、
世代が古いので、そこは経験値としてご勘弁・ご容赦いただきたい)
で、なんとかならないかと思う。
なんか、適当なスレタイはないか? これでいいんじゃね?
「初心者には絶対お勧めできない言語や方法や手段を勧めているヤツを晒すスレ」 >>475
代数的データ型ってRustでは何っていうんだっけ?
単にRust界ではEnumで通ってるんだっけ?
とおもってぐぐってみたら…
https://doc.rust-jp.rs/book-ja/ch06-00-enums.html
> 列挙型は、enumとも称されます。
> (略)
> enumは多くの言語に存在する機能ですが、その能力は言語ごとに異なります。
> Rustのenumは、F#、OCaml、Haskellなどの、 関数型言語に存在する代数的データ型に最も酷似しています。
なんだよ「酷似しています」ってw
代数的データ型とは言い切らずにあくまで列挙型なんだな あわしろ氏がお勧めする数学志向言語Haskell。 >>478
普通のプログラミング言語のenumは列挙された定数に過ぎないけど、Rustのenumは複数(0個以上)の任意の型の変数(または定数)を構成要素に取ることが出来、またパターンマッチングも可能なことから、代数的データ型と明言してよいかと思います。
一般的に、直和(型指定値付enumまたはタグ付union)と直積(struct)を組み合わせることで多彩な代数的データ表現をすることが出来ますが、Rustはそれを満たしていますね。 配列にマイナスのインデックスを指定できない時点でRustはPythonの代わりにはならへんわな >>481
それはPythonやRubyの仕様がおかしくてPythonやRubyがダメな言語であると結論が出ている話
【プログラミングのミスを見逃す】
・配列のインデックスがプログラミングミスで範囲外の負の数になったのか意図的に最後の要素からインデックスしたいのか区別がつかない
・そのためほとんどのプログラミング言語では範囲外のインデックスはエラーとなってくれるので負の数だと最後の要素からインデックスすることはない
【インデックスに正しい負の数を使えなくなる】
・インデックスの開始を負の数に指定できるプログラミング言語も多数あるため負の数だと最後の要素からインデックスする仕様があると矛盾してしまう
・C言語では配列のインデックスは常に0スタートだが配列アクセスにポインタを代わりに使えるため負の数のインデックスが範囲内のこともあるし範囲外だとしてもそのアドレスの値となる >>483
配列にマイナスのインデックスを指定して後ろからアクセスできる言語
Perl, Python, Ruby
できない言語
Ada, BASIC, C, C++, C#, COBOL, D, Java, JavaScript, Julia, Lua, Lisp, Fortran, Go, Haskell, Nim, Objective-C, OCaml, Pascal, PHP, Rust, Scala, Scheme, Swift >>486
それらPerl, Python, Rubyはダメな仕様のプログラミング言語です 俺が初心者に勧めるならpythonだな。数時間あれば物体追跡までやれるから面白いと思うよ。 >>486
その中でカスタムサブスクリプティングをサポートしてる言語は? >>487
「unsigned int」とか「unsigned long」という型宣言がない言語は
フツーにあるだろ?
>>486 の
> できない言語
> bAda, BASIC, C, C++, C#, COBOL, D, Java, JavaScript, Julia,
> Lua, Lisp, Fortran, Go, Haskell, Nim, Objective-C, OCaml, Pascal,
> PHP, Rust, Scala, Scheme, Swift
というのは、どこかに誤解があると思う。 御指摘が多数あったので書き直しました
配列にマイナスのインデックスを指定すると配列の最後からアクセスできてしまうダメな仕様>>483となっている言語
Perl, Python, Ruby
それ以外の言語
Ada, BASIC, C, C++, C#, COBOL, D, Java, JavaScript, Julia, Lua, Lisp, Fortran, Go, Haskell, Nim, Objective-C, OCaml, Pascal, PHP, Rust, Scala, Scheme, Swift >>493
何を言ってるのかよく分からないが
VB.NetやC#は普通にUIntやULongがあるぞ。 配列要素のマイナス指定の仕様の話をしているのになぜデータ型の話になるのか... あわしろ氏がお勧めする数学志向言語Haskell。 >>498
それはね
みんながあたりまえにそれを前提に喋ってるのに
それを一人だけ分かってない周回遅れが居るからだよ あぁ、まったくものを識らないというのは怖ろしいことだなぁ ……
南無阿弥陀佛南無阿弥陀佛 ――
「ここは配列の一丁目といって、
OPTION BASE 1を宣言しているので、
0丁目やマイナス一丁目の無ぇ処だ」。
アセンブラや C で配列の添字でマイナスの値を指定していて、
さんざん他人の記憶領域を踏みつぶしてトラップを発生させて
きた報いを今こそ受けるがいい。 >>502
今回はその話がされているのではないです
例えばPythonではマイナスの添字で配列の後ろから数えた要素になってしまうのです
a = [5, 6, 7, 8, 9]
print(a[-1]) # → 9
print(a[-2]) # → 8
print(a[-5]) # → 5
この添字が算出された変数で与えられた時に
プログラミングのミスでマイナスとなった場合と意図的に後ろから数えたい場合で同じこの結果となって区別できないため
プログラミング言語としてはPythonは悪い仕様だと言われている話です
さらに添字の開始を0ではなく任意の整数にできるプログラミング言語もありますが
このPythonの悪い仕様だと開始をマイナスの整数とした場合に困りますね 後ろからやりたい時には長さから引くとかやらないで済むんだから
それで書く時には楽な分気をつければ良いだけの話
だいたいPythonなんて軽くサクサク書く時にしか使わないんだから
どこの現場のどういう状況でそれ問題になったの? >>502
もう一つ
おっしゃってるC言語の場合だと配列もポインタとして扱われますので
意図的に添字をマイナスにして便利に使うことも多いですよ
例えば
int a[5] = {5, 6, 7, 8, 9};
int *p = a + 2;
for (int i = -2; i <= 2; i++) {
printf("p[%d] = %d\n", i, p[i]);
}
これで出力結果は
p[-2] = 5
p[-1] = 6
p[0] = 7
p[1] = 8
p[2] = 9
こうすれば-2から2の範囲で扱うことが出来ます >>505
意図せずに添字の算出結果がマイナスとなった時にエラーとならずに後ろから適用してしまうのはマズイです >>507
別にバグの種類が変わるだけで使い所だよ
書きやすい代わりにバグった時わかりにくいなんてことはこれに限らず
いくらでもあるわけで
何でも柔軟に使えない人はプログラマ向いてないよ Pythonは機械学習やった時に半年ほどしか使ってないがマイナスでバグったこと
一回もないしむしろその範囲では書きやすくてよかったよ
JSのダックタイピングとかだって動かすまでエラー出ないけど書きやすいし
Javaみたいにタイプがきっちりしてれば多少面倒くさいけどコンパイルで
エラー出るし読みやすいし大概の事はどっちが正しいじゃなくて状況次第 ほとんど全てのプログラミング言語では、Pythonのような変な仕様になっていない、これが答えだ。
プログラムの安全性の視点では、プログラミングの間違いでインデックス変数が負の数となった時に、Pythonのような変な仕様ではエラーとならずに間違った要素を指して通ってしまう。
プログラミング言語の拡張性の視点では、インデックスに負の数を用いることができるようにすると、この変な仕様とぶつかってしまう。
これらの理由から、ほとんど全てのプログラミング言語では、Pythonのような変な仕様を採用していない。 >>508
論理が通じる相手かどうか文章から判断できないようなら
君もプログラマに向いてないぞ >>510
ほとんどとか関係ないんだよね、言語って必要な人がいるから作られるわけで
実際使ってみて便利だったしマイナスでバグったこともないけどあなたは
具体的に仕事で使ってどういう状況で問題になったの?
>>511
それこそどういう論理だよw >>510
ふーん
Pythonの配列のインデックスをマイナスで指定したときって面白い挙動をするんだね
まるでアセンブラで符号を見ないでインデクスレジスタをオーバーフローさせて参照させたときみたい 後ろから取る作業が多くなると毎回いちいち長さから引いてとか
誰でも面倒くさくなるからね
他は知らんけど機械学習でデータの切り張りばっかりみたいな時には
便利だったし他にも便利な状況はいくらもあると思うよ なぜ、ほとんどのプログラミング言語では、Pythonのような変な仕様を採用していないのか?
有用ではなく、有害であるためだ。 インデクスの値を即値で-1のように書かずに計算して求める場合、符号などの妥当性ののチェックはやるんじゃないかな そうだわな
そもそもマイナスにしたくないならマイナスのチェック入れれば良いだけで
マイナスのチェック入れるのが面倒くさいのか、長さから引くのが面倒くさいのか
長さから引く事が多ければマイナスで後ろからのが楽だし逆なら逆だし
Javaでマイナスで後ろから取りたいなって思った事はそんなにないし
状況次第 >>516
インデックスの開始値をプログラマーが指定できるプログラミング言語では、もちろん負の数のインデックスも扱えるが、Pythonのような変な仕様では有害となる。
それ以外のプログラミング言語においても、インデックスの計算ミスで範囲外となった時にエラーとなってくれる言語が多くを占めるが、Pythonのような変な仕様ではエラーとなってくれず有害である。 >>519
だから「有害」の根拠は?
エラーが出ても変な値が出てもバグはバグだしチェック入れれば済む話だし
どういう仕事でどういう状況で問題になったのかとかガン無視だし
もう君の中では有害なんだろうね、って言うしか >>520
例えばPHPでは、配列のインデックスの開始値が負の数でも扱えるように拡張された。
もちろん、拡張なく最初から、開始値が負の数でも正の数でもプログラマーが指定できるプログラミング言語も多い。
Pythonのような変な仕様では、仕様がぶつかってしまい有害である。 >>506
配列の添字をマイナスにすることは、C言語では規格上認められていないんじゃなかったっけ? 配列の添字として取りうる範囲は、全ての要素および最終要素の次に対応する添字だけだったような気がするけど。
506の例は、単なるポインタを使った演算に過ぎず、配列とは無関係でしょ。配列の要素参照がポインタ演算としてなされるからといって、配列とポインタが同じものになるわけではないよ。混同してない? >>521
個人的にはむしろインデックスの開始が負であってほしいことなんて無いけれども
まあ別にあっても良いけど負であってほしいなら負でできる言語を使えば良いし
後ろから取れる方が便利ならそっち使えば良いし
具体的にどの仕事でどんなコード書いた時にインデックスの開始が負である事が
そこまで重要で「害」というほどの問題が出たの?
非常に些細な問題に思えるが
思い込みの強いスペクトラムの人がプログラマ向いてるみたいな事いう人
いるけど全然向いてないんだよね
数学とかのが良いのでは? そうね
パッとどんなシチュエーションで使えばインデックスがマイナスのとき有用性があるのか思いつかないけど、
スタックエリアも溜め込むときPushを使うとスタックポインタが指すアドレスはマイナスされるとかあるから、どっかで使い道はあるかもね。
弊害としてはちょっと違うかも知れないけど、スーパーマリオで残機増やして128機以上にすると、死ぬとゲームオーバーになる、というのと似ているのかな。
まぁあれの場合は1バイトでも削って作ろうとしていたみたいだから判ってたけど敢えてチェックは入れなかったのかも知れないけど。
機能を理解した上であれば別にそういうもんなんだろう、で片付く話のような気がするよ。 >>509
> Pythonは機械学習やった時に半年ほどしか使ってないがマイナスでバグったこと
> 一回もないしむしろその範囲では書きやすくてよかったよ
それな
これが実際書いてるやつの率直な感想だと思うわ
いろんな言語を切り替えて使ってる奴にとって
使ってる言語の仕様に合せてプログラミングするというのは
なんの恐れることもない当たり前の空気のようなこと
極端に経験が少ないか柔軟性が無い奴は怖いだろうけど >>510
なんで必要かどうかもわからない拡張性で今ここでいい悪いを論じるのかわからんが、
配列参照演算をオーバーライドできるなら問題ないがな。
逆にあんたの論理だと、配列参照演算をオーバーライドできない言語は拡張性の視点で
全部ダメってことにならないかな。 そもそもマイナス指定っ要するにarr.length-nでlengthを省略できるようにしたいってだけだろ
そこまで省略したいかね?って思うけどね
なんつーかここら辺はTDDとセットでやるから許される言語仕様であって、TDDしてないのにこの言語仕様を肯定するのはバグがあった場合の事想定してなさすぎる > 要するにarr.length-nでlengthを省略できるようにしたいってだけだろ
しつけーわ
なんでお前意外とっくに全員わかってることを
いまさら大発見みたいに書き込むんだガイジ
頭悪すぎん? length-nを省略すると良いことと悪いことがあって、
言語的に優先することが違うから、採用したりしなかったりするのかもね。
省略したら、ぱっと見判りにくくなるけど、
Pythonみたいなインタプリタは入力減らすほうが優先、とか。 皆が述べてるように悪い点は3つなのかな
・わざわざ省略するわかりにくさ
・バグでマイナス値になった時と区別がつかない
・インデックス範囲を自由に指定できる仕様とバッティング
だから多くの言語では採用していないのもわかる
結果としてPythonやPerlなど異端な言語のみが採用って感じ? サイズが n だと添字(そえじ)は 0 から n-1。
そんなわけで、添字で指定すると、要素は mod n。
数学的にはなんの問題もないのだが、実務に携わっている
システム屋としては、「範囲外参照なんだから例外くらい
投げろよ」と思う。
「だって、仕様書通りに実装したんだもーん」みたいな
アホがいた時代があった、という話だろうな。 ぶっちゃけ「始めるのにいい言語」というスレタイからするとその辺はどうでもいい範疇だと思うけどね >>522
C はそもそもシステム開発用の言語なので、
そういうことができないとダメなんだわ。
「右の値と左の値」というのがあって、
代入記号というのは「向かって左のアドレスに、
向かって右の値を転写する」というのが基本だった。
「バイト数が合ってたらなんでもあり」でないと、
システムプログラム(OS)は作りづらい。
そこは、アプリケーションプログラムの開発と
システムプログラムの開発では、違う部分があると思う。 >>522
Cでは負のインデックスもあり
さらにa[b]形式の時に配列とポインタの区別なし
さらにはポインタとインデックスも対照で入れ替え可能
*(a+b) = a[b] = b[a]
これがC言語 >>523
自閉系スペクトラム障礙の私が敢えていいますよ。
C のルーチンで、バイト列の値を返すときに、可変長だったら
こっちでバッファを用意するでしょう?(もちろん、
alloc した領域の中で処理して、free する前に確保した領域ですが)
そこを上位にルーチンが掻き潰すと、「うちの領域で起きた不具合」に
なってしまうんですよ! 「このクソ忙しいときに、上位会社のケツとか
拭いているヒマはねぇんだよ!」と思うんですが、とにかくシステムが
動かなかったらテストもできない。そんなわけで、障害切り分けをして
レポートを上げたら、「次からは気をつけてね」とか。
襁褓も取れていない小便臭い(プログラミングの何かも知らない)
ひいひいたもれのガキのお守りは、たぶん SE の仕事ではないと思う。 >>539
おぉ、解っていらっしゃる。
C の配列はポインタと同一視されるので、
++ は「ポインタに対して、sizeof 分だけ
インクリメントする」という意味ではあるし、
sp++ とか --spとかいうのも、スタック操作と
いうものを考えると自然な操作だ。 >>540
Cだと確保した領域を「渡してしまう」のかそれとも「一時的に貸すだけ」なのかの区別がないためどちらがその領域の最終責任を持つのか曖昧になってしまうね
Rustだとそこがはっきりしてるため解放忘れも二重解放も起きないし言語側が全て自動でやってくれるから楽で安全安心 ちなみにC#になるとポインタの概念が消えて
もっとセーフティーなDeregateになったよね。
それを良しと捉えるか悪化と捉えるかは
個人で意見の別かれるところだと思うけど。 deregateって何だよ
delegateの間違いだわ
スマソ >>543
C#はガベージコレクションが有る言語
C/C++/Rustのようなガベージコレクションが無い言語とは話の土台が異なります ガベコレがある言語かない言語かでどうしても考え方が分かれるから、始めるのにいい言語はどっちなのか先に決めてもいいんじゃなかろうか? ■ このスレッドは過去ログ倉庫に格納されています