次世代言語議論スレ[Go Rust Kotlin Scala]第4世代 [無断転載禁止]©2ch.net

0001デフォルトの名無しさん2017/04/20(木) 04:43:27.12 ID:mNwXvrXv
いざ、語ろうぞ。

スレタイ超過のため、一部省略。
Go, Erlang, Kotlin, etcもウェルカム。
Haskellは協議により次世代失格になりました

前スレ
次世代言語議論スレ[Go Rust Haskell Scala]第3世代
http://echo.2ch.net/test/read.cgi/tech/1488608741/

00022017/04/20(木) 07:32:05.38 ID:AyFGgpwk

0003デフォルトの名無しさん2017/04/20(木) 08:19:51.38 ID:zhxiAG0o
TypeScriptも次世代言語に入れてくれ。

https://trends.google.co.jp/trends/explore?q=Golang,Typescript,Kotlin
Google社内の標準言語としてTypeScriptが承認される。ng-conf 2017
http://www.publickey1.jp/blog/17/googletypescriptng-conf_2017.html
TypeScriptが標準言語になっても、Dartのことは忘れてませんよとGoogle担当者がフォロー
http://www.publickey1.jp/blog/17/typescriptdartgoogle.html

0004デフォルトの名無しさん2017/04/20(木) 08:44:47.83 ID:jeWo4Dft
208 デフォルトの名無しさん[sage] 2017/04/19(水) 12:20:37.70 ID:rIlDsUIc

継承もカプセル化もオブジェクト指向には必要ない
クラスを作る、つまり型を定義する事こそがオブジェクト指向

265 デフォルトの名無しさん[sage] 2017/04/19(水) 23:10:42.57 ID:2dTlCsss

>>208
代数的データ型で型を定義できるHaskellはオブジェクト志向言語だった……?

266 デフォルトの名無しさん[sage] 2017/04/19(水) 23:12:01.85 ID:qOdNs+TP

>>265
代数的データ型とはなんぞや?

269 デフォルトの名無しさん[sage] 2017/04/19(水) 23:19:37.80 ID:qOdNs+TP

type c = a or b
みたいな?

270 デフォルトの名無しさん[sage] 2017/04/19(水) 23:20:37.20 ID:qOdNs+TP

これもオブジェクト指向と言ってもいいでしょう!


こんなん草生える

0005デフォルトの名無しさん2017/04/20(木) 12:21:47.82 ID:yNBy9eOM
TypeScriptはJavaScriptのクソな点をまともに直しただけで
次世代というものを感じないのだがなんかあるの?

0006デフォルトの名無しさん2017/04/20(木) 19:50:17.61 ID:VIiPRj9u
TypeScriptは次世代を担うってよりも
旧世代の資産をなんとか次世代まで持ちこたえさせるつなぎって感じ

0007デフォルトの名無しさん2017/04/21(金) 00:32:39.17 ID:TpnuMFUz
別に便利ならそれでいいと思うけど。

0008デフォルトの名無しさん2017/04/21(金) 13:54:11.80 ID:cmecYv9F
>>5
とはいえ次世代は次世代でしょ

00092017/04/21(金) 16:45:28.52 ID:KFYgHFHL
TypeScriptは手段が目的化してきてるからな。
構文は嫌いじゃないけど。

0010デフォルトの名無しさん2017/04/21(金) 23:38:23.47 ID:F8Tq/dHs
なんでHaskell無くなってるの?もう学ぶの諦めたの?

0011デフォルトの名無しさん2017/04/21(金) 23:42:05.24 ID:1EW2mi9U
うん
Haskell学ぶなんて時間の無駄だってことに気づいたの

0012デフォルトの名無しさん2017/04/21(金) 23:59:18.37 ID:9S9WRWBb
>>10
前スレでHaskellは次世代言語ではなく遅延評価に問題があるとされた。
でもHaskellの考え方を学んで他の言語で活かすならありだと思う。

0013デフォルトの名無しさん2017/04/22(土) 00:57:02.64 ID:Kjd2lTg6
問題とされたのは遅延することではなく何秒遅れるか予測不可能なことだと思う
タイミングを何秒後と指定して評価するのは問題ないとされる
現にそういう問題が出題されたしね

0014デフォルトの名無しさん2017/04/22(土) 02:36:22.27 ID:gXJYMt+Q
いやHaskellを声高にプッシュしていた奴が例題のコードも出さずに逃亡して、Haskellそんなに詳しくない人が替わりに書くという事態になったからだよ
Haskellに詳しい人もHaskellについて議論できる人もいなかったんで対象として取り上げるには不適切になった(このスレでは)
Haskell上げの意見は説得力が無いしHaskell下げの意見はただのレッテル貼りにしかならない

0015デフォルトの名無しさん2017/04/22(土) 07:18:18.45 ID:yb9XO/RM
で、Haskellよりも劣った言語が次世代言語候補として残ったわけか
おもしれーw

0016デフォルトの名無しさん2017/04/22(土) 07:49:13.55 ID:9MR2WQGe
次世代言語なんだから、現行の言語を語っても意味ないよね。

0017デフォルトの名無しさん2017/04/22(土) 09:34:02.47 ID:Kjd2lTg6
>>14
逃亡というレッテル貼りをおそれて多くの人が努力したんだな
レッテル貼りには人を努力させる効果があった
レッテル貼りは悪という意見にはあまり説得力がない
この場合、逃亡は悪ではかったと考える方が説得力がある

0018デフォルトの名無しさん2017/04/22(土) 09:54:38.02 ID:69jc9pki
>>17
最後の1行がそれより前とつながらないんだが

0019デフォルトの名無しさん2017/04/22(土) 10:24:05.10 ID:69jc9pki
糞問題、糞設計、糞実装だの言うわりにどれ一つ代替案は出てこなかった(つまりパラダイムは変えない)
加えて、正直な感想として現行言語の方が次世代と称される言語よりずっとすっきり書けていた
という現状をふまえると次世代の「売り」って何なのだろう

クラスや付随する言語機能を捨ててシンプルさを求めたこと(継承のデメリットの排除と学習コストの軽減)と
それで生じる表現力・抽象度の低下を型チェックや型推論機構の充実で補ってバランスをとったところ?

0020デフォルトの名無しさん2017/04/22(土) 10:33:00.05 ID:d4ODGBV8
HaskellとDが最底辺であることに変わりはない。
実用性皆無なプログラム言語は存在価値無し。

