Ruby 初心者スレッド Part 63
■ このスレッドは過去ログ倉庫に格納されています
プログラミング言語Rubyについての、初心者向けスレです。質問・要望・雑談などどうぞ。
質問するときは、OSやRubyのバージョン、エラーメッセージを書いたほうがいいお
Ruby on RailsについてはWEBプログラミング板で
前スレ
Ruby 初心者スレッド Part 62
https://mevius.5ch.net/test/read.cgi/tech/1511451329/
るりまサーチ （リファレンス検索）
http://rurema.clear-code.com/
Rubyist Magazine - るびま
http://jp.rubyist.net/magazine/
逆引きRuby
http://www.namaraii.com/rubytips/ >>675
それ、もうブラウザでも使えるんだっけ？
JavaScriptは新機能を使っていいかどうか、いちいち考えないとイカンのがめんどくさい。
なおRubyも、バージョンのよる差異がうざい模様。 rubyって昔複数引数取る関数
foo bar baz
って書けたよね。
でも今は
foo bar, baz
だよね。 >>681
1.8.7でも foo bar baz は foo(bar(baz)) なんだね >>675
失礼しました、ES2015(ES6)で導入されたアロー関数ですね
ということで、>>670 の：
>・匿名関数の function() は煩わしい
という項目に関しては取り下げます
>>680
調べてみると、主要なブラウザの最新版であれば利用できるようです
まあ JS も Ruby も新機能の扱いを「めんどくさい」とか「うざい」と
感じることはあります
ただし、どちらも「後方互換性の維持」という言語進化の基本原則を
遵守しているのは共通していますから「新機能を使わない」という
選択肢も残されているわけです >>679
情報提供、ありがとうございます
MANGO板にて特定のページが規制されているのではなく、
サイト全体が規制されていることを確認できました
・NGワード絞り込みスレッド★118
http://agree.5ch.net/test/read.cgi/mango/1533547792/324-326/ >>681
昔って、いったいいつの時代なんだろう
自分は 1.6 の時代だからかれこれ20年は使ってるけど、
foo bar baz と書けたという記憶が無い
もしかすると 1.4 とかそれ以前には書けたのかな？
興味深いね >>683
JavaScriptはともかく、Ruby は「後方互換性の維持」を遵守しないぞ。
バージョンアップは、過去のコードをだいたい壊す。
次も、文字列の原則immutable化が控えているだろ。 それはjs以外たいていみんなそうなんじゃ？pythonしかり。 >>168
今どきにbabelも使わずフロント開発してるところなんて業務系SIerくらいしかないでしょ >>688
互換性維持の優先が高い言語はあるぞ。
C,C++,C#,Perl5はずっと更新されてきてるが、過去のコードを壊したことがほとんどない。
RubyやPythonと違って、システムの重要なところを担ってる自覚がある模様。 >>687
>JavaScriptはともかく、Ruby は「後方互換性の維持」を遵守しないぞ。
いや、Ruby は(も？)新機能の導入には保守的ですよ
たとえば Ruby の特徴である既存のクラスの振る舞いを後から上書きできる
オープンクラス、これには利点と欠点が共存してるけど、これに対応しようとする
refinement の提案は「後方互換性の維持」を理由に却下され続けたけど、
その壁を乗り越えてようやく 2.1 で採用された
もしも遵守しない例があるなら、具体的なコードで示してね(>>675 みたいに)
>次も、文字列の原則immutable化が控えているだろ。
え、frozen_string_literal オプションがあるでしょ？
>>688
いやぁ、バージョンアップしたら Hello world すら構文エラーになる Python みたいな
言語などとは一緒くたにされたく無いですね
・Rubyの設計上の欠点とは何か？
https://mevius.5ch.net/test/read.cgi/tech/1413113999/123-126/
Python2 の時点ですら全プログラミング言語でも人気トップ10、スクリプト系言語に限れば
圧倒的に首位を独走というメジャーな言語が、Hello world すら構文エラーになるという
基本原則「後方互換性の維持」を頭から無視したバージョンアップを断行するなんて、
過去のプログラミング言語の歴史を振り返ってもあり得なかった歴史的快挙(暴挙？)ですよ
とうていマイナー言語の Ruby なんかじゃあ到底まねできないですわ >>692
結局、互換を壊してるじゃん。ｗ
そんなのは保守的と言わないんだよ。
多少の不満は飲み込んででも、過去のコードを重視しないといけない。
オプションで選択できるとか、いいわけにならん。
例が知りたきゃググれ。
スコープとかメソッドとかいろいろあって、思い出すのもバカらしい。
ま、それがRubyの道なんだろうから、それはそれでいいんだよ。
ヘンに言い繕わずに、互換性は低いと冷静に受け入れてれば。 現実無視の机上の空論ｗ
昔のC/C++コードを一切の修正なしで再利用できるケースが実際にどれだけあるというのだ >>683
JS のアローと、function()無名関数は、スコープ・this の挙動が異なる
非同期処理などで異なる。
別のもの
JSは、Rubyの影響を受けて、ドンドン変化していく >>693
>オプションで選択できるとか、いいわけにならん。
では、以下のコードを python3 で動かす方法はあるんですか？
https://mevius.5ch.net/test/read.cgi/tech/1413113999/126/
え、オプションすら存在しないのぉ？？？
オプションすら許さない >>693氏のオレ様基準に従えば、
いいわけ以前の「後方互換性の断絶」であり「致命的な互換性の問題」ですね
>例が知りたきゃググれ。
>スコープとかメソッドとかいろいろあって、思い出すのもバカらしい。
え、これだけ「Rubyはゴカンセイガァー」と騒いでおいて、
ご自身では具体的なコードすら書けないんですか？
情けないですね、自分ならスコープやらいくつかRubyに関する
「些細な互換性の問題」を示してあげることもできるんですけど
>ヘンに言い繕わずに、互換性は低いと冷静に受け入れてれば。
いやぁ JS と比較すれば互換性は低いですよ
あちらはECMAScriptという国際標準の強い縛りがありますからね
でも Hello world すら動かなくなる最底辺 Python と比較すれば遥かに高い
そもそも具体的なコードも示せないくせに、
ナゼか「上から目線で」オレ様理論を押し付けるのは、
Rubyアンチに共通する性癖ですね Selenium WebDriver を使って、Nokogiri で、DOM を構築して、
JavaScript(JS) を使って、そのDOMで、body 以下を更新しようとしたが、エラーになる
つまり、DOMの構築には、JSではなくNokogiriを使った。
なるべく、JSではDOMを構築したくない。面倒だから
p inner_body = %(<div class="thread">あ</div>) #=> "<div class=\"thread\">あ</div>"
jsCode = <<"EOT"
var element = document.querySelector('body');
element.innerHTML = "#{ inner_body }";
EOT
driver.execute_script jsCode # JavaScript を実行
ただし、下のように書くと、body以下は正常に更新される。
element.innerHTML = '<div class="thread">あ</div>';
違いは「\"thread\"」の、ダブルクォーテーションのエスケープなのかな？
Nokogiriで構築したDOMを、JSにどうやって渡せば良いのか？ > Nokogiriで構築したDOMを、JSにどうやって渡せば良いのか？
うん、でもいま面倒なことになってるよね？ >>697
Rubyアンチアンチは、だからめんどくさいんだよな。
そんなに必死にならんでもええよ。ｗ それがルビリスト
皆呆れてるだろうが
個人的にすごく良い流れなので
もっと頑張れ 一言で言えば左翼と同じメンタル
何故そうなるかは長くなるから書かないけどな p inner_body = %(<div class="thread">あ</div>) #=> "<div class=\"thread\">あ</div>"
以下は、jsCode を、puts, p したもの
(A) element.innerHTML = "#{ inner_body }"; の場合
var element = document.querySelector('body');
element.innerHTML = "<div class="thread">あ</div>";
"var element = document.querySelector('body');\n
element.innerHTML = \"<div class=\"thread\">あ</div>\";\n"
(B) element.innerHTML = '<div class="thread">あ</div>'; の場合
var element = document.querySelector('body');
element.innerHTML = '<div class="thread">あ</div>';
"var element = document.querySelector('body');\n
element.innerHTML = '<div class=\"thread\">あ</div>';\n"
A は、" の対応が崩れるから、ダメ。
一方、B は正常に処理される
どうやれば、変数をBのように展開できるのか？ p inner_body = %(<div class="thread">あ</div>) #=> "<div class=\"thread\">あ</div>"
以下は、jsCode を、puts, p したもの
>>706 の、
(C) element.innerHTML = '#{ inner_body }'; の場合。
>>705 の(B) と全く同じになった！
var element = document.querySelector('body');
element.innerHTML = '<div class="thread">あ</div>';
"var element = document.querySelector('body');\n
element.innerHTML = '<div class=\"thread\">あ</div>';\n"
"#{ inner_body }"
'#{ inner_body }'
まさか、シングルクォーテーションで変数展開できるとは！
神！ 5ch ブラウザみたいに、スレに書き込んである画像のURL を、
自動的に、<img> に展開して表示するものを自作している
Selenium WebDriver を使って、Nokogiri で、DOM を構築して、
JavaScript(JS) を使って、そのDOMで、body 以下を更新しようとしている
わざわざ、Sinatra, Vue.js などを使うまでもない。
標準添付ライブラリのERB は、使っても良いかも Action Cableを使用してるアプリってもうある？ BIOSが夏時間に対応していると、OSの時刻までずれてしまう
これ比較的最近の話だからな
http://naitaku.hatenablog.com/entry/2017/04/06/012238
> RTCにはタイムゾーンや夏時間を扱う仕組みは一般にはありませんので、
> OS側でタイムゾーンや夏時間を管理することになります。
> (実はRTCに夏時間を扱う仕組みがあって誤発動したというのが今回の原因なのですが）
> RTC の Daylight Savings Enable (DSE) という機能について
> 現代のOSでは上で述べたようにタイムゾーンや夏時間を管理しているのですが、
> 昔（DOSとかの時代？）はOSはそんな賢い機能はなくRTCの時刻がそのままローカルタイムでした。
> そんな時代に夏時間を扱うためにハードウェア的に実装されたのが DSE という機能です。
> またブコメで「日本のタイムゾーンにしていれば夏時間は自動的にオフになるはず」というものがありましたが、
> DSEの設定値はOS上の夏時間の設定とは無関係です。OSは上で述べたように夏時間を管理していますので
> RTCが勝手に1時間進んだり遅れたりすることは想定していないはずです。
> したがって現代のパソコンではDSEは無効になっているのが正しいです。 p inner = %(a"あ"b) #=> "a\"あ\"b"
outer = <<"EOT"
'#{ inner }'
"#{ inner }"
'X'
"Y"
EOT
以下は、outer を、puts, p したもの
'a"あ"b'
"a"あ"b"
'X'
"Y"
"'a\"あ\"b'\n
\"a\"あ\"b\"\n
'X'\n
\"Y\"\n"
つまり、#{ inner } だけが変数展開されているだけ。
ヒアドキュメント内の、', " は、そのまま表示されているだけだった Ruby FFIを使ったエクステンションの作り方
http://kazegusuri.hateblo.jp/entry/2014/03/02/192729
FFI(Foreign function interface)
コンパイルがいらない、多言語を呼び出すためのインターフェイス
RubyにおけるFFIは、libffi
こんなのがあるのか
Windows で、クリップボード機能を使おうとして、
win32-clipboard gem の文書を見ていて、FFIを見つけた だからなんだよいちいちうるせえな
リファレンス全部読んでこい str.chomp!.strip!
末尾の改行を削除して、先頭末尾の空白を削除するのを、メソッドチェーンで書いたけど、
chomp! は、改行がない場合に、nil を返すのでエラーになる
メソッドチェーンに出来ないから、分けて書くしかない
str.chomp!
str.strip!
nil を返す可能性があるものは、メソッドチェーンに出来ない 拡張子で、画像ファイルかどうかを判別する際に、
大文字の拡張子を、downcase で小文字に変換して判別していますが、これで良い？
それとも、String#casecmp を使う方が良いの？
どう書けば良いの？
file_extname = ".JPG"
# . を削除して、小文字にする
file_extname.delete!(".").downcase!
extnames = %w(png jpg jpeg gif) # 画像の拡張子
extnames.include? file_extname # 含まれている？ >>717
str = " \tfoo\t \n" #=> " \tfoo\t \n"
str.strip! # => "foo" >>719
file_extname.delete!(".").downcase! は
file_extname.delete!(".")&.downcase!
とでもしないとfile_extnameにドットがない時にエラーになる
ドットから始まることが分かってるなら
hoge = file_extname[1..-1].downcaseとでもすべきだし
ドットから始まることが分かってないなら
file_extname[/\.\K[^.]+$/]的なことでもしないとだめ
そもそもfile_extnameを破壊的に変更するのがそもそも気持ち悪い
extnames = %w[jpg gif png]
path = '/hoge/fuga/hage.jpg'
file_extname = File.extname(path)
extnames.include?(file_extname[1..-1].downcase) if file_extname[0] == '.' ていうかこのくらいの処理なら正規表現で書くわ
files = [
'/hoge/fuga/piyo.jpeg',
'/hoge/fuga/piyo.piyo.JPg',
'/hoge/fuga/png',
'/hoge/fuga/gif.txt'
]
files.each {|f| p f.match?(/\.(?:jpe?g|gif|png)\z/i) }
#=> true
true
false
false Ruby de GUI for Windows
RScript(ActiveScriptRuby)→良くも悪くもHTA、要インストール、最新版に追従していない
wxWidgets(wxRuby)→高機能、環境構築が面倒、機能によっては罠があったり不安定だったり、コントロール類のデザインに手間がかかる
Tcl/tk(Ruby/Tk)→導入が容易、機能面はwxRubyに劣る、コントロール類のデザインに手間がかかる
fiddle(WindowsAPI)→何でもできる、配布サイズが小さい、茨の道
(Webブラウザ組み込み型→現状なし？、出てきたとしても配布サイズの肥大化は不可避) 拡張子発明したやつ天才だわ
名前にファイルの種類を埋め込むとか一見ダサそうだけど理にかなってる
一方でマックバイナリは糞だわ 拡張子の何が凄いって
あくまでそれが何であるか種類を表しているだけで
どう扱われるかはOSの設定次第ってところ
これがRubyみたいな古い考えの頭のやつがやると
ファイルは自身がどう扱われるべきか知っているべき
とかアホみたいなこと考えだして
マックバイナリみたいな糞が出来上がる
だが実際には拡張子ぐらいが一番使いやすい >>721
>file_extname.delete!(".")&.downcase!
&. こういう演算子が出来たのか
Ruby の &. と #try の違い
http://secret-garden.hatenablog.com/entry/2016/09/02/000000
Ruby 2.3 で、Safe Navigation Operator(&.)という新しい演算子が追加された >>729
メタプログラミングのため
ソース上に現れる変数名やメソッド名とかってソースを解析する時点で全て把握できてるわけだから、
それを予め数値に置き換えてしまうことで効率よく扱おうという伝統的なコンパイラ技法があるんだけど、
Rubyはメンバ検索の動作を独自に定義できたりするので、その置き換え後の数値をRuby上のデータとして扱えなければならない
そのために用意されてるのがシンボルオブジェクトでありシンボルリテラルである
一方で、数値じゃなくて変更不能な文字列を使えばそんなもん要らなくね？という説もあって、実際Matzもそうすべきだったと失敗を認めている
というわけで、今となっては変更不能でちょっと不便な文字列のようなもの、以上の意味はない ちなみにRails専用DSLに成り下がって以降のRubyではRailsの影響でシンボルをキーにしたHashを引数に渡すということがよく行われるけど、
これはクォーテーションより:の方が書くのが楽だからとか、
文字列よりシンボルをキーに使ったほうがハッシュの検索が速いと信じられていた(今のRubyではこれは正しくない)からといった
あまり本質的でない理由によるもので、シンボルじゃなくて文字列でも何の問題もないよ >>729
不変性と同値時の同一性が保証された文字列は便利でよく使うから
不変だと特にハッシュのキーとして安全に運用できる
多数出現する同値を同一にできるとメモリが節約できる ＞シンボルじゃなくて文字列でも何の問題もないよ
うわあああああｗ frozenになるだけでオブジェクトは別に作られるのかと思ったらこれじゃ本当にSymbolと変わんねえなｗ
でもSymbolもなんだかんだ好きだけど
ruby --enable=frozen-string-literal -e 'p 1000.times.map{"foo".object_id}.uniq'
#=> [20966820] あもともとfrozenな文字列は使いまわしてたのか
$ ruby --disable=frozen-string-literal -e 'p 1000.times.map{"foo".freeze.object_id}.uniq'
[20983260] >>733
MatzがしれっとSymbolをStringのサブクラスに変更しようとしたの知らんのか
結局互換性の問題でMRIメンバーから大反対されて却下されたけど、
今Rubyを完全に再設計するならまず間違いなくシンボルリテラルは単なる文字列になり、Stringは常に変更不可になる
Railsのパフォーマンス改善のためにRubyに導入されたシンボルGCなんて、
それこそ本来のシンボルの意味からすると全く必要ないはずの馬鹿げた機能だ
もはや誰が見てもSymbolは事実上単なる文字列 最下位bit使って
整数の範囲を減らしてまで
シンボル空間作ったのに
互換性無いですかそうですか >>731
>メタプログラミングのため
後半の内容とは何ら関係しない
覚えたてのメタプログラミングって単語を使いたいだけちゃいますか
>Railsの影響でシンボルをキーにしたHashを引数に渡すということがよく行われるけど、
Railsで最初にRubyに触れた人にとってはそう感じるだろうけど、
ハッシュのキーとしてシンボルを使うのはRails以前から普通だったよ
>>736
>Railsのパフォーマンス改善のためにRubyに導入されたシンボルGCなんて、
シンボルGC導入のきっかけは(ブルートフォース攻撃に対する)セキュリティ対策だよ
パフォーマンス改善のために導入された文字列のfrozenデフォ化とごっちゃにしてる >>736
ヤツはホンマ互換性を軽視する輩やな。。。 Selenium WebDriver, Nokogiri を使って、文字列からHTML を作って、
それをJavaScript で実行して、DOM を更新しているけど、
こういう原始的なやり方で良いのかな？
もっと、ERB とか、Vue.js みたいな、UI コンポーネント指向の書き方はできないのかな？
doc = Nokogiri::HTML(driver.page_source)
content_wrapper = doc.at_css("#content") # 全体の枠
# 画像ノード
img_wrapper_str = <<"EOT"
<div class="img_wrapper"><img></div>
EOT
picture_urls.each do | pict_url | # 画像のURL
img_wrapper = Nokogiri::HTML::DocumentFragment.parse img_wrapper_str
img = img_wrapper.at_css "img"
img.set_attribute('src', pict_url) # 属性
img_wrapper.parent = content_wrapper # 親
end
jsCode = <<"EOT"
var elem = document.getElementById("content");
elem.innerHTML = '#{ content_wrapper.inner_html }';
EOT
driver.execute_script jsCode # JavaScript を実行 すいません、プログラミングの世界に最近初めて入ったんですけど
C++やろうとしたら別のスレでRubyとjava勧められたのでやろうと思ってるのですが
Rubyはプログラム初心者に向いてますか？
それと実行環境はVisualStudioを使えますか？
この２点教えてください >>742
Rubyは開発陣がWindowsアンチばかりでWindowsとRubyは極めて相性が悪い
初心者云々以前に、Macに乗り換える気がないならRubyは論外
WinでスクリプトならPythonにしよう
絶賛落ち目中のRubyよりよほど将来性があるし初心者にもわかりやすいしWinで使いやすいしVisual Studioでもサポートされている アホか初心者が戯れにやる程度ならrubyもpythonも大差ねえよ RubyInstaller for Windows がある。
エディタは、VSCode
ただし、Windowsで、irb を使うと、日本語でバグるから、
irb だけは、Windows10 なら、WSL でLinux(Ubuntu)側から使う
paiza.IO, codepad などのサイトで、ブラウザからプログラミングするのが簡単。
他には、progate という学習サイトもある
環境構築には、数十のLinux コマンドも覚えるべき。
絶対・相対パス、環境変数PATH の仕組みなども知らないと無理
ruby -v
例えばこういう、ruby のようなパス無しのコマンドを入力すると、
どういう仕組み・順序で、PC 内から、そのコマンドの実行ファイルのある場所を探し出すのか？
つまり、こういうOS の知識がないと、
コマンドプロンプト・PowerShell などのシェルを使えない
ほとんどの人は、これらの勉強ができず環境構築ができないから、
環境構築のいらない、Excel エンジニアになるしかない！
つまり、プログラマーにはなれない人！ >>742
C++ をやるんだったら Java にすればいいと思います >>743
そうなんですか。Win10使ってるんですけどやめたほうがいいですか...
別スレでC++始めるならまずたのしいRuby 第5版、2016 とスッキリjavaやってからにしとけって言われたので
聞いてみたのですがあまりよろしい選択ではなかったですか。
色々調べてみるとrubyは簡単な言語の上位にランクインしてたので覚えやすいのかなって思ってたんですが
PythonはVisualStudioで出来るんですね。いいこと教えていただきありがとうございます。
>>745
一応VisualStudioでRubyもやれるんですか
LinuXはOS?ですか？あまり良くわからないんですが、かなり敷居は高そうですね……
paiza等もブラウザで出来るみたいなんですが入力とかクラスとかの機能が使えないみたいで
色々不自由しそうで、なるべく実行環境整えたいのですが、今の段階では厳しいですか。
教えていただきありがとうございます。 今の覚えるならpythonの方がいい
悪いことは言わない勝ち馬に乗れ ＞paiza等もブラウザで出来るみたいなんですが入力とかクラスとかの機能が使えない
そんなことはない普通に使える
実行環境構築に自信がないならブラウザコンソールからJavascriptやっとけ >746
別スレで教えていただきjava環境導入出来ました。ありがとうございます！
せっかくお勧めの入門書２冊教えてもらったので両方の言語やろうかなって思って聞いてました
少しでもC++の理解が簡単になるならやっとこうと思ったんですけど無意味ですかね >>748
そこまで本格的にやる予定ではなくて,
別スレでプログラム０から始める奴がC++からやっても理解できない。
たのしいRuby 第5版、2016 とスッキリ分かるjavaやってからにしろ！って言われて
少し遠回りしてでもやろうと思ってたんですが、今聞いた感じだとあまり入門者がやる言語ではないみたいですかね…
pythonとjavaとりあえずやってみます。ありがとうございました C++やるつもりならなおさらPythonがおすすめだな
Pythonは設計思想が比較的C系に近いからC++やJavaにも馴染みやすいよ
RubyはRubyが最高だと信じて閉じ籠って他の言語やりたがらない人が多い 「たのしいRuby」「スッキリjava」は薦めたのは、俺だよ
Windows のユーザー・システム環境変数の設定画面を使えないと無理。
この画面の環境変数PATH を、穴のあくほど見つめる。
新しく何を追加したのか
絶対・相対パスの違い。
これがわからないと、VSCode で、PowerShell から実行できない
cd, ls などの、基本的な20ぐらいのLinux コマンドも覚えるべき。
PowerShell でも、そのまま使えるから。
例えば「cd ..」これの意味がわからないと、PowerShell を使えない。
コマンドプロンプトはややこしいから、なるべく使わない方が良い
C++ なんて、5年以上先の話。
環境構築できないと無理
paiza.IO, codepad などのサイトで、ブラウザからプログラミングするのを薦める。
progate という学習サイトで学習する人も多い 「たのしいRuby」「みんなのPython」「スッキリjava」の3冊を読めばよい
「たのしい・みんなの」の2冊は双子。
ただし必ず、たのしいから読むこと！
みんなのから読むと、わからないから苦戦する
ただし、みんなのは、AI・機械学習しない人には、無駄が多い。
ウェブ系なら、たのしいRuby
HTML, CSS, JavaScript も必要 今からJavaをするくらいなら、C#をしたほうが一億倍はいいと思うが。
とくにWindowsなら。 >>742
プログラミング言語は道具だ。道具を使って何をしたいか(目的)が重要なのではないのかな
逆に目的が決まれば適したプログラミング言語も自然と絞られてくる
なんとなくならメジャーなのをやっておけとしか・・・ 例えば、C++ のロベールを読むよりも、
「たのしいRuby」「みんなのPython」「スッキリjava」の3冊を3回読む方が、
はるかに速く読めるし、得るものも大きい。
50時間もあれば、全部読める
一方、C++ で50時間使っても、ほとんど何も作れない。
やってみればわかるけど、時間の無駄
C/C++ などポインタがある言語は、すぐにバグるから、すごく時間を損する https://rubyinstaller.org/
Ruby Installer を使うなら、2.4 系を使う。
2.5 系は、まだ新しいから使わないように
irb は日本語でバグるから、使わないように。
使うなら、WSL でLinux(Ubuntu)側で、irb を使う
VSCode もインストールして、Rubyの拡張機能も入れてみれば？ 環境変数がわからないのはともかく自分で調べて理解できないレベルなら諦めろ web上では見たことあるけど
出版物上で観るのは初めて感 言語の初心者用の本は、PCの初心者用の本じゃない！
言語の本はあくまで、その言語を知らないだけで、
環境変数とか、絶対・相対パスとか、cd, ls などの基本コマンド、
PowerShell の使い方などは、知っている事が前提
こういうOS の知識を、教えている本はない。
それを書けば、言語を説明するページが減るから、書かない
つまり言語の本は、PCの初心者を対象としていない！
既に、OS の知識はあって、その言語だけを知らない人向け 762 みたいな本を書いている奴は、勉強を何もわかっていない。
なぜ生徒が、プログラミングを嫌うか
言語には、勉強する順番がある。
小学生にいきなり、大学教育をしても無駄。
小中高大学と、個人の成長には、勉強する順番が重要。
知識を下から、積み重ねていかないといけない
1. 動的・軽量言語
Ruby, Python, JavaScript
2. 静的言語
Java, Kotlin, C#
3. ポインターのある言語
C, C++
今の大学教育では、C から教えているから、皆プログラミングはしょーもないってやめる。
これは、Rubyの女神・女優の池澤あやかが言ってる >>768
教養時代に必修科か準必修科目でRubyやったぞ
薬学とか農学部進学予定の奴までやってたのはかわいそうだったけど >>753
つまり、Python信者は他言語スレまで出張してPython推しするほど必死だと >>769
今日日、農学志望の人はRubyくらい使う機会があるかもね。
集計統計とか農業IoTとかで。 ラズパイでは、Python も良いけど
ウェブ系では、Ruby が強い。
Rails から、Vue.js, React も使える >>770
言語なんか複数使えて適宜使い分けられて当然でしょ >>743
つまりPython推しのためであれば、他言語スレでの荒らし行為も正当化されると
いやあPython信者って怖いですね アンカミスを訂正：
X：>>743
O：>>776 俺はPythonよりRubyの方がずっと好きだけど
（Railsプログラマーを目指してるんでもなきゃ）
これから何か始めようって人には断然Pythonを薦めるし
自分のお気に入りだからってむやみにRubyを薦める奴の見識は疑うね ■ このスレッドは過去ログ倉庫に格納されています
