Ruby 初心者スレッド Part 65

2018/12/22(土) 04:43:34.03

プログラミング言語 Rubyについての、初心者向けスレです。質問・要望・雑談などをどうぞ

質問するときは、OSやRubyのバージョン、エラーメッセージを書いて下さい。
Ruby on Rails については、WEBプログラミング板で

前スレ
Ruby 初心者スレッド Part 64
https://mevius.5ch.net/test/read.cgi/tech/1535797516/

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

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

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

Ruby コミュニティ公式
https://www.ruby-lang.org/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2019/08/03(土) 23:28:43.68

>>553
> DRYに反してるっていうけど、何処が？
Type obj=new Type()
じゃないの？型を2回書いてるじゃん！という。

なお、C#がそうだったんだけど、遠からず改善される予定。
Type obj=new()
# 最初からそうしといてよー、と思わないでもないけど。ｗ

型のDRYを避ける方法はあるんだよな。
しかし、Rubyはそこから目をそらして、DRYを言い訳にして、とにかくなにがなんでもオブジェクトの宣言を含めたくないんだろう。

2019/08/04(日) 03:31:45.57

>>553
>DRYに反してるっていうけど、何処が？

https://qiita.com/t2y/items/2a1310608da7b5c4860b
> def sum_and_stringify(nums: List[int]) -> str:
> 　　"""Adds up the numbers in a list and returns the result as a string."""
> return str(sum(nums))
じゃないの？
型を2回書いてるじゃん！という。

なお本件、改善される計画はなく、いつまで待っても放置される予定。
# ML や Haskell なら最初から型アノーテーションなんて不要だからDRYだけど、
# その方向性を最初から放棄してどうすんのよー、と思わないでもないけど。ｗ

型のDRYを避ける方法はあるんだよな。
しかし、そこから目をそらして、global だの nonlocal だのスコープ問題の泥縄的解決である
変数宣言を言い訳にして、とにかくなにがなんでも型宣言を含めさせたいんだろう。

2019/08/04(日) 12:53:29.81

あと
別ファイルに型定義書くのって立派なDRYじゃねーの？
だって、クラス名やメソッド名変更するとき
両方書き直さなきゃならないじゃねーか
これはDRY以外の何なんだ？
ほんと、ペテン師はいつも自分に都合のいい事だけ言うよな
分かっててすっとぼけるんだわ
信者には悪いが、マジで毎回そう

2019/08/04(日) 13:05:34.87

つまり、
普通に素直に型宣言するより
別ファイルに型定義書く方が
よりDRYだし面倒だし
この掛け違えたボタンで首が絞まる感じ何なん
もう普通に型書いたら？
アホらしすぎ

2019/08/04(日) 13:18:44.89

型定義を別ファイルの書くのって
丁度C言語が.hと.cに分かれてるのと同じ感じだよね
で、関数名変えるとき.hと.cの両方書き換えるっていうね
今更C言語に先祖返りってどうよ
あれDRYって何だっけ

2019/08/04(日) 13:39:41.20

あるクラスの名前を変更する
型定義ファイルに書いてあるクラス名を変更し忘れる
そのクラスの型定義が無くなり型チェックが効かなくなる
プログラマは型チェックが効いてると思い込みテストをサボる
バグを組み込んでしまう
あり得るシナリオだし、こういうのをDRYと言うのではww

同じような感じでヘッダと実装に分かれてるC/C++の場合は
これは間違ってるとコンパイルエラーになるから良いけど
Rubyの場合は修正し忘れてて型定義が見つからない状態になってても
それはそれとして、どうせ無テストになるだけでスルーでしょ
(他に型定義の無いクラスはいっぱいあるわけで型定義が無いだけでエラーには出来ない)

さあ型定義ファイルにあるクラス名とメソッド名が
間違っていないか確かめるテストを書かなきゃねwww
(単純にtypoしてるかもしれないわけで)

で、誰得なんこれ

2019/08/04(日) 15:37:02.28

まつもとが型のメリットを理解してないからどうしようもない

2019/08/04(日) 20:45:52.66

WEB+DB vol.111

詳解 Rails 6

コミッターが解説する、26ページ分の特集！

2019/08/05(月) 01:20:57.58