0021デフォルトの名無しさん2017/04/22(土) 10:40:11.00 ID:Kjd2lTg6
訂正
逃亡は悪ではかった→逃亡は悪ではなかった

>>18
レッテル貼りは悪とは限らないし、そもそも悪と戦うことが目的ではない
戦いが目的でないなら逃亡は合理的だ

0022デフォルトの名無しさん2017/04/22(土) 11:00:51.13 ID:69jc9pki
>>21
そこじゃない!www>訂正

逃亡というレッテル張りを恐れて他の善意のファンが努力
→レッテル張り自体は悪だが結果はそう悪いものでもなかった

という流れからどうして逃亡自体が悪でないという帰結が導かれるのか?
ひたすら机上の空論を展開し、他を貶め、蔑み、悪態をつくだけついて
じゃあ動くコードやよりよい設計を出せというと逃げるのはどうみても身勝手だろう

0023デフォルトの名無しさん2017/04/22(土) 11:14:59.00 ID:Kjd2lTg6
悪口を言われたから賠償してほしいって?
そんな出題者の意図があるとは知らなかった

0024デフォルトの名無しさん2017/04/22(土) 11:36:19.62 ID:69jc9pki
>>23
この場合、出題者は関係ないだろう
「他を」は「他言語(あるいはその使い手、ファン、コミュニティ)を」だ

0025デフォルトの名無しさん2017/04/22(土) 11:53:17.53 ID:69jc9pki
なんかいちいち噛み合わないな
もしかしてHaskell儲がまだいるのか?
なら逃亡行為を好意的に解釈したがるのも頷ける

0026デフォルトの名無しさん2017/04/22(土) 12:24:45.77 ID:VCLbyEjA
あんまり荒らしたくはないが、できるかできないかで言えばできたんだから問題ないだろ
それにType Classのコード理解できるやつ何人いた?
単なる継承だと勘違いしてるっぽい奴はいたが

0027デフォルトの名無しさん2017/04/22(土) 12:38:09.97 ID:yb9XO/RM
そもそも単価の高いHaskellerにタダでコード書けというほうが間違っている

0028デフォルトの名無しさん2017/04/22(土) 13:11:14.86 ID:69jc9pki
>>27
旧世代言語なら実質50行程度せいぜい10分で書けるコードにいくら請求するつもりだよww

それに単価ならカンブリア言語のSmalltalkerの方がよほど高いわ
奴ら呼べばきっと頼まれなくてもホイホイ書くぞ
Rust使いに次いで自分言語大好きだからな
https://developers.srad.jp/story/17/03/31/0448232/

0029デフォルトの名無しさん2017/04/22(土) 13:55:32.78 ID:/fxOrStV
どうせお前ら、フレームワークに用意されたメソッドを
サンプル通りに呼び出すだけのドカタだろ?
次世代言語なんて要らんだろ

0030デフォルトの名無しさん2017/04/22(土) 14:38:27.32 ID:XG8YtWUq
そういう言語こそ切望されている。

0031デフォルトの名無しさん2017/04/22(土) 19:55:27.63 ID:2QNaIclJ
次世代言語ならおっさんにマウントされずに
仕事できると思ってるバカが多いってだけなんだよ結局。

0032デフォルトの名無しさん2017/04/23(日) 13:37:29.12 ID:mKAZq6VZ
新スレ

abc系でみんなで人工知能を作ろう!
http://echo.2ch.net/test/read.cgi/tech/1488681839/

0033デフォルトの名無しさん2017/04/23(日) 14:04:42.00 ID:NE9/Voyw
個人的にはスレタイからRustも抜いてほしい。まともに物が作れないのにクソモジラのステマだけで話題になってる、言語未満のクソの塊。

0034デフォルトの名無しさん2017/04/23(日) 14:08:54.35 ID:HdKb/Sdq
このスレは何を目指してるの?

0035デフォルトの名無しさん2017/04/23(日) 15:35:02.72 ID:zop66JA+
よく分からんよね
いつか知らないけど、次に主流になる言語が何かを決めたいんだろう

0036デフォルトの名無しさん2017/04/23(日) 15:41:50.81 ID:OBcWFFpc
もう全部C++でいいんじゃないかな
これから100年先までずっとC++だ

0037デフォルトの名無しさん2017/04/23(日) 16:07:52.01 ID:UJAzDyB2
>>36
それでいいそれで。他を圧倒的に突き放して一番早くて実用的な言語だ。

0038デフォルトの名無しさん2017/04/23(日) 16:10:21.34 ID:svTWBXfu
多次元配列弱いC++はFortran以下
まず配列アクセス演算子が引数一つしか取れない時点で終わってる

0039デフォルトの名無しさん2017/04/23(日) 16:16:54.85 ID:dVBaHUf3
そりゃ、関数で十分だからな。テンプレートとオーバーロードと参照があれば
配列アクセス演算子なんて最初から必要なかった。

0040デフォルトの名無しさん2017/04/23(日) 16:20:47.89 ID:svTWBXfu
まあ確かにEigenなんかは関数呼び出し演算子で代用してるな
そのEigenでさえ3次元以上には対応してないっていうのがC++の自由度の低さを物語ってるが

0041デフォルトの名無しさん2017/04/23(日) 16:24:19.41 ID:UJAzDyB2
逆に聞くけどそれなくて何か実用的なプログラミングで困るの?

0042デフォルトの名無しさん2017/04/23(日) 16:29:32.67 ID:mKAZq6VZ
C++++あくしろよ

0043デフォルトの名無しさん2017/04/23(日) 17:38:01.40 ID:svTWBXfu
>>41
深層学習とか統計処理とかには必須だぞ
量子化学にもあれば便利だな
データ整理一般にも使うしな

0044デフォルトの名無しさん2017/04/23(日) 19:47:31.29 ID:zjYzndui
いや、そんな要素一つ一つに対して別個の処理をするようなコードは
あんまいらんだろ。
本当に必要な場合は結局、配列レベルで高速化が望まれる場合だけだし。
誰かが用意した python のライブラリでも使ってなさいってこった。
カスが個人的に作ったものよりもよっぽど速くて正確なものがあるんだから。

