Ruby 初心者スレッド Part 60 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/04/29(土) 02:01:58.34

プログラミング言語Rubyについての、初心者向けスレです。質問・要望・雑談などどうぞ。
質問するときは、OSやRubyのバージョン、エラーメッセージを書いたほうがいいお
Ruby on RailsについてはWEBプログラミング板で

前スレ
Ruby 初心者スレッド Part 59
http://echo.2ch.net/test/read.cgi/tech/1475394638/

るりまサーチ　（リファレンス検索）
http://rurema.clear-code.com/

Rubyist Magazine - るびま
http://jp.rubyist.net/magazine/

逆引きRuby
http://www.namaraii.com/rubytips/

**デフォルトの名無しさん** · 2017/06/23(金) 13:37:52.68

現実の開発ではきちんとバージョン管理するのでフォルダの構成変更なんかそんなに頻繁にやることではない
だからリポジトリを分けるほどでもないなら気にせずパス決め打ちでいい
独立性と再利用性が高いものであればリポジトリを分けてgemにする

**デフォルトの名無しさん** · 2017/06/23(金) 14:21:13.96

ありがとうございました

**デフォルトの名無しさん** · 2017/06/23(金) 14:40:20.24

rails で、自作ライブラリの、autoload なら、

lib/モジュール名/クラス名.rb
lib/foo/bar.rb

module Foo
class Bar

ファイル名は小文字で、単語の区切りは'_'に変える

class FooBar
lib/foo_bar.rb

**デフォルトの名無しさん** · 2017/06/23(金) 14:43:58.67

>>404
場合によっては環境変数 RUBYLIBにmyfunc等のパスを淹れるのもあり
https://docs.ruby-lang.org/ja/latest/doc/spec=2fenvvars.html

**デフォルトの名無しさん** · 2017/06/23(金) 18:29:59.15

>>400
“終了しない excel application”でググったら出てきたけどこの仕様は罠だろ・・・

**デフォルトの名無しさん** · 2017/06/23(金) 18:31:41.63

馬鹿には無理

**デフォルトの名無しさん** · 2017/06/23(金) 19:09:21.56

>>409
COM経由で起動させてるんなら自動で終了する方がきもちわるい

**デフォルトの名無しさん** · 2017/06/23(金) 19:49:53.85

>>411
自動化処理に使ったプロセスが不要になっても残りっぱなしの方が気持ち悪い

**デフォルトの名無しさん** · 2017/06/24(土) 18:05:14.46

>>404
モジュールファイルへの相対パスなら確定できる場合はrequire_relative。
特定ディレクトリの設定だけなら許容できる場合は、そのディレクトリを$:に追加。

**デフォルトの名無しさん** · 2017/06/24(土) 18:06:46.13

>>412
プロセス自身にはわからんじゃろ。。。

**デフォルトの名無しさん** · 2017/06/28(水) 09:33:18.25

瑕疵担保責任（かしたんぽせきにん）

瑕疵担保責任のポイント

民法改正で事実上期限が「無制限」になった
バグや設計のミスなどは、瑕疵担保責任
納品物に不具合があれば損害賠償を請求される可能性もある
不具合を指摘されたらすぐに行動をとるべし
軽微なミスでも先延ばししない

http://www.atmarkit.co.jp/ait/articles/1706/26/news014.html
http://itpro.nikkeibp.co.jp/atcl/news/17/052601508/?rt=nocnt

改正法では欠陥に気付いてから1年以内にITベンダーに通知すれば、
通知後5年以内は修正や報酬の減額などを求められるとしている

全ベンダーが泣いた民法改正案を解説しようその1
http://www.atmarkit.co.jp/ait/articles/1609/14/news009.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_2.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_3.html

ポイント1：修補や損害賠償、契約解除の期限がなくなる

従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。
条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、
その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、
11年後まで請求可能なのだ。

もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。

**デフォルトの名無しさん** · 2017/06/28(水) 10:47:59.83