>>556-559
>別ファイルに型定義書くのって立派なDRYじゃねーの？

まず、この文章は「DRY違反じゃねーの」の間違いだろう
これだけでもアンチRubyがDRYという言葉の意味を理解せずに
トンチンカンな批判を繰り返している実証になる

次に上記の文章を：
>>別ファイルに型定義書くのって立派なDRY違反じゃねーの？
と訂正したとしても、答えは NO だ
確かに型推定を最初から放棄してユーザに型アノーテーション記述を
強制する言語(>>555)であれば、その型アノーテーション記述がソースファイルと
同一ファイルであっても別ファイルであってもDRY原則に反している、と言える

しかしRuby3.0で計画されている型プロファイルは、型宣言記述が無い
素のRubyソースコードから型定義ファイル rbi を自動生成できる
また、ソースコードと同一ファイルにアノーテーション(注釈、いわゆるコメント)として
型定義を記述することもできる（ただし、この場合は自動生成されず手書きとなる）

2019/08/05(月) 01:57:11.36

>>562

> トンチンカンな批判を繰り返している実証になる

揚げ足をとれたからって、そんなに必死にならなくても。ｗ
DRYDRYとうるさいのは信者くらいで、ふつうは実はそんなに気にしてないからな。しゃあない。

> 素のRubyソースコードから型定義ファイル rbi を自動生成できる

スケルトンみたいなこと？
その手のやりかたってヤバい原因になりがちだと思うんだけど、だいじょうぶなの？たいがい元ソースコードの変更に追い付けなくなって、うやむやになるよねえ？

> 型定義を記述することもできる（ただし、この場合は自動生成されず手書きとなる）

つまり、ソースを変更したら、あわせてアノテも変更しないといけないのか？
結局はDRY違反なの？

ホントにそんなだったら、どうせ誰も使わない気がするなあ。。。

2019/08/05(月) 02:20:06.63

>>563
>揚げ足をとれたからって、そんなに必死にならなくても。ｗ

揚げ足ってのは、DRYを逆の意味に理解していた(>>556)事実を、
あっさり >>557 の冒頭で指摘されちゃったこと？
まぁしゃあないわな、「揚げ足」を隠そうと必死になるのも www

**564** (ﾜｯﾁｮｲ 75e7-27IP) · 2019/08/05(月) 02:21:24.98

訂正
X：>>557
O：>>562

2019/08/05(月) 07:34:24.32

https://img.logmi.jp/article_images/D2VbGeV4PWY5uay2tHho6g.jpg
こんなんを別ファイルに記述するはめになるんだ
クラス定義に似てるね
重複して同じようなことを二回書かなきゃならないって事
DRYの原則に反してるから型宣言を書きたくないって話だったのに
より一層DRYの原則に反してるね
C++のヘッダにそっくり

あと今更するなら最初からしておけば何かとよかったのにね
夏休みの宿題を最後にためておく人だったのかな

一方静的型言語にも型推論とか取り入れられてるけど
こっちは文法的にも文化的にも何の障壁もなく導入されてるのが笑える
なにこの差
さらにはヌル安全とかまでやろうとしてる
逆にこっちのやってるのはいまだにネイティブスレッドww
何周遅れよこれ

そんでいつも後出しジャンケンで負ける
動的型もそう
後出しジャンケンして負けた
後出しジャンケンでも勝てばいいんだが負けたら意味ないね
Rubyサイコー

2019/08/05(月) 07:39:15.45

>また、ソースコードと同一ファイルにアノーテーション(注釈、いわゆるコメント)として

この方式はmatzが滅茶苦茶に嫌ってるから採用される事はないね
あの人わけわからないぐらいこのことに固執してるからね

また何も知らないか、知ってても嘘をつく
いつものパターンね

2019/08/05(月) 13:40:37.89

ちなみにmatzがソースコードに型を書きたくない理由だが
色々言ってるが、彼は詐欺師だから、本音ではないし、嘘も含まれる

まず
https://logmi.jp/tech/articles/321280
にも書いてあるし、たびたび登場するDRYに反するというやつ
言うまでもないが別ファイルに書く方がDRYに反するし
これは多分、彼の本音ではないし、煙に巻くための適当な言い訳