0045デフォルトの名無しさん2017/04/23(日) 20:12:53.69 ID:svTWBXfu
Python >>>> C++が証明されたな
速度においてもCython擁するPythonが負ける要素はないし

0046デフォルトの名無しさん2017/04/23(日) 20:19:34.87 ID:PCQQgnKm
C++er「もう全部C++でいい」
配列マン「多次元配列需要あるのにC++にはないやん」
C++er「そんなもんあんまいらんだろ。Pythonでも使ってなさいカス」

C++erってやっぱダブルスタンダードのカスだわ

0047デフォルトの名無しさん2017/04/23(日) 20:36:30.78 ID:zjYzndui
用途によって使い分けるという当たり前の発送のないバカと一緒にされたくないんだけど。。

0048デフォルトの名無しさん2017/04/23(日) 21:11:17.67 ID:OBcWFFpc
皮肉なのにマジで取られても

0049デフォルトの名無しさん2017/04/23(日) 21:15:41.28 ID:PCQQgnKm
あとはID:UJAzDyB2だけか

0050デフォルトの名無しさん2017/04/23(日) 21:50:20.49 ID:bkkcl6Xn
多次元配列とはいえ結局は仮想メモリ上に一次元に乗るデータになるんだから、多次元→一次元マッピングを最初から最適にデータ設計出来てればいらんだろそんなもん。
そこを処理系任せにしてメモリ上のデータ構造チューニングできないようなものが次世代言語なのか?

0051デフォルトの名無しさん2017/04/23(日) 21:51:12.16 ID:bkkcl6Xn
あ、ID変わったけどID:UJAzDyB2。

0052デフォルトの名無しさん2017/04/23(日) 22:10:15.66 ID:bkkcl6Xn
最先端のアルゴリズムで実用ライブラリを書く言語としてのC++はこの先100年安泰で、
ラッパ用スクリプトのPythonとはそもそも言語としての立ち位置が違うって話。

0053デフォルトの名無しさん2017/04/23(日) 22:22:19.93 ID:mKAZq6VZ
100年後の言語ってどうなってんだろな
頭にチンポ型の伝送デバイスハメるだけでプログラミングできたりする?

0054デフォルトの名無しさん2017/04/23(日) 22:24:04.51 ID:NBHRohTD
そりゃもう感応入力で思考の速度でプログラミングできてるだろう
言語はなくなってるかもしれん

0055デフォルトの名無しさん2017/04/23(日) 23:40:41.71 ID:OBcWFFpc
C++を今の地位から引きずり下ろすためにもRustには頑張って欲しいものだ

0056デフォルトの名無しさん2017/04/24(月) 00:14:14.60 ID:Hq5/eqGq
言語がなくなる
科学がなくなる
数学がなくなる
こういう無数の可能性から一個選んで的中させるのはほぼ不可能だよな

0057デフォルトの名無しさん2017/04/24(月) 00:21:20.12 ID:lffXTkps
ID:bkkcl6Xnの発言は一番気が狂っていた頃のエンジニアガイジと似てるな

0058デフォルトの名無しさん2017/04/24(月) 00:26:31.35 ID:6h5JoTUe
>>36
早くネットワーク系のライブラリを標準で入れてくれぃ

0059デフォルトの名無しさん2017/04/24(月) 00:33:57.43 ID:6NGlh03T
ID:UJAzDyB2「C++は実用的な言語である。多次元配列がなくても実用的なプログラムでは困らない」
ID:bkkcl6Xn「私はID:UJAzDyB2である。C++は実用ライブラリを書くための言語だ」

なにこれ

0060デフォルトの名無しさん2017/04/24(月) 00:40:56.94 ID:zwhieng4
>>50
多次元配列でチューニングすべきところなんかあるか?せいぜい格納方向が2通りあるくらいだろ。チューニング出来るものは一切搭載してないFortranにすらデフォルトで搭載されてる機能だぜ?
それにそれ言っちゃあSTLなんてどうなるんだよ? まさかSTLは使うけど多次元配列は自分で作るなんて言わないよなあ?

0061デフォルトの名無しさん2017/04/24(月) 00:56:56.87 ID:FOMNUfbf
>>60
ガチ用途でSTL使わねえだろバカも休み休み言えよ……
STL使うC++なんてちょっと速いPythonやらRubyじゃねえか。

0062デフォルトの名無しさん2017/04/24(月) 00:58:00.30 ID:zwhieng4
>>61
ほーんSTLより速いの書いてあげてみ?
絶対無理だろ

0063デフォルトの名無しさん2017/04/24(月) 01:04:22.49 ID:FOMNUfbf
>>62
そりゃ自分の書くものに一番合うように書くから、あらゆるベンチを通すように丸く作られたSTLに全分野で勝てるわけないだろ。

0064デフォルトの名無しさん2017/04/24(月) 01:10:06.24 ID:zwhieng4
>>63
この用途ならこれが一番速くて信頼性が高くて拡張性も優れていて、自分で書いてSTLを使わないコストという面でも釣り合いが取れるっていうのがあるってことだよな?
用途から自分で設定していいから書いてみろよ。

0065デフォルトの名無しさん2017/04/24(月) 01:16:51.68 ID:lffXTkps
いや、そもそも多次元配列の話してたんだし、numpyを超えるスピード、信頼性の多次元配列を書いてもらうべきだな

0066デフォルトの名無しさん2017/04/24(月) 01:19:28.66 ID:p282pyvh
疎行列

0067デフォルトの名無しさん2017/04/24(月) 01:22:28.66 ID:zwhieng4
ああ、そもそもSTLで出来ないことを書いて「勝った」っていうのはなしだぞ。それこそ疎行列とかな

0068デフォルトの名無しさん2017/04/24(月) 01:30:31.10 ID:p282pyvh
ハッシュマップ

0069デフォルトの名無しさん2017/04/24(月) 01:36:23.44 ID:zwhieng4
ってか割と真面目にC++上で動く多次元配列欲しいんだけど
1〜5次元くらいまで同じインターフェースで動く奴作ろうとして、思いの外面倒だったから辞めてFortranに乗り換えたことあるんだよな

0070デフォルトの名無しさん2017/04/24(月) 06:51:30.21 ID:wCWPirmZ
>>42
亀だけど、C#って、C++++という意味を込めてるんだよ。