366 :nobodyさん 2017/05/29(月) 16:07:39.16 ID:6v4UcGhE
今回の民法改正、ソフトウェア受託開発の場合、(検収後ではなく)バグ発見後１年瑕疵担保責任があるということで、地獄かよ、と思ったが、
元々問題が起きがちな受託案件がビジネス的に成立しなくなることで強制的に業界再編につながるなら良いことかもと思うようになった。
一部で地獄を見ても。
https://twitter.com/yukihiro_matz/status/869061879389343744

367 :nobodyさん 2017/05/29(月) 16:28:06.55 ID:6v4UcGhE
ニュース - 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大：ITpro
http://b.hatena.ne.jp/entry/itpro.nikkeibp.co.jp/atcl/news/17/052601508/

372 :nobodyさん2017/05/29(月) 19:10:37.12 ID:???
Railsでシステム作って納品する
↓
Railsはマイナー、メジャーのアップデートが半年以内に必ずある
↓
客がアップデートする。アップデートによるエラーやバグ、動作の不具合に気づく
↓
気づいてから1年以内に通知すれば、5年間無料保証ゲット
↓
つまりRailsがアップデートするたびに、無償の修正作業を発生するということかな

376 :nobodyさん2017/05/30(火) 09:20:20.09 ID:L5po86sS
>>378>>379>>375
客が瑕疵担保責任法の法改正を知ってくると思うから、今後5年無償保証をお願いされるだろう
営業がそれでも仕事を取ってこれるか？たぶん無理だろう。無限の直していたら赤字になる。
こういう保守に弱い言語、ころころ仕様が変わる言語は仕事として発生しなくなってくる。
これは変わり目だ。お前らも早く逃げたほうがいいぞ。RubyやPHPなど動的言語は確実に廃れる。
保守に強い言語のみ生き残れる。

**デフォルトの名無しさん** · 2017/06/28(水) 19:56:54.80

> RubyやPHPなど動的言語は確実に廃れる。
軽々しくこういう断言する人間の言葉は話半分どころか1/4以下にして聞け、ってばっちゃが言ってた

**デフォルトの名無しさん** · 2017/06/28(水) 20:15:29.47

Rubyが現在進行形で廃れていってるのは確かな事実だけどね

**デフォルトの名無しさん** · 2017/06/28(水) 21:48:23.90

ぶっちゃけて言えば、意味論的には普通なのに文法がぐちゃぐちゃすぎて使いづらい。
Perl のあまりの一貫性のなさに Ruby を試したりしたこともあるが、
多少はマシって程度でうんざりするような無茶苦茶さを指向していることにかわりない。
parse.y が黒魔術の塊だというのは聞いていたが、実際に見てみると常軌を逸している。
せっかく yacc を使ってるのに純粋な LALR として解釈できないようなわけわかんないクソが埋め込まれてて、
もはや統制が取れてない。
mruby をベースにして拡充していった方がいい気がする。

**デフォルトの名無しさん** · 2017/06/30(金) 00:38:26.19

使いづらいなら他の言語使えばいいじゃん
わざわざRubyスレ覗いてRubyの悪口書いてる暇があるなら他の言語でコード書こうぜ

**デフォルトの名無しさん** · 2017/06/30(金) 01:21:01.84

>>420
だからもう十年以上使ってない。
事実として文法規則のごちゃごちゃしたところはあるという話だよ。
そして事実として私はそれを気に入らなかったという話だよ。

よくある場面を短く書けるとか人間の一般的な感覚に合わせたりもした結果だというのはわかっているし、
Ruby に向いた用途があるのは知ってるよ。
ただ、それの行く先には実装上の行き詰まりが生じそうだという懸念だ。

**デフォルトの名無しさん** · 2017/06/30(金) 01:37:54.59

>>421
うん、そんな人間がなぜRubyスレを覗いてて、なおかつ悪口を書き込むのか
はっきり言えば粘着質で気持ち悪い