つぎに、静的型と動的型は振り子のようにトレンドが移り変わり
今後また動的型言語の時代が来るから、というもの
いやいやこれから先、動的型の時代など来ないだろうし、そもそもの前提がおかしい
C言語以降はずっと静的型の天下であり、動的型が勝ってた時代などなかった
振り子のようにというのがそもそも嘘偽り誇大表現、こうやって騙してくる
C/C++、Java、C#といった超メジャー言語にRubyが勝っていた時代など一度もなかっただろ、詐欺師め

2019/08/05(月) 13:43:49.85

もう一つ
ここに書いてあることが実は本音(らしい)
https://jp.quora.com/TypeScript%E3%81%AE%E3%82%88%E3%81%86%E3%81%AA%E5%9E%8B%E4%BB%98%E3%81%91%E3%82%92Ruby%E3%81%AB%E5%AE%9F%E8%A3%85%E3%81%97%E3%81%9F%E3%82%89%E6%9C%80%E9%AB%98%E3%81%AE%E8%A8%80%E8%AA%9E%E3%81%AB%E3%81%AA%E3%82%8B
要約すると、Rubyに型アノテーションが導入されたら
型を書いた方が行儀が良いという風潮が蔓延するだろうが、自分は型を書きたくないので
そのために型をかけないようにしておく、というもの

良いことが出来ると、良いことをする風潮になるだろうが
自分は悪いことがしたいから、良いことが出来ると困る
と言っているわけで、マジキチなのがお分かりいただけるだろうか

法律があると法律を守らなければならないから嫌
信号があると信号無視が出来ないから嫌
と言ってるようなもので、まさに悪人の考え
型は書いた方が良い、とうことはしっかり分かってる上で
嫌だから出来ないようにしておく、と言ってるわけで、悪人独特の自己矛盾

しかし普段自分の都合のいいように嘘しか言わない彼が、本音を語っている点は評価できる

2019/08/05(月) 13:47:09.02

そろそろこっちでやれ
アンチということではなく本スレの代わりとして
Rubyについて（アンチ専用） Part005
https://mevius.5ch.net/test/read.cgi/tech/1555162340/

2019/08/05(月) 13:52:01.39

しかし>>569に書いたようなことを公式で言うとマジキチだから
静的型を導入しない理由を聞かれると、いつも適当なことを言って言葉を濁しているわけ
これでRuby3.0で導入されるといわれる型チェックが
どうしてああいう感じになってるか良くわかるでしょ

2019/08/05(月) 13:52:35.64

型を書きたくないんじゃなくて、Rubyの設計上、型を書こうとすると
設計レベルで作り直さなきゃいけなくなるから面倒くさいだけだよ。

2019/08/05(月) 14:07:53.55

Perlも6で詰んだしな
*byも脱皮失敗で死亡
pythonは2->3でヨタヨタだがうまく離陸してくれ

2019/08/05(月) 14:08:47.58

単純に全体の完成度がバージョン0.8くらいに戻るよね
そこまでして「わざわざRubyに」導入するべきものでもないということではあろう
昔ならともかく今は他の言語もあるのだから
これ言うと揉めるけどな

2019/08/05(月) 14:14:45.71

1. 型を導入すると良いものになる。
2. だけど全体を再設計しなければならない。（面倒くさい）
3. その上、使いやすくすると、言語がガラリと変わる
4. ユーザーもその「使いやすい言語」に乗り換えるのが面倒くさい
5. 結果使われなくなるのがわかっている。
6. Ruby離れを防ぎつつ、型を導入するには、コレしかなかった

2019/08/05(月) 14:23:24.52

型無し*byに不満な人はElixirやればいい

2019/08/05(月) 14:27:47.88

LISP や Smalltalk が好きな人にとって使いやすい Perl の代替となるスクリプト言語なんだから、型欲しい人は他の言語使えば？と言うだけの話。
型を導入すると対話環境での使い勝手が悪くなり、書き捨てのプログラムを書く際の手間が増える。それは楽しくない。

型を使うと速くなる？そんなに速度が要求される要件に使うなんて決定をする奴がおかしい。型を使うとバグが減る？そんなにレベルの低い人は使わなければいい。
妥協できるラインが、今の、書きたいやつは書けば良いんじゃない？でも、文法を拡張して既存コードとの非互換生むような修整は受け入れられない。
と言う話でしょ。