0071デフォルトの名無しさん2017/04/24(月) 20:17:17.36 ID:zyXx2ugF
>>65
だよねぇ、多次元配列の操作で Python に勝るのは Fortran くらいしか思いつかないや
純粋手続き型言語の始祖である Fortran と、同じく純粋手続き型スクリプト言語である
Python、誰にも否定できない当然の結果だよね

もう、このスレでは次世代 Fortran は Python で決まり!!ってこと結論が出たね

0072デフォルトの名無しさん2017/04/24(月) 21:50:54.50 ID:CyDBAtYH
その結論は何を表すの?

0073デフォルトの名無しさん2017/04/24(月) 23:19:46.46 ID:H47kwRKj
>>71
多次元配列操作で次世代言語を選ぶならJuliaだろう。

Python使いをJuliaに引き込むサンプル集
http://www.mwsoft.jp/programming/julia/python_to_julia.html
RユーザのためのJulia入門(行列編)
http://rishida.hatenablog.com/entry/2013/11/30/194733

0074デフォルトの名無しさん2017/04/24(月) 23:52:45.18 ID:lffXTkps
Juliaのステマ貼るならせめて最新版の解説貼れよ
ないけどさ

0075デフォルトの名無しさん2017/04/25(火) 00:38:05.23 ID:O6VBfE9R
>>74
Qiitaで検索するかAdvent Calendarsを読め。
普及が始まっている次世代言語は
たいていAdvent Calendars 2016がある。

0076デフォルトの名無しさん2017/04/25(火) 02:23:12.66 ID:wELv0O7d
言語オタクが重視する言語間の細かいシンタックスの差なんてどうでも良くて、
次世代言語に必要だったのは高速で便利な多次元配列だったってオチか

0077デフォルトの名無しさん2017/04/25(火) 08:40:21.09 ID:fJvGo7FT
>>75
Julia0.3の化石みたいな記事貼るなって意味だよ

0078デフォルトの名無しさん2017/04/25(火) 10:54:45.65 ID:niXLk7Hx
Juliaって化石なの?

0079デフォルトの名無しさん2017/04/25(火) 10:55:45.34 ID:cMLOigtr
0.3はね
そろそろ0.6

0080デフォルトの名無しさん2017/04/25(火) 11:10:54.53 ID:x9Sc69FW
>>76
多次元配列が必要な人間は一部だけど文法が全員に影響があるから、多数決で文法優先
オタクではなく多数決です

0081デフォルトの名無しさん2017/04/25(火) 11:51:27.86 ID:DZfkzF9H
RubyとPythonとか観てると文法より多次元配列やライブラリのが重要だと実感するが。
C#やJavaScriptにしても、簡潔に書けるとかじゃなくて何を作れる(サポートするプラットフォームの多さ)で選ばれてるし。

0082デフォルトの名無しさん2017/04/25(火) 12:35:16.20 ID:0RXyPjWo
利用者が多い・ライブラリが豊富って現在流行っているものの話でしょ

0083デフォルトの名無しさん2017/04/25(火) 12:35:23.60 ID:KAzBuoYA
多次元配列が重要って感覚がわからないんだけど、
どういう分野の人が使うの?

00842017/04/25(火) 12:49:25.85 ID:m9LocPpZ
多次元配列ってジャグじゃないものの事だよな?
マクロ書いちゃえばいいんでないの?
アクセス演算子と大仰な言い方するが、要は単に掛け算なんだし。アライメントも揃えられるしさ。

適当な並べ方してるとメモリアクセスで悲しい思いをする気がする。特にどーんとクラスタに投げるときとか。
Fortranでもメモリマップ的には後ろの列からの順番になるから思い付きで並べると重いよ。

00852017/04/25(火) 12:51:38.43 ID:m9LocPpZ
>>83
テンソルに係数を掛けたり、テンソルとベクトルを掛けたりすると、欲しくなるのは確か。
unionって思ってたより随分便利だなーって思うやつ。

0086デフォルトの名無しさん2017/04/25(火) 12:56:48.67 ID:DZfkzF9H
>>82
Rubyが流行りそうになった時、RoRの登場で一躍有名になった。
Pythonにはそれに相当するものが無かった。
後に同じようなの出来たけど、Rubyを引き離すほどじゃ無かった。
Ruby1.9の時、互換性切り捨てでRuby自滅が決定打だった。
結果としてディープラーニング向けライブラリの登場で揺るぎない地位を得た。

文法はRuby1.9以降のが好きだし理に適ってる。
でも、世界的には終わった言語。

00872017/04/25(火) 13:06:52.92 ID:m9LocPpZ
Rubyは理想を追いかけ過ぎ。
自然言語で言えば、エッセイストは言語学者じゃないのに形態素に基づくなんとかかんとか、こういうしきたり、こういうルールってのを並べられてもって感じで、
しかも、言語学者側はそれを素晴らしいと絶賛してると言う狂った状態に近い。

英語なんかあんな破綻した闇仕様に溢れた言語
(例えば、Shipの口語の代名詞に失われた性を補完してsheを使う)なのに、
あんなに全世界で使われてるんだから。

言語なんて歯ブラシなんや、ってPHPの方が随分スタンスとして好き。

0088デフォルトの名無しさん2017/04/25(火) 13:39:27.32 ID:9lYWlQQl
次世代の定義と合わなくね?って書き込みになんでそんなレスがつくんだろ

0089デフォルトの名無しさん2017/04/25(火) 13:59:47.20 ID:DZfkzF9H
かつて次世代だった言語の栄枯盛衰から、次世代言語に何が必要かが分かると思って投下した。

0090デフォルトの名無しさん2017/04/25(火) 14:18:46.85 ID:x9Sc69FW
文法は繁栄の原因にはならないけど互換性云々で衰退の原因になるんだ

00912017/04/25(火) 14:31:36.92 ID:m9LocPpZ
>>88
あんまり原理主義的な事話してると怒られるから。。

0092デフォルトの名無しさん2017/04/25(火) 14:54:40.56 ID:3KXt8ND/
文法は繁栄の原因にもなり得たよ。
Rubyも注目された当初は簡単でなんでも出来る言語としてsmalltalk作ったけど、真のsmalltalkはRubyだったとかアラン・ケイも絶賛してたし、RoRもRubyの文法に惚れて作られた。
その後の保守戦略家で差が付いた。