**デフォルトの名無しさん** · 2017/06/30(金) 02:32:52.47

Rubyは読み書きしやすいから使ってる
規則が統一された文法が良ければLispを使えよ

**デフォルトの名無しさん** · 2017/06/30(金) 09:41:10.74

何で使ってない言語を見に来ているの？
暇なの？

**デフォルトの名無しさん** · 2017/06/30(金) 09:50:34.06

rubyは上級者には不満があるのかもしれんが、俺の様な素人が使うには使いやすい。
メソッドチェインも「.」でつなげていくだけだし、
正規表現使うのにimportとかしなくていいし。
でも複数行のコメントアウトは面倒。

**デフォルトの名無しさん** · 2017/06/30(金) 09:51:37.98

>>422

Rubyスレに来て悪態さらすヤツってのは、喩えて言えばこんな感じだ。
最初は、良い会社だと思って就職した。
けど、外から見るのと、入って見るのとでは大違いで、内部は火の車だった。
（例：最近の東芝、タカタ）

転職活動も、うまくいかず、悪態をつかざるを得なくなる。

**デフォルトの名無しさん** · 2017/06/30(金) 10:15:14.59

２ちゃんも昔は良かった

**デフォルトの名無しさん** · 2017/06/30(金) 11:25:06.46

>>427
そうかぁ？殺人予告とかあったんだぞ！
そんでもって、本当に発生してビックリなんてのが、2chなのだ。

**デフォルトの名無しさん** · 2017/06/30(金) 11:30:06.98

>>425
> でも複数行のコメントアウトは面倒。

初心者スレということでいちおうマジレスしておくと
=begin
=end
で囲むと一挙にコメントアウトできる

**デフォルトの名無しさん** · 2017/06/30(金) 11:33:27.81

>>429
たしか、こんなのも
__END__

以下の行は全てコメント！
うる覚えだが。

**デフォルトの名無しさん** · 2017/06/30(金) 11:38:01.54

>>429
こんな糞みたいなの教えたって誰も使わない

**デフォルトの名無しさん** · 2017/06/30(金) 11:45:54.89

>>429
すみません。知っているんですが、
jsとかみたいに/**/とかだと入力がラクだなーって話です。

**デフォルトの名無しさん** · 2017/06/30(金) 12:42:16.16

>>432
メモ帳使ってるわけじゃないんだろうからそれぐらいショートカット使えば差はない

**デフォルトの名無しさん** · 2017/06/30(金) 12:50:26.31

タイピングの文字数に拘るあたりが初心者だよな
（↑それが悪いことだとは言っていないし、一切の悪意は無い）
プログラミングを指の労働と捕らえてるんだよな

**デフォルトの名無しさん** · 2017/06/30(金) 13:04:45.36

>>429
>>430
どっちもコメントアウト用じゃないから

**デフォルトの名無しさん** · 2017/06/30(金) 13:09:33.76

>>435
=begin, =end は一時的なコメントアウトにはよく使うよ

**デフォルトの名無しさん** · 2017/06/30(金) 13:35:43.48

>>434
それはMatz批判か?
処理系を黙らせるためだけの冗長な記述を強いられることは屈辱であると神が仰っている

**デフォルトの名無しさん** · 2017/06/30(金) 13:40:13.66

そんなperlのパクリ機能なんかもう使ってる人いないよ
普通は#で複数行コメントアウトするようなエディタ使ってるでしょ

**デフォルトの名無しさん** · 2017/06/30(金) 14:08:18.32

黙らせるならexit!やな

**デフォルトの名無しさん** · 2017/06/30(金) 16:49:14.50

一時的に処理から外したいときは「そういやRubyにも複数行コメントの記述法があったななんだったかな」と思いながら
#と方向キーを交互に連打してるかコメントリージョン機能を使ってるかどっちかだな