2019/08/05(月) 14:32:38.11

>>576
そう。 Elixir なり Crystal なりを使えばいいだけの話。
なんでRubyに型を導入することにこだわるんだろう。

2019/08/05(月) 15:48:35.23

ドキュメントに型を書くことになるんだから、そこの仕様をしっかり決めるべきだった

2019/08/05(月) 16:30:50.53

>>577
> 型を導入すると対話環境での使い勝手が悪くなり、書き捨てのプログラムを書く際の手間が増える。それは楽しくない。

それはstrictモードを作ればいいだけなんよ

2019/08/05(月) 16:33:24.89

>>577
> 型を使うと速くなる？そんなに速度が要求される要件に使うなんて決定をする奴がおかしい。
> 型を使うとバグが減る？そんなにレベルの低い人は使わなければいい。

その二つ、論点のすり替えだよね？

型を使うと速くなる？ → それは事実 → だから人間の問題にすり替える。
型を使うとバグが減る？ → それは事実 → だから人間の問題にすり替える。

事実ならまず「それは事実だね」って言ってみようか？
事実に対して反論するかと思いきや、反論しないんだもの（笑）

2019/08/05(月) 16:34:57.91

> でも、文法を拡張して既存コードとの非互換生むような修整は受け入れられない。

結局本音はそこ。

速くなるとかバグが減るという "事実" は存在するが、
既存コードの非互換性をうむから、改善できない。

2019/08/05(月) 17:42:09.05

>>581
型を入れてもオープンクラスな言語では大して速度は上がらない。精々一部のループの速度が上がるだけ。それは事実。java みたいに final や primitive 型入れれば効果は相当あると思うけど、それは Ruby を否定することになる。
型を入れると未熟なプログラマでもコンパイル時に分かる程度のバグなら発見できることはある。それは事実。でも実行時例外の回避は出来ないし、オープンクラスを使ったダックタイピングという Ruby の言語デザイン自体を否定することになる。

> 事実に対して反論するかと思いきや、反論しないんだもの（笑）

反論もなにも、自分はこのスレッドで >>344 >>577 >>578 しか書いてないよ。
だから、なんらかの反論を待ってるならその相手は自分ではない。

自分は Ruby に非互換を生む型の導入を期待するくらいなら、型有りの別の言語で書けばいいじゃんという立場。

>>580
この場合の strict モードって何を指してるの？
RPython 的に SRuby 作って型使いたい人は SRuby 使えってこと？同一バイナリにしてモード切り替えするとしたら、パーサも VM もほぼ別物レベルになると思うけど。
共有できるとしたら、pure ruby で書かれたごく一部のライブラリ程度じゃない？

2019/08/05(月) 17:55:40.47

型を入れてもオープンクラスな言語では大して速度は上がらない
→オープンでない言語なら速度は上がる
→速度を上げるためにはオープンでなくすれば良い
→そのような改善方法は存在するが、非互換性をうむから、取り入れられない。
→まつもと「Rubyでは改善はなんです。諦めてください」

2019/08/05(月) 17:55:56.86

→まつもと「Rubyでは改善は無理なんです。諦めてください」

2019/08/05(月) 17:58:22.53

>この場合の strict モードって何を指してるの？

適切な型を書いたものがstrictモード

だがどのオブジェクト指向でも、基底クラスのobject型として扱うことはできる。
暗黙的にobject型の変数を使ってるとみなしているのが今のRuby。

変数の型をobject型と書く（もしくは省略）か、適切な型を書くかの違い。

2019/08/05(月) 18:29:24.24

> 実行時例外の回避は出来ないし

は？

2019/08/05(月) 18:55:01.90

Rubyの癌は、型を指定できないことよりも、宣言ができないこと。
型を指定できないのは、宣言ができないことによる副産物。

宣言は、ここからこのオブジェクトを使うで、ということを明確にできてわかりやすいのに、何で嫌がってんだか。

2019/08/05(月) 19:04:12.59