0093デフォルトの名無しさん2017/04/25(火) 14:55:18.59 ID:3KXt8ND/
x保守戦略家
o保守戦略

0094デフォルトの名無しさん2017/04/25(火) 18:40:55.97 ID:x9Sc69FW
戦略ってなんだろう
どうやって決めたかは教えないけど、成功とか失敗とか成果だけ教えてやるよって感じ
成果だけが重要と思っているからなのか

0095デフォルトの名無しさん2017/04/25(火) 18:52:57.84 ID:e9WI/SQ5
>>86
>Ruby1.9の時、互換性切り捨てでRuby自滅が決定打だった。

互換性切り捨てってのは、これのこと?

http://echo.2ch.net/test/read.cgi/tech/1413113999/128

うーみゅ、確かに Hello world レベルのお題ですら動かなくなるようでは、
互換性切り捨てと批判されるのも仕方ないよね

0096デフォルトの名無しさん2017/04/25(火) 19:19:36.86 ID:gy+i7xO9
>>94
戦略って言っても、私が結果だけ見てそう判定しただけだがね。
結局、言語の開発管理側が業務で使われているって事実を重要と見たかどうかってだけ。
どっちも互換性切り捨ててるんだけど、Pythonはまだ旧バージョン系列サポート切ってないし、長々とアナウンスしてる。

0097デフォルトの名無しさん2017/04/25(火) 19:40:02.70 ID:e9WI/SQ5
訂正してあげるね

X:Pythonはまだ旧バージョン系列サポート切ってないし
O:Pythonはまだ旧バージョン系列サポート切れないし

Pythonはまだ新旧バージョンでの後方互換性切り捨てが災いして、
未だに旧バージョン系列から新バージョン系列へ移行できていないだけの話
だから旧バージョン系列サポートを切りたくても切れないってのが現実

http://blog-imgs-82.fc2.com/n/o/r/noriaki3/201508310726369c2.jpg

0098デフォルトの名無しさん2017/04/25(火) 20:00:00.53 ID:DCpQVXaD
それが企業に好感持たれてる現実。
強行したRubyはどうなったよ。

0099デフォルトの名無しさん2017/04/25(火) 20:09:39.00 ID:e9WI/SQ5
こうなった
http://echo.2ch.net/test/read.cgi/tech/1486026729/900

ところで、Rubyの互換性切り捨てとは具体的には何を指しているのかな?
少なくとも Hello world レベルであれば、RoR登場以前の 1.6 から最新の 2.2 に至るまで、
Ruby であれば Syntax Error にならず正常動作するから互換性は維持されているけどね

0100 ◆QZaw55cn4c 2017/04/25(火) 20:17:10.34 ID:Vqnsayjn
>>87
うーん,LL(1)に徹している pascal が古今東西素晴らしいとおもっているんだが‥ruby ってそんなにすごいの?

0101デフォルトの名無しさん2017/04/25(火) 20:37:45.43 ID:KIIhfRh7
Rubyが理想を追いかけてるとか、苦笑しか出てこない。

0102デフォルトの名無しさん2017/04/25(火) 20:45:57.84 ID:MvOKB5m4
>>100

低機能パーザー使うと何ですごいの?

0103 ◆QZaw55cn4c 2017/04/25(火) 21:06:43.69 ID:Vqnsayjn
>>102
>自然言語で言えば、エッセイストは言語学者じゃないのに形態素に基づくなんとかかんとか、こういうしきたり、こういうルールってのを並べられてもって感じで、
だろうね

0104デフォルトの名無しさん2017/04/25(火) 21:16:47.80 ID:qd1hD0YR
結局、キャットドア問題解決できなかったしね

0105デフォルトの名無しさん2017/04/25(火) 22:43:32.29 ID:lEn+EjQK
python3 とか好きじゃないんだよな。。
1/ 2 = 0.5
とか型が弱くなる方向に修正したんだか。。
明示的に書かせるのが python の良さなのにそれと逆行しようとしてるのが好きになれん。

01062017/04/25(火) 23:45:33.40 ID:RguWTiRy
>>100
pascalは素晴らしいと思うよ。俺も。
いつの間にか呼ばれてるto_intみたいな馬鹿な仕様もないし。
あれは理想ではなくて現実。
>>101
追いかけてるだろー。
「Objectには不要なものが多すぎる、好ましくない。でも、互換性失いたくない。
 そうだ、Objectの親にBasicObjectを作って白紙のオブジェクトとしよう」
なんてまともな神経してたらちょっと思いついたけど敢えて忘れるレベルの実装をマジでやった上に、
一番やめてほしい==の実装をBasicObjectに持ってったんだぞ。
気が狂ってる。
わざわざtrueClassやらnilClass作ってたのが原理主義っぽくて良かったのに。
n = true if false
で、nがnilになるのもおかしい。
n = n+1でnilに+はねえよってメッセージの原因だけど、こればっかりは異常。

0107デフォルトの名無しさん2017/04/25(火) 23:47:17.89 ID:qd1hD0YR
>>106
言葉に気をつけろよ
キャットドア問題の前にお前らはボロ雑巾のように敗れ去っているのだから

01082017/04/25(火) 23:50:40.24 ID:RguWTiRy
メッセージパッシングで大枠作ったのにな

そもそも、クラスを破壊せずに機能追加せよ、って矛盾した設問がおかしい事にまだ気づかんのかなぁ。

0109デフォルトの名無しさん2017/04/26(水) 00:00:43.82 ID:T5a4wmc6
>>100
俺もpascalはシンプルで好きな方。
だけどブロックは波括弧が好きなんだよなぁ。

0110デフォルトの名無しさん2017/04/26(水) 00:34:00.42 ID:Boe/ixbX
>>99
うろ覚えだが、文字列から文字を取り出すのが思い切り変わった。
これは阿鼻叫喚になるなって印象はあった。

0111デフォルトの名無しさん2017/04/26(水) 00:43:56.99 ID:9BTWZVlt
>>110
>うろ覚え
正しくは。うる覚え。な
学がないやつはこれだから

0112デフォルトの名無しさん2017/04/26(水) 03:53:03.15 ID:2ISuU/qN
スレタイからElixir抜いた奴俺の許可とったの?