**デフォルトの名無しさん** · 2017/06/30(金) 18:29:44.40

atomやvscodeだったら Ctrl + / で行コメントの挿入削除

**デフォルトの名無しさん** · 2017/07/01(土) 04:05:27.85

俺は if false ～～～ else ～～～ end を使ってる
あるいは後置 if false
元の処理を走らせる場合は否定演算子を付けて if !false みたいにしてるなあ

**デフォルトの名無しさん** · 2017/07/01(土) 04:30:56.70

>>442
それでは駄目なのだ
まあじきにわかる

**デフォルトの名無しさん** · 2017/07/01(土) 05:26:51.20

>>434
まったくその通りだな
「=begin」程度でタイプ数多くてダルいとか

Rubyは記述だと簡潔な方だし
コメントアウトを多用するなんて
書き方してたらそもそも筋が悪い

**デフォルトの名無しさん** · 2017/07/01(土) 11:17:02.68

>>414
爺なの？

**デフォルトの名無しさん** · 2017/07/01(土) 14:26:38.71

同じ処理をさせようとしても
初心者が書くのと慣れてる奴が書くのとですでに差が出てる
a = ['a', 'b', 'c']
b = []
i = 0
a.each {|c| b << (i.to_s + c); i += 1}
p b

↑こーいう書き方する人ほどタイプ数に拘り
↓こーいう人はもはやそこでは騒がない

c = %w(a b c).each_with_index.map {|c, i| i.to_s + c}
p c

**デフォルトの名無しさん** · 2017/07/01(土) 14:59:17.39

いい加減壁に向かって物言うのやめたら
誰もそれを話題にしてはいないよ

**デフォルトの名無しさん** · 2017/07/01(土) 15:48:19.58

>>446
それはわかる
ダメな奴は抽象度を上げようとせずに同じことを短く書こうとする
地頭悪いのをプログラミングの小手先のスキルで誤魔化してる奴にありがち

**デフォルトの名無しさん** · 2017/07/01(土) 16:44:27.93

>>448
そうそうｗ
なんかこう、間違った努力をしちゃうんだよねえ

**デフォルトの名無しさん** · 2017/07/01(土) 19:39:10.28

>>443
駄目でもないのじゃ。
違う処理を簡単に試してみたいときなんかは、外したい部分にも最低限の文法チェックがかかるので、事故が少なかったりな。

**デフォルトの名無しさん** · 2017/07/01(土) 20:41:44.60

b = []
b << 要素

1つずつ、配列に追加していく処理だけど、
エラー処理などがいらないなら、簡潔に書くべき

**デフォルトの名無しさん** · 2017/07/01(土) 21:37:44.67

>>446
> 初心者が書くのと慣れてる奴が書くのとですでに差が出てる

せやね

お前が書くと
c = %w(a b c).each_with_index.map {|c, i| i.to_s + c}

俺が書くと
c = %w(a b c).map.with_index {|c, i| i.to_s + c}

これはタイプ数の問題じゃねーよ？
配列から配列に変換して入れる処理で
eachって単語がでてくることキモいって話

**デフォルトの名無しさん** · 2017/07/01(土) 22:38:49.78

関数厨は、Ruby・JS のスレにやって来て、

何でもかんでも、map を使って、1行で書いてしまうからなw

**デフォルトの名無しさん** · 2017/07/01(土) 22:44:59.49

>>452のようなことに特に興味がなくて
正直どっちでもよくね？
って考える普通の人はRubyを使わなくてもよいってことなんだよ
まさにこれがRuby
「タイプ数にこだわるのは初心者」
「そうそうそうなんだよね～」
とか言いながら動的型言語を使うのって最高でしょ

**デフォルトの名無しさん** · 2017/07/01(土) 23:45:31.46

mapperかな

**デフォルトの名無しさん** · 2017/07/01(土) 23:49:19.16