>>586
strict モードにしたら
Class が凍結されるの？
途中でモードを切り替えられるの？
そのスコープは？
マルチスレッド時の挙動は？
Object クラス(Kernelも？)への継承関係がなくなるの？
データは VALUE 型じゃなくなるの？
オブジェクトのデータ構造は自分で C で定義するの？
既存CAPIとの整合はどう取るの？
そのコードを古いインタプリタに食わせたらどうなるの？
また分断するの？(想像するに1.4->1.6 や 1.8->1.9 より大きそうだけど)
strict にしたら何がどう変わるのかわからん。
過去に例示してあるのなら参照求む。

>>585
そう。大抵の要望は Crystal で解決されてると思う。
速度欲しいなら Elixir 。もしくは C で FFI。

2019/08/05(月) 19:13:25.94

>>589
うん？だからそういう問題が発生するから、
Rubyでは型という素晴らしい道具を導入することが
設計上不可能って話をしてるんだが？

2019/08/05(月) 19:28:52.54

>>590
そのかわり型ということを考えなくても計算機と対話することができる日常用途に便利な言語になったわけだ。

2019/08/05(月) 19:32:29.27

Rubyにも型があるんだから、型考えてるでしょｗ
それともどんな型を入れても、エラーにならずに動くコードかいてんのか？

2019/08/05(月) 21:15:23.92

型チェックが欲しい人は他の言語使えって言ってるけど
Ruby3.0で型チェックが導入されるんだからそこは前向きに検討しようよwww

matzが言うようにRubyに型が指定できるようになったら、指定すべきという勢力も
出てくるだろうし、一方でわざと型を書くのが億劫になる仕様にしてあるし
どちらの勢力が勝つか未知数というか
平行線が続いて空中分解してクラッシュするかもしれないし
ここでも今そういう意見があるように、今までは型チェックが欲しい人は他の言語使え
だったわけだけど、Ruby3.0からはそうじゃなくなるから更にカオスになるだろう
今までは型を書くべきかどうかはRuby 対他の言語って感じだったけど
これからはRubyの中でそれが起こる
楽しみだね
このへん、言語仕様で初めからどちらかに決まっていた方がスッキリしていたかもしれないね

2019/08/05(月) 21:19:04.07

それに加えて型定義ファイルの自動生成の話もあるが
まぁ最初は使い物にならないだろうからそれも含めてカオスになる
それがRuby3.0

静的型言語も動的型言語を取り入れてるっていうけど
こっちは何の問題もなく行われてて全くの静寂なのが笑える
まぁ型推論はコンパイラが型を推論してくれるというだけで
型は静的に決定されているわけだから当たり前なんだけど

2019/08/05(月) 21:29:41.54

型は書いたほうが良いが今更自然な形での導入は難しい
しかし3.0で書きにくいけど書けるようになる
書けるようになるなら書いたほうが良い
でも書きにくい
でも書かなきゃ
でも書きにくい
書きたくない
でも書かなきゃ
でも書きにくい

これがRuby3.0

2019/08/05(月) 21:34:38.65

型注釈、PythonとRuby両方でやってみたけど
Pythonの方が全然完成度高い
試験的な実装とはいえRubyの方は複雑になるとチェック通せなくなる

2019/08/06(火) 15:11:10.96

実行時まで型が決まらない

ひとことで言え

2019/08/06(火) 17:04:56.96

実行時まで型が決まらないと言うが、
コードは特定の型もしくは特定のインターフェースを備えた
型であるという前提になってるんだよなｗ

2019/08/06(火) 18:28:14.04

perl5の末期に登場したのがuse strictとuse warningだよ
それを順当に真似てるだけだ
他意は無い

2019/08/06(火) 20:21:21.15

前々からの、掛け違えたボタンの、いよいよ一番上を閉めようとしている段階なのだよ
そんなことは出来ないか、不格好か、首が絞まるか
何にせよ、こういう仇花的なことをしなければならない状況に追い込めたのは
日々のみんなの空気づくりのおかげであって、いわば人類側の勝利だよ
おめでとう

2019/08/06(火) 20:25:09.69

まずはモンキーパッチを抑制するオプションを追加して
静的に解析できるようにするのが先でしょ

2019/08/06(火) 20:27:16.73

>>599
Perl5に「末期」なんかないぞ。
まだまだ現役だからな。ｗ

2019/08/06(火) 20:34:15.67