01131012017/04/26(水) 04:48:11.60 ID:gEnKLRTK
>>106
Objectクラスの親クラスにProtoObjectクラスがあるのも、
==をProtoObjectで実装するのも、
TrueクラスやUndefinedObjectクラスがあるのも、
false ifTrue: [true]がnilになるのも、
みんなSmalltalkでは理想どころじゃない、
ProtoObjectは90年代のOO普及期からずっと当たり前のこと、
それ以外は80年代のOO黎明期からずっと当たり前のことだが、
どこがどう理想なのか、どこがどう次世代なのか、教えてくれよ。

0114ich12017/04/26(水) 07:20:16.12 ID:KcpaNie5
https://goo.gl/Y4tSAe
これは嘘でしょ?
本当なら落ち込むわ。。

0115デフォルトの名無しさん2017/04/26(水) 07:22:08.94 ID:xY5d2zmE
「うろ覚え」の誤り。「うろ覚え」は、はっきりと覚えていない様子を意味する語。空洞を意味する「うろ」が、文字や音の似た「うる」に置き換わって生じたといわれている。ネットスラングとしては、「ふいんき」と同様に、誤記を承知で敢えて用いられる例が見られる。

ネットスラングとしては、「ふいんき」と同様に、誤記を承知で敢えて用いられる例が見られる。
ネットスラングとしては、「ふいんき」と同様に、誤記を承知で敢えて用いられる例が見られる。

0116デフォルトの名無しさん2017/04/26(水) 08:01:30.06 ID:70MJdvvC

0117デフォルトの名無しさん2017/04/26(水) 08:02:47.44 ID:GreYiU3v
>>71
Python の配列って、list でしょ?

01182017/04/26(水) 08:27:05.94 ID:aLqmc7M7
>>113
だから、理想に走りすぎで現実見えてないって言ってるの。その論調だとsmailltalkが自然で目指すべきだと聞こえるが?俺はそうは思わないけど。
泥の中の蓮的な理想感はあるが、実際にはそんな物が必要ならそれこそRubyなんか使ったら劣化コピーで気持ち悪いものをこねくり回して満足してる学者大先生と同じ。
エスペラント語を素晴らしいと言いはって、エスペラント語でエッセイ書くようなもんだ。書いてみりゃわかるが、無謀だよ。
正しくしか書けないし、元の発想が比喩で作られてるようなもんだから、比喩表現は比喩の比喩になってもう意味がわからない姿になる。
永遠に次世代になりたくて、実は永遠に次世代ではない。

0119デフォルトの名無しさん2017/04/26(水) 09:01:42.16 ID:uVr9LBvI
エッセイなら正しく書けばいいだろ。
ポエムは難しいけど。

0120デフォルトの名無しさん2017/04/26(水) 09:43:39.33 ID:A4NmaPdj
>>111
思い出したよ。
Stringクラスからeachメソッド無くなって、each_lineとかeach_charsになったんだ。
お陰で配列と同じように扱ってたのが、文字列だけ別扱いになったから、ダックタイピング出来なくなった。

あと文字コードの扱いとか。

詳細はこっち。
https://www.oreilly.co.jp/community/blog/2009/05/changes-on-ruby-1-9.html

0121デフォルトの名無しさん2017/04/26(水) 10:59:41.81 ID:pV6k193k
スクリプトは純粋仮想関数が無意味だからクラスの意味をこじつけるのが大変
Pythonのクラスは演算子を定義する機能のような印象

01222017/04/26(水) 12:47:25.64 ID:aLqmc7M7
>>119
小論文の意味のエッセイなら割とそうだろうけど、それでも主観の表現方法を無理やり曲げられる時点でダメだろ。
グーグルをラ行五段活用する事を無理に実現するために他の名詞が巻き沿い食う感じ。

0123デフォルトの名無しさん2017/04/26(水) 13:48:30.98 ID:pV6k193k
経験則
表音文字に依存するな、記号に依存しろ

0124デフォルトの名無しさん2017/04/26(水) 15:44:49.66 ID:TQfkYYQc
(みんなあってもよくね?と思ってたはずなのに)
ずっとクラスベースを拒否し続けたJavaScriptも
ある意味プロトタイプベースの理想を追い続けてるような

01252017/04/26(水) 16:06:30.69 ID:aLqmc7M7
>>123
まぁ、恐ろしいほどに無意識に使ってるスペースなんて記号も英語ベースだしな。
コアダンプが漢詩のように見える事もあるけど。

>>124
あれはあれで、リストをああいう形で実現した時点で割と言語としては完成してた。冗長だけど。

0126デフォルトの名無しさん2017/04/26(水) 21:50:24.12 ID:SZlYFMhx
>>98
>それが企業に好感持たれてる現実。

Hello world すら Syntax Error になってしまう(>>95)ほどの壊滅的な
後方互換性切り捨てを強行してなお旧バージョンのサポート打ち切りなんて、
常識的な企業倫理からはありえないだろ
そんな対応を指して「好感」という言葉は冷酷な皮肉でしかない

あるいは、過去に Hello world がバージョンアップで動かなくなったメジャー言語が存在するの?

print が文なのか関数なのかという言語とライブラリ設計における根源的な決定、
言い換えると入出力処理は構文で実現すべきなのか(すなわち文)、それとも
ライブラリで提供すべきなのか(すなわち関数または手続き)という言語設計の哲学、
そんな初歩的な判断すらできない人物によって行き当たりばったりに設計されたのが
Python だろ

0127デフォルトの名無しさん2017/04/26(水) 22:30:36.25 ID:SZlYFMhx
>>120
$ irb1.9
irb(main):001:0> "abc".each { |x| p x }
NoMethodError: undefined method `each' for "abc":String
from (irb):1
from /usr/bin/irb:12:in `<main>'

うん、確かに実行時エラーになった
では、ここで呪文を唱えてみよう

irb(main):002:0> class String; alias :each :each_char; end
=> nil
irb(main):003:0> "abc".each { |x| p x }
"a"
"b"
"c"
=> "abc"
irb(main):004:0>

あれ、おかしいなあ、Ruby 1.9 の String クラスなのに、Ruby 1.8 と同じく
配列と同じように扱えるようになったぞ、しかも元のコードは一切改変されていない
いったいどうなってるんだあ…

01282017/04/26(水) 23:16:03.93 ID:WASTpqE2
メソッド生やしてしまえる事自体がオブジェクト指向でも何でもない気持ち悪さ。