いくらRubyのコード効率が良いと言っても可読性を犠牲にするつもりはないな
無用に行数を減らしたりオブジェクト名の長さを減らしたりはしない
そういう書き方をすると後で苦労するのは自分だし

**デフォルトの名無しさん** · 2017/07/01(土) 23:54:52.06

>>456
可読性というのは読むべき「単語」を減らすものであって
行数を減らすことやオブジェクト名を減らすことは
単語を減らすことにはつながらない。

例えば行数を減らしたとしても、それが空行や { などの
カッコだけの行を減らした所で単語数は変わらない。
むしろ空行がある方が読みやすい文章となることもある
名前も、短い名前にしても単語数は変わらない

単語数を減らすと結果的に行数が減ることはあるが、
行数を減らすことは可読性を上げる行為ではない。

**デフォルトの名無しさん** · 2017/07/01(土) 23:56:03.86

>>453
本当の関数厨は今時map程度に拘らんぞ。
どの言語でも採用されてるしな。

{|c, i| i.to_s + c }

のがどうにか出来ないか気になるw

**デフォルトの名無しさん** · 2017/07/01(土) 23:56:04.59

ちなみにさっき書いたこれ。

c = %w(a b c).each_with_index.map {|c, i| i.to_s + c}
c = %w(a b c).map.with_index {|c, i| i.to_s + c}

下の方が「単語数」が減っている。
each with index map ・・・ 4単語
map with index ・・・ 3単語

**デフォルトの名無しさん** · 2017/07/01(土) 23:57:42.07

>>458
できるぞ

c = %w(a b c).map.with_index {|c, i| "#{i}c" }

**デフォルトの名無しさん** · 2017/07/02(日) 00:03:47.37

あ、間違った。こうなｗ

c = %w(a b c).map.with_index {|c, i| "#{i}#{c}" }

俺としては、なんでmapがデフォルトでindexを持ってないかのほうが気になるな。
JavaScriptならこれでいいのに

a = ['a', 'b', 'c']
c = a.map((v, i) => i+v)

**デフォルトの名無しさん** · 2017/07/02(日) 00:18:14.45

>>461
というかJavaScriptが特殊なんだよ
引数の数のチェックをしないからな

**デフォルトの名無しさん** · 2017/07/02(日) 00:19:08.94

JavaScriptはJavaの名前にあやかっただけで全くJavaじゃないって本当ですか？

**デフォルトの名無しさん** · 2017/07/02(日) 00:23:24.49

>>462
Rubyでもこの文脈では引数の数のチェックをしてないようですが？

%w(a b c).map.with_index {|c| "#{c}" } # 引数が足りなくてもエラーなし
%w(a b c).map {|c, i, x, y, z| "#{i}#{c}" } # 引数が多くてもエラーなし

**デフォルトの名無しさん** · 2017/07/02(日) 00:24:36.29

>>463
Rubyも宝石の名前にあやかってるだけで全くRubyじゃないよｗ

**デフォルトの名無しさん** · 2017/07/02(日) 00:24:58.24

>>465
なるほどｗ

**デフォルトの名無しさん** · 2017/07/02(日) 00:29:32.61

JavaScriptはLISPっぽい所ある

**デフォルトの名無しさん** · 2017/07/02(日) 00:38:11.58

>これはタイプ数の問題じゃねーよ？
と言いつつも
>可読性というのは読むべき「単語」を減らすものであって
と言うのであった

そして多くの人はこう思うのであった
「単語数と可読性ってそんなに関係あるか？」
「ここで言ってた可読性って、少々冗長であっても
　読みやすいほうが良いって話じゃなかったの？」

>下の方が「単語数」が減っている。
>each with index map ・・・ 4単語
>map with index ・・・ 3単語

一単語減らせて本当によかったね
>これはタイプ数の問題じゃねーよ？ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

**デフォルトの名無しさん** · 2017/07/02(日) 00:49:17.22

>>468

> >これはタイプ数の問題じゃねーよ？
> と言いつつも
> >可読性というのは読むべき「単語」を減らすものであって
> と言うのであった

矛盾してないよ？

例えばコピペ、コピペを使うとタイプ数は減る。
CTRL+vとたった1文字タイプするだけで、
過去に書いたコードを複製できる。
だけど、読むべき単語は倍増していく

可読性のためにやらなければいけないのは、タイプ数を
減らすことではなくて単語数を減らすこと

**デフォルトの名無しさん** · 2017/07/02(日) 00:55:38.04

>>468
> 「単語数と可読性ってそんなに関係あるか？」
> 「ここで言ってた可読性って、少々冗長であっても
> 　読みやすいほうが良いって話じゃなかったの？」

日本語に置き換えて考えればわかるだろ？
文章はシンプルな方が読みやすい。
ただそれだけのことなんだが。

まああと付け加えるとするならば「誰にとって」の話だな。
もちろんプログラマにとってだ。

これは数学に例えればわかるか？

数学者同士が会話をする時、数式を使ったほうがより簡単に説明できる。
数学者同士の会話で素人がわかるように数式を使わないで
会話するのは話をわかりにくくするだけ
なぜか？数式を使えば短い単語数で説明できるから。

ここで素人でもわかるように難しい単語を使わない方がいいという意見は
数学者同士の会話で、素人でもわかりやすく話せといってるようなもん。
素人のために生産性を大きく落とすだけ

**デフォルトの名無しさん** · 2017/07/02(日) 00:57:54.25

>>470
その冗長なレスをまず自覚しろ

**デフォルトの名無しさん** · 2017/07/02(日) 01:08:47.26

プログラムを書くのであれば誰しも可読性が良いプログラムを書きたいと考える
部分があるかもしれないが、そんなとき、単語数などというものの脳内に
占めるウエイトは、ほぼ無い

「あのプログラムのソースコードは単語数が少ないから非常に読みやすかったよ～」
なんて会話は、無い

というと、じゃあ単語数が多いほうが良いのか？と言い出すかもしれないが
そもそも単語数など論点にするのがピンボケ

労力の方向がおかしいし、論点がおかしい

**デフォルトの名無しさん** · 2017/07/02(日) 01:14:15.76

>>471
お前が短く書き直せば？ｗ

**デフォルトの名無しさん** · 2017/07/02(日) 01:15:48.32

>>472

> 「あのプログラムのソースコードは単語数が少ないから非常に読みやすかったよ～」
> なんて会話は、無い

無駄がないとかシンプルっていう言い方をしてるはずだよ。
無駄がないとかシンプルとはどういうことか？というと
それは殆どの場合単語数が少ないことを意味してる
単に言い方の違いだねｗ

**デフォルトの名無しさん** · 2017/07/02(日) 01:23:00.07

ついでに言っておくと、俺は別に冗長に書けばわかりやすくなるとも思ってない
元の人がそのようなことを言っていたから、そういった風なことも書いたが
俺自身はそうとも思っていない
というか、そういったことは、割とどうでもよいというか
多少コードがシンプルになったぐらいで一喜一憂する気分ではない
そりゃ少しはうれしいが、それはまぁなんていうか、青信号だったラッキー、みたいな感覚
どちらかというと、1円見つけた！のほうが嬉しいかなー

**デフォルトの名無しさん** · 2017/07/02(日) 01:28:42.17

> 多少コードがシンプルになったぐらいで一喜一憂する気分ではない

割合で考えようか？

4単語が3単語になったら、25%もシンプルになったとみなすことができる

**デフォルトの名無しさん** · 2017/07/02(日) 01:36:42.12

ほらもう、プログラムの美的センスがまるでないでしょ

>無駄がないとかシンプルとはどういうことか？というと
>それは殆どの場合単語数が少ないことを意味してる

大体において、ソフトウェアの可読性について考えたとき
そのほとんどは設計に依存していると考える人は多いっつーか
まぁ普通の感覚であるところだけど
じゃあなるべく素晴らしい設計をしようって意気込んだ時
「できるだけ単語数を減らせるような設計にしよう」
なんてこと考える奴居るのかね
そんなことがシンプルさの基準になるんかね
これはコードレベルでも同じことだろう
と、俺は思っているわけ

**デフォルトの名無しさん** · 2017/07/02(日) 01:39:30.83

>4単語が3単語になったら、25%もシンプルになったとみなすことができる

なんでシンプルさの基準が単語数なのか本当に不思議な奴だ
プログラム書いたことないんじゃね？説

**デフォルトの名無しさん** · 2017/07/02(日) 03:26:13.52

>>477
> 「できるだけ単語数を減らせるような設計にしよう」
> なんてこと考える奴居るのかね

いるだろうな

言語とかライブラリの比較みてみ？

あの言語・ライブラリではこんなに面倒なコードが
たったこれだけのコード（単語数）で書けるって
話になってるから。

**デフォルトの名無しさん** · 2017/07/02(日) 03:29:27.16

>>478
> なんでシンプルさの基準が単語数なのか本当に不思議な奴だ

単語数だけじゃないけど？

それ以外の条件が同じ時。
単語数が少ないほうがシンプルなコード

それ以外の条件っていうのは、単語の長さはどちらも同程度であること
一行の文字数はどちらも同程度であること
関数の行数はどちらも同程度であること
ファイル数やクラス数や関数数はどちらも同程度であること

それ以外の条件を同じか、同程度にした時
単語数が少ないほうがシンプルなコードになる。

**デフォルトの名無しさん** · 2017/07/02(日) 05:05:29.89

各「.」で何の型が返ってきているのか、実装を見ずとも自明になっている。

最悪でも、マウス当てただけで自明になる書き方。

これを守ってるほうが遥かに重要だわ。

**デフォルトの名無しさん** · 2017/07/02(日) 05:55:04.26

ああもうあなたが初心者であることはよくわかったので他のスレでやってくれ
https://mevius.2ch.net/test/read.cgi/tech/1475332848/

**デフォルトの名無しさん** · 2017/07/02(日) 06:33:34.29

うますぎるプログラムはいけない

**デフォルトの名無しさん** · 2017/07/02(日) 12:23:01.69

>>461
確かにその文法欲しいな。

**デフォルトの名無しさん** · 2017/07/02(日) 13:05:35.53

>>477
同意
プログラミングの難しさは設計の難しさ
コードの美しさは設計の美しさ

それが分かっている奴は
初心者が騒ぐ観点で騒がない
真顔で黙ってる

タイプ数が少ない？よかったね
単語数が少ない？よかったねえ

**デフォルトの名無しさん** · 2017/07/02(日) 13:08:21.66

コードが美しい？よかったねえ

**デフォルトの名無しさん** · 2017/07/02(日) 13:49:07.69

>>422
改善してほしいところさ。
Ruby を使いたいのに全然使いこなせる気がしない部分をなんとかしてほしいっていう要望は悪口なのか？
いや、ユーザーたちは本当にクソだと思わずに使ってんの？

**デフォルトの名無しさん** · 2017/07/02(日) 17:59:14.19

既存の言語が気に入らないんなら
自分で作ってみればいいんじゃね？
クソじゃない言語とやらを

**デフォルトの名無しさん** · 2017/07/02(日) 18:07:42.30

>>487
使ってて言うのならまだしも、10年使ってない人間が言ってもそりゃ悪口にしか聞こえないだろうよ
しかも10年使ってないのにRubyスレを覗いてるという粘着性の高さ

**デフォルトの名無しさん** · 2017/07/02(日) 21:49:13.80

>>487
Haskell良いぞぉ～。

**デフォルトの名無しさん** · 2017/07/02(日) 22:48:36.18

Java + Groovy = Kotlin

Groovy == Ruby

つまり、Kotlin は、Ruby, Groovy に静的型チェックを付けたもの。
型チェックがあるから面倒くさいが、型推論もある

または、Java に関数型を付けたものとも言える

**デフォルトの名無しさん** · 2017/07/02(日) 22:51:40.39

>>491
使ったことないでしょ君

**デフォルトの名無しさん** · 2017/07/03(月) 00:51:18.19

>>461
＞デフォルトでindexを持って
それは思う

「with_index」って冗長だし
eachでもデフォで持ってて欲しい

**デフォルトの名無しさん** · 2017/07/03(月) 01:32:13.92

デフォでindex持ってたらそれこそ冗長じゃないの

**デフォルトの名無しさん** · 2017/07/03(月) 01:33:52.97

>>494
冗長であるとはどういうこと？

**デフォルトの名無しさん** · 2017/07/03(月) 03:30:38.10

>>494
たしかに記述が冗長か構成が冗長かだけど別に良くね
イテレータがインデックス持っててもおかしくない

配列はデフォで配列の長さ分かるじゃん
そんなようなもん

**デフォルトの名無しさん** · 2017/07/03(月) 03:42:56.46

構成が冗長ってどういうことだろう？
普通、冗長ってそういう意味に使わないよね？

**デフォルトの名無しさん** · 2017/07/03(月) 10:06:01.55

>>493
each_with_index は素の each に比べて 3~4 割遅い。
each のデフォルトで index を持つよりは、遅くても index が使いたいときに明示するという使い方の方がリーズナブルだと思うけど。

**デフォルトの名無しさん** · 2017/07/03(月) 10:29:47.39

でもそういう使い分けこそ、まつもとさんに言わせればムダなわけだし
あのひとは機械にできることはすべて機械にやらせるべし、って言ってるからね
コンパイラはインデックスを必要としているかどうか、判断できるわけだから
勝手に使い分けてくれればよいんじゃね？
てことでRubyを静的型にしてオーバーロードで解決すればよいだろう
静的型にするとコンパイル時に型チェックをさせることができるし
最適化もかけやすくなるし、入力補完との相性もよい
機械で出来ることがどんどん増えるから
まつもとさんの機械にできることは～の考えによく合ってるね

**デフォルトの名無しさん** · 2017/07/03(月) 11:00:51.38

>>499

> あのひとは機械にできることはすべて機械にやらせるべし、って言ってるからね
発言を自分に都合よく拡大解釈してない？

> コンパイラはインデックスを必要としているかどうか、判断できるわけだから
あなたの脳内のコンパイラはそれができるみたいだけど、
現状のMRIにその機能は無いよ。

> てことでRubyを静的型にしてオーバーロードで解決すればよいだろう
> 静的型にするとコンパイル時に型チェックをさせることができるし
> 最適化もかけやすくなるし、入力補完との相性もよい
機械で出来ることがどんどん増えるから

現時点で解決したいならCrystal使ったほうがいいよ。
変数の型を変えると言う言語の根幹に影響する変更が受け入れられるとは思わないけど、あなたがそんなに強く望むのならコミュニティに参加して意見が通るほどの功績を積むのが最短の道。

**デフォルトの名無しさん** · 2017/07/03(月) 20:57:22.46

>>500
久々に普通な常識を元にしたレスを見た

**デフォルトの名無しさん** · 2017/07/03(月) 23:47:51.07

まあ別にeachにインデックスを渡してても良かったと思うけどね
(3..9).each_with_index {|e| p e }

**デフォルトの名無しさん** · 2017/07/04(火) 04:47:02.02

つーかeach_with_indexが長いから
each_iとかで良かったんじゃね？
極端な省略だけどto_iとかもあるから

**デフォルトの名無しさん** · 2017/07/04(火) 10:42:41.42

オブジェクト指向なんだからオブジェクトによって振る舞いが変わればよくね？
なんでこっちで使い分けなきゃならんの？