モンキーパッチ（オープンクラス）ができるのはメリットではあるが、
通常はそんなことしないので、小さなメリットのために
大きなデメリットが発生してるんだよな。
最終手段を取るしか無いところだけ、unsafeとかマークを付けて対応すればよかった。

2019/08/07(水) 18:14:09.58

>>596
>Pythonの方が全然完成度高い

当然の感想だよ
そもそも静的型付けは大きく以下の２つに分類される
・明示的(explicit)な型付け
・暗黙的(implicit)な型付け

前者の明示的型付けはプログラマが型定義を手書きすることを前提としており、
Fortran/Cobolといった1950年代の太古の時代から培われてきた「枯れた技術」である
Python の型アノーテーションも明示的型付けに分類される
従って、完成度が高いのも当然、できて当たり前と言える

後者の暗黙的型付けは堅牢な型システムを前提とし、処理系が「型推論」と呼ばれる技術により
コードから型定義を自動的に決定するものであり、1980年代にMLで開発され、近年、明示的型付けを
主としながら部分的に暗黙性を取り込む次世代言語が次々に登場するなど、急速に普及が進みつつある

MatzがRubyKaigi 2019で語った：
https://logmi.jp/tech/articles/321280
「最近は静的型がすごくホットで、2010年代のプログラミング言語はみんな静的型言語で、…」
というホットな静的型言語も、後者の暗黙的型付けを指す
同時にMatzが語った：
「もう、われわれもやろうか。PHPもPythonもやってるし」って言うんだけど、正直やりたくない……。」
の「やりたくない」のは前者の(プログラマが型定義を手書きしなければ型検査が働かない)明示的型付けを指す
つまり意訳すると：
　Rubyでも明示的型付けをやろうと思えばいつでもできるけど、今さら時代に逆行したできて当たり前の事を
　やるなんてつまんない、それより今まで誰もやったこともない血が湧き立つような挑戦をしてみたい、
　それがRubyらしさだよ
そして、この後、「動的型付け言語であるRubyにおける暗黙的な静的型付けの導入方針」として、
(型推論の代用である)「型プロファイラ」と呼ぶ新技術の紹介が続くわけだ

2019/08/07(水) 18:42:31.98

>>604
なにかごちゃごちゃ語ってるけど、

マッツが言った「やりたくない」は
面倒くさいって意味だよ。

血が湧き立つような挑戦なんてものを思いついていたら
それを理由にするだろ。そんなもんないからさｗ

2019/08/07(水) 19:39:46.36

そら掛け違えたボタンの一番上を締めるのは
血が逆流するほど苦しくて沸き立つだろうな
こんなもんは北朝鮮とか共産党とかの言ってる理想みたいなもので
最初に掛け違えてるからそういう夢を見なきゃいけない羽目になってるだけで
大人になったらさらっと流さなきゃね

2019/08/07(水) 19:40:25.87

マルクスとかに感化されて
血が沸き立つような挑戦
って言ってるようなものなんよ

2019/08/07(水) 20:15:49.09

他は学生運動とかかな>血が湧き立つような
俺は世代じゃないからよく知らんけど、映像見る限り、かなり湧き立ってるな