0129デフォルトの名無しさん2017/04/27(木) 00:01:25.31 ID:GJNrvvrA
Open Class だろ。モンキーパッチ

0130デフォルトの名無しさん2017/04/27(木) 00:31:22.08 ID:1+VMbtmi
>>128
その理屈だとSmalltalkはオブジェクト指向じゃなくてなんだったんだ?

0131デフォルトの名無しさん2017/04/27(木) 00:39:07.48 ID:NvHKpotz
Stringは定数ではなくグローバル変数のように改変される
全ての関数をクラスという箱に入れた結果全てが事実上のグローバル変数になった

0132デフォルトの名無しさん2017/04/27(木) 00:55:55.98 ID:jbk1ehAe
>>131
見方によってはそう(グローバル変数)なんだよね。
スコープは狭い方が良い。
正直オープクラスはイマイチと思うのだが、でもjavascript はそのおかげでpolyfillとかできるんだよな。

01332017/04/27(木) 01:20:41.99 ID:S1ERYEjc
>>130
Smalltalkはレシーバだろ

0134デフォルトの名無しさん2017/04/27(木) 02:05:35.72 ID:XheCn2mn
>>133
記法の問題ってこと?

0135デフォルトの名無しさん2017/04/27(木) 07:23:11.77 ID:1+VMbtmi
>>134
ビヤーネ・ストラウストラップらの抽象データ型のOOP(カプセル化、継承、多態性)と
アラン・ケイの遅延結合徹底のOOP(オブジェクトにメッセージを送る)は別物だって事をいいたいのかな

0136デフォルトの名無しさん2017/04/27(木) 07:38:57.38 ID:0Df9bF2U
Smalltalkがウンコ過ぎて世間からそっぽ向かれて死滅したんだから
後追いのRubyも死滅するのは歴史が証明している

01372017/04/27(木) 08:15:10.34 ID:YQ2WW8c/
>>135
そう。パッシングの口でしかない。

0138デフォルトの名無しさん2017/04/27(木) 08:28:33.27 ID:/s/zy9NN
まさか、rubyがADT拡張としてのOOPLだと思ってる?

0139デフォルトの名無しさん2017/04/27(木) 08:44:30.71 ID:N3r3uYtr
>>136
死滅したとか記憶から消し去りたいロートルがいる一方でスタートアップで勝負をかける奇特な人もいる
http://pharo.org/success/AllStocker
スタートアップ界の異端児!産業機器 x IT x SmalltalkのSORABITO株式会社
https://thepedia.co/article/1068/

Smalltalkのとらえ方は人それぞれやね

0140デフォルトの名無しさん2017/04/27(木) 08:58:08.10 ID:/s/zy9NN
Smalltalkはうんこすぎて死滅したと2ちゃんでクダ巻いてるだけの爺さんを横目に、
今日もSmalltalkが世界の海上コンテナ輸送の30%を捌いているわけだが。

0141デフォルトの名無しさん2017/04/27(木) 09:17:39.03 ID:N3r3uYtr
>>140
OOCLのことを言っているんなら、あれってJavaに置き換えられたんじゃないの?

Who uses Smalltalk? : programming - Reddit
https://www.reddit.com/r/programming/comments/3wv7ik/who_uses_smalltalk/cxzzhkp/

0142デフォルトの名無しさん2017/04/27(木) 09:25:15.12 ID:wBdpEusi
>>140
もしかしてOOCLのこと言ってんの?
とっくにそんなシェア無くなって、今年に入って買収の噂が出るくらい落ちぶれてるぞ

0143デフォルトの名無しさん2017/04/27(木) 10:07:04.57 ID:Cz6WFEXA
爺さん批判してる奴の知識が爺さんだったか

0144デフォルトの名無しさん2017/04/27(木) 10:10:47.76 ID:sNquU9cU
Smalltalkがどうこう以前にファンやアンチがうんこすぎてわらた

0145デフォルトの名無しさん2017/04/27(木) 10:12:00.41 ID:/ppzzK1q
Smalltalk信者とHaskell信者はよく似てる

0146デフォルトの名無しさん2017/04/27(木) 12:35:13.63 ID:/s/zy9NN
>>141
よく読め。再実装されたのはUIだけだ。あほか?

0147デフォルトの名無しさん2017/04/27(木) 13:02:15.04 ID:jfFmbm9g
>>146
なんでとても素晴らしいsmalltalkで再実装されなかったの?

0148デフォルトの名無しさん2017/04/27(木) 13:17:16.51 ID:+ggBtOYn
おそらく同じ言語で再実装するとeachをeach_charに変えたくなるから
そんなことするなら言語ごと変えた方が良い

0149デフォルトの名無しさん2017/04/27(木) 14:09:11.99 ID:Yjb8fh0C
>>147
Smalltalk は開発環境含めてあまりにオールインワン過ぎるから。

0150デフォルトの名無しさん2017/04/27(木) 17:05:36.01 ID:sNquU9cU
>>146
そんなどーでもいいことより30%シェア撤回マダー

0151デフォルトの名無しさん2017/04/27(木) 20:07:13.14 ID:PwOPvcNg
どーでもいいな、クソくだらねえ。

0152デフォルトの名無しさん2017/04/27(木) 20:28:54.10 ID:zXLo9cW8
もう死んでる言語を追い詰めても仕方ないよな
死体蹴りは良くない

0153デフォルトの名無しさん2017/04/27(木) 22:14:26.81 ID:McKGSVbG
もう風化してて蹴るものもないと思ったのに

0154デフォルトの名無しさん2017/04/27(木) 22:36:43.95 ID:+ggBtOYn
風化すればまた再発明される
過去に同じことがあったと口で言っても証拠が残ってなければ同じことが繰り返される

0155デフォルトの名無しさん2017/04/27(木) 23:26:29.59 ID:Yjb8fh0C
死んだ言語の死んだ理由ってのは新しい言語の糞機能アピールよりかは勉強にはなる。

0156デフォルトの名無しさん2017/04/28(金) 08:28:08.68 ID:WPyfQjET
死んだ言語ねえ…
死んでるのはおめーの脳みそだろ?

http://pharo.org/success

0157デフォルトの名無しさん2017/04/28(金) 08:55:25.45 ID:j+L8+G8p
SmallTalkガイジって一番ガイジだった頃のエンジニアガイジとちょっと似てるな