後単に、「血が湧き立つようなっ」て表現面白い(こわッ

まぁそういうのはあるよ
最初を掛け違えたため人生台無しになるっていう
大概の人はどこかで気づいて掛け直すから大事には至らないけど
物事を考える最初の起点が一つズレて、以降思考が全部ズレる
ゴールにたどり着けないもんだから、ゴールのさらに先へ行こうと夢見る
そうやってたぶらかす
共産党みたいな輩

根本の問題だからなぁ
悪人は悪人にしかなれないってわけじゃないけど
気づけなきゃ悪人のまま終わるよね

2019/08/08(木) 10:01:50.60

すげえ馬鹿な質問するけど
x = [nil, "hoge", 42, 3.14].sample
みたいなのがあった時って型推論ってどうなるの？

2019/08/08(木) 10:56:04.30

rubyに限らずスクリプト系はlispが基準だろ
だからリストにはなんでも入れれる

2019/08/08(木) 12:56:56.32

>>609
理想としてはArray<nil|String|Integer|Float>みたいな感じかね

2019/08/08(木) 15:33:58.94

C#的にはエラー(推論不可)だな。
それでいいと思う。

2019/08/08(木) 21:48:40.95

TypeScriptは型システムの表現が凄すぎて
大抵の言語に型付けできそう
パクればRubyにも型付けできるんじゃね

2019/08/08(木) 22:17:23.13

Haxe では、Array<Dynamic> で、何の型でも入る、配列を定義できる

これは型推論しないから、できる限り避けるべき！
これは、設計ミスかも知れない

2019/08/11(日) 09:42:24.48

typescript なら [ null, string, number, ‘foo’ | ‘bar’, 1 | 2 ]
のように定義できるしね

2019/08/12(月) 10:28:41.63

そうやって夢を見ておけばいい
その方が落胆が大きくなるだろうから

2019/08/12(月) 21:41:57.67

とにかくTSからパクれるものは全部パクった方がいいと思うんだが
JSに無理やり型付けするために生み出されたキメラなのだから
参考になる部分だらけなはず

2019/08/12(月) 22:34:28.71

全然違う方向へ向かってるから無理

2019/08/13(火) 09:14:00.33

TSで書いてRuby吐くコンパイラω

2019/08/17(土) 14:16:33.22

>>617
JavaScriptはそもそも静的型付け言語であるCやJavaの構文を参考にして設計された言語だ
医学部卒のプロ棋士が引退して医師に転向することは容易だが、中卒には不可能である

2019/08/17(土) 16:35:39.55

>>620
> JavaScriptはそもそも静的型付け言語であるCやJavaの構文を参考にして設計された言語だ
大嘘つくなよ
似てるのは中括弧を使ったブロックとかの見た目だけじゃん

2019/08/17(土) 16:44:03.64

>>621
だから構文の話をしてるんだろ

2019/08/17(土) 16:58:40.60

jsは構文でもJavaと似ても似つかないぞ

2019/08/17(土) 17:04:14.21

惜しい
jsですら似ても似つかないなら、Rubyだったらどうなのか考えてみよう
基準はあくまでRubyであることを忘れないようにしましょう

2019/08/17(土) 17:16:36.20

話を逸らすのはチョン國人の手口

2019/08/17(土) 19:31:09.99

>>622
中括弧使ってセミコロン使えば静的型付けになるのかよｗ
的外れもいいとこ

2019/08/17(土) 19:37:00.00

>>625
死ねよネトウヨ
お前もチョンがどうのとか言って話そらしてんじゃん

2019/08/17(土) 21:08:03.39

>>624
JavaScriptに比べたら、Rubyのほうがまだ似てるんだよなあ。ｗ

JavaScriptのクラス定義を見たことがあるか？プロトタイプベースなので、ほかではなかなか見られないぞ。

2019/08/17(土) 22:01:43.78

JavaScriptのクラス定義は、C++やJavaにそっくり

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Classes

class Rectangle {
　constructor(height, width) {
　　this.height = height;
　　this.width = width;
　}

　// ゲッター
　get area() {
　　return this.calcArea();
　}

　// メソッド
　calcArea() {
　　return this.height * this.width;
　}
}

const square = new Rectangle(10, 10);

console.log(square.area); // 100

2019/08/17(土) 22:03:16.05

プライベートフィールドはちょっと変わってる。

class Rectangle {
　#height = 0;
　#width;
　static #depth = 1;

　constructor(height, width) {
　　this.#height = height;
　　this.#width = width;
　}

　volume(){
　　return this.#height * this.#width * Rectangle.#depth;
　}
}

2019/08/17(土) 22:03:58.27

JavaScriptの継承もC++やJavaとそっくり

class Dog extends Animal {
　constructor(name) {
　　super(name); // 親クラスのコンストラクタを呼び出し、name パラメータを渡す
　}

　speak() {
　　console.log(`${this.name} barks.`);
　}
}

2019/08/17(土) 23:51:47.98

Node.js は、Ruby のコピー。
npm, yarn も、Bundler のコピー

CakePHP は、Rails のコピー

2019/08/18(日) 00:59:22.65

> Node.js は、Ruby のコピー。
間違い。Node.jsは言語ではなく実行環境（≒ライブラリを提供してる）

Rubyという言語をコピーするわけないじゃないですか（笑）

ツールやフレームワークに価値はあって、そっちはコピーしたとしても
Rubyという言語にコピーする価値はないですからねｗ

2019/08/18(日) 01:51:43.24

>>629
つい最近そうできるようになっただけやけどな。ｗ

2019/08/18(日) 01:59:35.72

>>634
つい最近 = 4年も前

それを今知ったんかい？ｗ

2019/08/18(日) 03:22:24.68

元から似せて作ってないって話でしょ

**632** (ﾜｯﾁｮｲ 132c-BF++) · 2019/08/18(日) 08:06:58.21

Node.js は、Ruby 実装系のコピーだろ。
npm, yarn も、Bundler そっくり！

npm, yarn のlockfile とか、Bundler のlockfileと同じ

Ruby, Node.js も、サーバー側プログラミング

2019/08/18(日) 08:22:32.26

> Node.js は、Ruby 実装系のコピーだろ。

全く違う。似てるところが一つもないと言っていいレベル
つーか、Rubyにぱくれるところなんてなにもない

2019/08/18(日) 09:44:57.54

ちょっとこの信者なんとかしてくれない？
スキルセットがRubyしか無いから、何が何でもRubyのコピーだと言い張ってて鬱陶しいんだけど。

2019/08/22(木) 23:17:51.79

WEB+DB vol.111 は、Ruby on Rails 6, Julia 特集だけど、
Python から、Julia へ流れそう

Julia は、do ～ end が使えて、Ruby風に改良されてる！
Jupyter Notebook(JN)でも使える

Windows で、RubyをJNで使っている人は、日本語でバグらないの？
irb では、バグるけど

RubyをVSCode で使っているけど、JNでも日本語でバグらないかどうか、知りたい

2019/08/23(金) 01:33:05.16

ocraやgolangのgo buildみたいにRubyスクリプトとその要求ファイルを
単一の実行ファイルに固める仕掛けのLinux/FreeBSD向けってありませんか？
利用側でのセットアップを簡単にするために探しています

2019/08/23(金) 02:21:20.94

Bundler は？

Node.js のnpm, yarn と同様の、パッケージマネージャー

2019/08/23(金) 07:21:08.15

Bundler というより、gem だね
gem を作れば1ファイルにできる

2019/08/25(日) 21:34:28.24

>>640
JuliaとPythonじゃ目指してる方向が違うから、PythonがまるまるJuliaに移行するということはないよ。
numpyでゴリゴリ計算してるようなものはJuliaに移行するだろうけど、
Cなどで書かれた外部ライブラリを呼び出しまくっているようなものが移行するとは思えない。

2019/08/25(日) 22:57:02.68

結局、Perl5はシステム、RubyはWebバックエンド、Pythonは機械学習と、確立した用途で落ち着いてしまいそうだよなあ。

2019/08/25(日) 23:37:44.87

Rubyは良く出来た言語だが、困るのはバイナリ処理したいとき
バイナリを扱うことはできるらしいが、かなり面倒そうで結局やらない
rubyにCのインタプリタを内蔵してはどうなのだろう
AIなど一挙に使える範囲が広がる

2019/08/26(月) 00:06:00.18

もうCでよくない？

2019/08/26(月) 00:08:19.86

でもたいていのところではrubの方がでいいわけですし

2019/08/26(月) 03:42:42.45

>>646
バイナリ処理は、目的とやりようによっては、C/C++よりもPerl5/Rubyのほうが簡単なんだが。
pack/unpackが意外と使いやすいからな。

2019/08/26(月) 03:47:15.63

バイナリはバイナリのまま処理すればいいと思うんだが、
なんでいちいちpack/unpackなんかするんだ？

2019/08/26(月) 10:06:15.99

perlからの流れであり深い意味は無い
それが好ましいと言う奴だけがrubyを使ってる
だから宗教だ

「わたくしはそれを気にいっている」宗教ではコレ以外の理由は必要無い

2019/08/26(月) 13:12:19.64

>>650
スクリプト言語は原則として、メモリに直接アクセスするようにはできていない。

念のために言っておくと、C/C++のキャストと比較しているのならそもそも大間違い。
また、あれはあれで問題だらけ。

2019/08/26(月) 13:36:12.79

例えば？