01582017/04/28(金) 17:12:11.94 ID:Yq+yDopp
>>157
いつでも同じクオリティじゃないか

0159デフォルトの名無しさん2017/04/28(金) 20:19:57.31 ID:j+L8+G8p
>>158
最近文読みやすくなってきてるしちょっとええ感じやで

01602017/04/28(金) 20:29:25.20 ID:0gV62uUk
>>159
まぁ具体的に「パラグラフが長い」「言い回しがくどい」と言われたら、
なるほどと思うし、ちょっと気を付けられるからな。
読みにくい、ガイジか!とだけ言われたら、読みにくいだけならしっかり読めとしか言いたくなくなる。

0161デフォルトの名無しさん2017/04/29(土) 02:55:48.56 ID:R+WhfS42
シミュレーションをより簡略に作成するための新言語開発を。

「ロボットは東大に入れるか」成果報告会 in 2016(11/14)レポート
http://blog.livedoor.jp/dg_law/archives/52354118.html

これからはシミュレーションシステムの構築が簡略化されるので、来年のセンター物理は大きく得点が伸びるに違いない。

 スーパーコンピュータでの計算に必要となるプログラムはときに数十万行にも及び、作成やチューニングは大変困難です。
一方で、原理的にはシミュレーションしたい自然現象とその離散化法(注2)を指定すれば、プログラムは機械的に生成できます。
しかし、プログラミングはシミュレーションとコンピュータ双方に深い知識が必要となる非常に高度な作業であり、多数の計算機を
協調して動作させるスーパーコンピュータの性能を引き出す高度なプログラムを、自動かつ汎用的に生成することは不可能でした。
 そこで共同研究グループは、方程式がプログラムに変換されるまでの一連の段階に対応する数学的定義を作りました。
スーパーコンピュータが持つ階層のすべての段階において、自然が元来備えている「並列性」と「局所性」(注3)を保持する変換
を厳密に定めることで、新たなプログラミング言語「Formura」を開発しました。これによって、これまで不可能だったプログラミング
の機械化に成功しました。さらにFormuraは、同じアプリケーションに対して何万通りものプログラムを試し、最も速かったものを自動的に選択します。
 Formuraを開発したことで、規則格子シミュレーション(注4)分野においては、自然科学者が慣れ親しんだ方程式の記法を使ってシミュレーション
したい対象を記述することで、スーパーコンピュータの性能を引き出すための高度なプログラムが自動的に作成できるようになりました。
気象、地震、宇宙、生態ネットワークの研究など、規則格子シミュレーションを用いる分野の研究の加速が期待できます。
http://pr.fujitsu.com/jp/news/2016/12/2.html

01622017/04/29(土) 12:11:59.50 ID:R/nsoadB
投機ベースは確かに分野限られるし、実用例と先端の研究者が解離してる典型だわなぁ。
「5%の不良率で100個発注したら当たり前のように105個納品されてくるようなどっかのおおざっぱな国の発想だ」
と、日本の会社だと反発されるやつ。
ナップサックとか問題持ち出して、モノによっては泥臭く計算せなあかんのやと言うのと、
次は百万台でやっても一つのタスクの不可分な時間以下にはならんのだよ、
を説明して説得して導入するようなものだから。

トポロジ解析と図面生成か何かで原始的なそれやった事ある。

0163デフォルトの名無しさん2017/04/29(土) 13:21:11.09 ID:rB0Fvmgg
>>161
多くの深層学習フレームワークはNN構造をPythonなどで記述すると
それをテンソルの計算グラフに変換してGPUで高速計算してくれる。
NN構造や規則格子をさらに簡略に記述したければJuliaがある。
Fomuraの20行のシミュレーション記述も既存の言語でできるはずだ。

つまりシミュレーションをより簡略に作成するために新言語は必要ない。
必要なのは用途毎のフレームワークだ。

0164デフォルトの名無しさん2017/04/29(土) 18:34:55.63 ID:n+S+CElE
発展し続ける言語とゴミ屑同然に忘れ去られる言語、何が違うんだろうなぁ

0165デフォルトの名無しさん2017/04/29(土) 19:09:01.68 ID:0nTkChzC
言語の良さを理解して使い続けられる人と、ゴミ屑同然の脳みそですぐに忘れ去ってしまう人、何が違うんだろうなぁ

0166デフォルトの名無しさん2017/04/30(日) 00:13:09.75 ID:feM/rwNV
>>164
覚えやすさとチューニングのしやすさ。
以上。

0167デフォルトの名無しさん2017/04/30(日) 01:03:20.38 ID:E30HxT2S
>>164
いろんなプログラム言語を開発しておいて、その上で『良いとこ取り』で新言語を開発する。

0168デフォルトの名無しさん2017/04/30(日) 01:49:39.39 ID:9UtCfcRf
>>164 バックでしょ
Goはグーグル発じゃなかったら「今どき継承もない言語作ったのかよ?w」で即死

0169デフォルトの名無しさん2017/04/30(日) 01:50:36.87 ID:2awuHSHC
>>167
なおScala

0170デフォルトの名無しさん2017/04/30(日) 09:42:21.85 ID:QitJ8eBZ
>>168
実際死んでね?言語としては。
言語として死んでるのをGoogle謹製の周辺ツールで無理やりカバーしてゾンビ化してる感じ。
ゾンビなので一周回って死ににくい。

0171デフォルトの名無しさん2017/04/30(日) 10:18:39.25 ID:H2bTIgd1
どんだけバックが大きくてゴリ押ししても
死ぬときは死ぬ
Dartとか

0172デフォルトの名無しさん2017/04/30(日) 12:02:29.80 ID:kLDfBj4F
>>168 >>170
Goは文法が簡単で高性能という特徴がある。
おかげで文法は簡単だが低性能な言語から移行しやすい。
だから難しい言語が選ばれない所で活躍している。

Gopherの道を歩む – Node.jsからGo言語への移行
http://postd.cc/the-way-of-the-gopher/
Go言語の低レイテンシGC実現のための取り組み
http://postd.cc/gos-march-to-low-latency-gc/

0173デフォルトの名無しさん2017/04/30(日) 15:36:43.63 ID:4Q8qZxsi
Goって手続き型だろ?
Mainに集中して必要な機能呼び出すだけでいいんだから設計書なしで良さそう

新着レスの表示
レスを投稿する