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

**デフォルトの名無しさん** · 2017/04/20(木) 04:43:27.12

いざ、語ろうぞ。

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

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

あ · 2017/04/29(土) 12:11:59.50

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

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

**デフォルトの名無しさん** · 2017/04/29(土) 13:21:11.09

>>161
多くの深層学習フレームワークはNN構造をPythonなどで記述すると
それをテンソルの計算グラフに変換してGPUで高速計算してくれる。
NN構造や規則格子をさらに簡略に記述したければJuliaがある。
Fomuraの20行のシミュレーション記述も既存の言語でできるはずだ。

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

**デフォルトの名無しさん** · 2017/04/29(土) 18:34:55.63

発展し続ける言語とゴミ屑同然に忘れ去られる言語、何が違うんだろうなぁ

**デフォルトの名無しさん** · 2017/04/29(土) 19:09:01.68

言語の良さを理解して使い続けられる人と、ゴミ屑同然の脳みそですぐに忘れ去ってしまう人、何が違うんだろうなぁ

**デフォルトの名無しさん** · 2017/04/30(日) 00:13:09.75

>>164
覚えやすさとチューニングのしやすさ。
以上。

**デフォルトの名無しさん** · 2017/04/30(日) 01:03:20.38

>>164
いろんなプログラム言語を開発しておいて、その上で『良いとこ取り』で新言語を開発する。

**デフォルトの名無しさん** · 2017/04/30(日) 01:49:39.39

>>164 バックでしょ
Goはグーグル発じゃなかったら「今どき継承もない言語作ったのかよ？ｗ」で即死

**デフォルトの名無しさん** · 2017/04/30(日) 01:50:36.87

>>167
なおScala

**デフォルトの名無しさん** · 2017/04/30(日) 09:42:21.85

>>168
実際死んでね？言語としては。
言語として死んでるのをGoogle謹製の周辺ツールで無理やりカバーしてゾンビ化してる感じ。
ゾンビなので一周回って死ににくい。

**デフォルトの名無しさん** · 2017/04/30(日) 10:18:39.25

どんだけバックが大きくてゴリ押ししても
死ぬときは死ぬ
Dartとか

**デフォルトの名無しさん** · 2017/04/30(日) 12:02:29.80

>>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/

**デフォルトの名無しさん** · 2017/04/30(日) 15:36:43.63

Goって手続き型だろ？
Mainに集中して必要な機能呼び出すだけでいいんだから設計書なしで良さそう

**デフォルトの名無しさん** · 2017/05/02(火) 06:00:14.79

Mathematica 11.1 | 2017年4月（日本語版）詳細 ≫
バージョン11.1では，機械学習，ニューラルネットワーク，音声処理，ロバストな記述統計等の分野における
MathematicaおよびWolfram言語の最先端機能が拡張されています．
広範な応用分野に加わった，130を超える新関数
ニューラルネットワークの新しい20種類の層の追加，および再帰型ネットワークと可変長シーケンスのシームレスなサポート
NetModelにより，増加し続ける完全なニューラルネットワーク（訓練されたものとされていないものを含む）のリポジトリにアクセス
データ，画像，テキスト等の空間を機械学習ベースで可視化するFeatureSpacePlot
SequencePredict，ActiveClassification，ActivePredictionを含む，新しい機械学習関数
AudioCaptureを使って音声を直接ノートブック内で録音することによって，すぐに処理・解析することが可能に
2Dおよび3D画像に対する，*，-等を使った計算が可能に
計算写真学と計算顕微鏡学に対するサポートの拡張
ImageGraphicsを使って，ビットマップのベクトルグラフィックスによる近似を求める
HilbertCurveやSierpinskiMesh等の空間充填およびフラクタル領域コンストラクタ
WinsorizedMean， SpatialMedianを含む，新しいロバスト統計と空間統計
新しいGeoBubbleChartと，Callout，ScalingFunctions等のサポートの拡張
記号次数を持つ導関数のサポート
解像度が高くなった標高データ
シームレスに統合されたWeb検索，Web画像検索，テキスト翻訳のための外部サービス
セッション間の値をローカル，あるいはクラウド等に保存するための，幅広いPersistentValueシステム
クラウド内で個別に編集できるノートブックをシームレスに配布するためのAutoCopy
ノートブックベースのスクリプトエディタを使ったWolframScriptの.wlsファイルの生成
Wolfram言語スクリプトの自動実行がWindowsでも可能に
ドキュメントセンターおよびオンラインの例題すべてが新しくレスポンシブデザインに
https://www.wolfram.com/mathematica/quick-revision-history.ja.html?footer=lang

**デフォルトの名無しさん** · 2017/05/02(火) 06:54:00.89

回転放物面の方程式と東大の問題
http://mathtrain.jp/kaitenhobutsu

「放物線 y = 3/4 - ｘ^2」
を
「y軸の回りに回転させる」

・・・例えば、こういう操作ができる３次元ＣＡＤって開発されてないんですか？

統計的機械翻訳では自然言語処理は無理という話も聞いているけれど、高校数学でやることは内容が限られており、
一般的な機械翻訳よりは難易度は低いと思われます。

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

3次元CADを名乗っていて回転体を作れないもののほうが珍しいと思うが、
その問題を解けるCADは多くないだろうな。
近似的な数値解が求まることと、解を方程式で表して数式処理できることは全くの別物。

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

>>176
＞その問題を解けるCADは多くないだろうな。

そのための新プログラム言語開発ってことだよな。

あ · 2017/05/02(火) 11:18:08.85

>>175
ごく当たり前の機能として存在する。
面で切り取る事もできる(面に対する押し出しで、相手方を削り取る感じ)
体積も求められるよ。
拘束条件は厳密だし、カーブを式で入れることもできるから。

ただ、それのために1License300万出す？

**デフォルトの名無しさん** · 2017/05/02(火) 14:54:44.43

ああ、高精度な数値解を導出することと、任意の拘束条件から方程式を導出することの区別がつかない人がいるようだ。

**デフォルトの名無しさん** · 2017/05/02(火) 14:57:14.02

解析解が必要な場面なのか？これは

あ · 2017/05/02(火) 17:06:18.52

>>179
うちでつかってるのは数値解じゃなくて方程式まで自由じゃないけど変数の式でも出たはず。あれ内製だったかな。
AutoCADのMASSPROPとかくらいだと、悲しいかな数値解しか出ないけど、カーネルに手を出せる会社ならだいたいその辺持ってると思うよ。

あ · 2017/05/02(火) 17:07:00.26

もし内製だったら、当たり前の機能として、とは言えんな。
それはすまん。

**デフォルトの名無しさん** · 2017/05/02(火) 17:33:48.15

任意の方程式を扱えないと、>>175 の問題は解けないよね？

あ · 2017/05/02(火) 22:27:44.92

>>183
押出する元の図形をプロシージャルではなくて、曲線定義で描く。
曲線への拘束条件で何を取るか次第だけど、問題文通り入れればそれで良いと思うよ。
ゴールデンウイークは試せないのがもどかしいな。

**デフォルトの名無しさん** · 2017/05/03(水) 16:11:10.64

Smalltalkって名前だけ変えて次世代言語って紹介されたら
殆どの人は信じてしまうくらい先進的だよね
進歩しすぎてて理解されない不幸な言語

**デフォルトの名無しさん** · 2017/05/03(水) 16:33:31.70

比較的新しい言語ってvar t : Type形式が多い気がするけどType t形式を利用しなくなった理由ってあるのかね

**デフォルトの名無しさん** · 2017/05/03(水) 16:46:20.28

>>186
型推論の問題じゃない？多分

**デフォルトの名無しさん** · 2017/05/03(水) 16:53:47.90

型を書いたり書かなかったりする場合に記述を大きく変える必要がなくて都合がいいんだろう。
型推論を使う言語とか、動的型言語に型ヒントを追加する場合とか。

**デフォルトの名無しさん** · 2017/05/03(水) 17:10:47.34

たとえばC#だと基本はType tで後から型推論var t(: typeはない)を追加した
だったら最初から統一的な記法で良くね？ってなる

**デフォルトの名無しさん** · 2017/05/03(水) 19:11:09.93

なるほど
型推論が流行ってる(のかはわからないが)から型推論の書き方+αで書けるようにしたってことか

**デフォルトの名無しさん** · 2017/05/03(水) 20:37:23.26

デニス・リッチーも型前置にしたことを後悔していたんじゃなかったっけ？
たぶん型後置の方が合理的という点には大方の一致があって、あとは合理性を取るか、Cの語順に近づけることを取るかっていう感じなんじゃないかな？

**デフォルトの名無しさん** · 2017/05/03(水) 22:01:20.86

>>186
pascalがそういう記法だけど、コンパイル速いのはpascalがコンパイラの都合に合わせた文法だからって読んだことある。
何かしらコンパイラが解釈し易い記法なんじゃね？

**デフォルトの名無しさん** · 2017/05/03(水) 23:27:43.76

>>192
Pascalの構文は再帰的パーサを簡単に書けるLL(1)文法なんじゃなかったかな
LL(1)ならトップダウンで構文解析できるからパーサは書きやすいしパーサの効率も多分だけど高い

Cの場合は、例えば

　　atype;

という宣言があった場合、"atype"という識別子が

１．typedefで型の名前として既に定義済であれば「変数が指定されてない構文エラー」となるし

２．そうでない場合、"atype"という名前のint型の変数の宣言として扱われ
　　２―１．"atype"という変数が既に宣言済であれば２重宣言のエラー、
　　２―２．そうでなければ正しい変数宣言

となるので、構文解析の際にsymbol tableを参照する必要がある（つまり本質的なレベルで文脈依存文法）ケースが存在するので
当然ながらコンパイラの効率が下がるだろうね

**デフォルトの名無しさん** · 2017/05/04(木) 00:37:37.35

昔のpascalは1パスコンパイラだった。コンパイルの速さはそれもあったかもね。
今のobject pascalはジェネリクスもあるしどうだろう？

**デフォルトの名無しさん** · 2017/05/04(木) 05:29:59.66

>>186
v: Type形式なら変数の型だけでなく、式に型をつける構文としてもそのまま使えるから。

**デフォルトの名無しさん** · 2017/05/04(木) 09:04:54.52

値の演算だけでなく型の演算として同じ記号を使うのがCのポインタや配列
これは評判が悪かった
悪いのはポインタだけだというのがJava
全部悪いから全部変えるのが次世代

**デフォルトの名無しさん** · 2017/05/04(木) 09:34:14.90

まあポインタの宣言と参照のための記号に同じ * 使ってんのは今でもなんでなんとは思う。

**デフォルトの名無しさん** · 2017/05/04(木) 09:51:37.05

関数の戻り値型の指定はPython,TypeScriptが=>、Swiftだと->が混ざって
いまいち統一感がないんだよな。:のままだと構文的にうまくない部分があるんだろうか。

**デフォルトの名無しさん** · 2017/05/04(木) 10:09:01.14

>>186
C方式に慣らされてるからそう感じるだけであって
あれはパースしづらいクソ構文だよ

struct S s;
を捨てたのは何でだろうと問うべきだよ

**デフォルトの名無しさん** · 2017/05/04(木) 10:44:22.27

そもそも静的型が悪いと思えば単純明快だな

静的型は悪くない、だがジェネリクスは不要、ただし Array<T> 等はこっそり入れておく
こんな状態で統一感（笑）を期待する方がおかしい

あ · 2017/05/04(木) 11:53:43.54

>>200
思いっきりGoだな。
まぁ、Goに統一感なんか無いし、期待してはいかんw
あれは誰でもかける便利な言語だよ。

一切の原理原則以外を排除する崇高な思想で作られた芸術品ではなくて、
「その辺にある便利そうなものを誤謬矛盾なく突っ込めるようにそれなりにルール作りました。
　とりあえずこのルール破ると突っ込めなくなるからやめてね。コンパイルさせないよ。」
という、実用のためのルールが細かいのがGoだよ。
電動ドリルのチャックとビットの規格みたいなもん。

「対称性がなくなるからこのメソッドを実装する」という発想ではない。

**デフォルトの名無しさん** · 2017/05/04(木) 12:29:38.64

原理原則というのは崇高な思想じゃなくて無駄な仕様変更の防止という実用の技術だ

**デフォルトの名無しさん** · 2017/05/04(木) 12:53:07.54

なんだ PHP だったのか

あ · 2017/05/04(木) 13:45:55.83

>>202
口実やね。
専用品と汎用品なら、圧倒的に前者の方か仕様変更の回数は少ない。
無理に延命したり使いましたりしたいからこそ、よくわからん仕様変更するハメになる。
無駄な仕様変更なら、最初からしなけりゃいいんだよ。
無駄なんでしょ。
使い捨てを使い捨てと認識する事こそがスタート地点。
歯が折れたら取り替えたいし、違う歯を使いたいからチャックがあるんだから。
歯の代わりにバフ付けることも出来るけど、それに対して仕様変更なんか要らないでしょ。バフを新規に作るだけじゃん。
置換原則出してきて証明する必要も無い。

>>203
そうだ、と言う認識だなぁ、俺は。
PHPも同じ理由で、いろんな意味でとても潔い言語だと思うよ。

**デフォルトの名無しさん** · 2017/05/04(木) 15:09:17.79

言語設計とドリルチャックを一緒くたとか…完全に呆れた

あ · 2017/05/04(木) 17:00:05.42

呆れるなら簡単だからな。
どう違うかをきっちり教えて欲しいわ。
本当に勉強になったら素直に勉強になったと言うことにしてるし、実際何度もそうレスしてるよ。

言語なんて外から見たときに一意に呼び出し規約や入出力が決まってりゃそれでいいんだよ。
これでも素晴らしい言語とやらを5個10個と多数見てから言ってるんだけどな。

それ以上の、実用性以上の思想の旗を振りたいなら、何故その思想が必要か語ってほしい。

あ · 2017/05/04(木) 17:07:42.27

しかし、式に型をつける構文が後置だから出来るのは本当なのかな。
キャストの前置や後置と何か違うのかなぁ。

って考えたら「宣言文名前型」の方が遥かに簡単にパースできるなって思わんのかな。
式に型をつけるってのも、コンパイラに教える意味での型か、キャストの型か2つの意味あるけど、どっちの事かな。
疑問。

**デフォルトの名無しさん** · 2017/05/04(木) 21:21:01.22

>>204
多分それは使い捨てではなく交換
これを捨てる代わりにあれが欲しい
見返りがあれば捨てるが無条件に捨てられそうになったら使い捨てに反対するだろう

**デフォルトの名無しさん** · 2017/05/04(木) 22:18:26.60

むしろ変な原理原則に縛られてる方が糞仕様の増加を招くのだが。
haskell みたいにな。

**デフォルトの名無しさん** · 2017/05/04(木) 22:34:29.63

確かに、関数型とかいう変な原理でHaskellを理解しようとしてるならやめた方がいい
静的型の原理だけで理解できるから

あ · 2017/05/04(木) 22:35:23.26

>>208
「交換できる、交換出来ない」と「使い捨てである、改良を加えて連用する」は同時にどの組み合わせも成り立つのでは？
これを捨てる代わりに、これと同じ機能プラスαの新ライブラリを作る、みたいな話で、
完全に前方後方互換の代替品であるかもしれないし、そうではないものかもしれない。

そういう意味では、無条件に捨てる事ができるってのは立派な見返りだよ。

**デフォルトの名無しさん** · 2017/05/04(木) 22:36:44.00

良いんだよ。
Haskellは美しさが売りなんだから。
むしろ美しさを保ったまま、どこまで実用的なの作れるかが楽しいんだよ。

そう言う意味じゃsmalltalkと同じ、純粋xx言語でxxの真髄理解するなら～って言語であって、次世代言語じゃあない。

あ · 2017/05/04(木) 22:36:44.02

>>210
ならPrologの方が賢いし、Scalaの方がまともだし、Lispの方が最低限の原理から出来てるから、Haskellは要らない子だな。

あ · 2017/05/04(木) 22:39:24.44

>>212
それそれ。エスペラント語とかロジバンみたいなもん。
実用的ではないけど面白いのは認める。

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

Haskellは代数的データ型が便利
何気にあのレベルに便利な型システム他に見ない

あ · 2017/05/05(金) 03:41:35.36

>>215
OCamlの方がシンプルかな。
Haxeの方が記法はきれい。
Kotlinはいささか冗長で使い物になるのかな？みたいな羊感出てるけど、when使うときに逆に便利になる。

**デフォルトの名無しさん** · 2017/05/05(金) 05:49:16.66

SmalltalkとHaskellは使ってみるとゴミと分かる二大巨頭
信者が煩いとこもソックリ

**デフォルトの名無しさん** · 2017/05/05(金) 07:09:34.37

>>217
アンチがウザいのもそっくりだよね

**デフォルトの名無しさん** · 2017/05/05(金) 07:18:58.13

>>218
どっちの信者？

**デフォルトの名無しさん** · 2017/05/05(金) 07:39:38.28

>>217
アンチが無知なのもそっくりだよね

**デフォルトの名無しさん** · 2017/05/05(金) 08:48:03.35

IntelliJとかのマトモなIDEを使った後に
Smalltalkの時代遅れのIDEモドキ？を使ってみると、
終わった言語の進化に取り残されてる感がよく分かるし
こんな出来損ないを使うの強制されるSmalltalkerって哀れだなーって優しい気持ちになれるよ

**デフォルトの名無しさん** · 2017/05/05(金) 09:20:19.67

>>221
言語としてはどこらへんがゴミなの？

**デフォルトの名無しさん** · 2017/05/05(金) 09:39:59.96

>>222
動的型言語の中ではぶっちぎりで冗長なコードになるところ

**デフォルトの名無しさん** · 2017/05/05(金) 09:54:56.24

文字列クラスを改変したら元に戻せないという話はSmalltalkにも当てはまるのかな
文字列クラスクラスがあれば壊れたクラスを使い捨てて新品のクラスに交換できるのに

**デフォルトの名無しさん** · 2017/05/05(金) 10:13:52.40

>>224
クラスが壊れるという事自体が糞めんどくさい

**デフォルトの名無しさん** · 2017/05/05(金) 13:00:01.57

Smalltalkっていうか遅延結合の徹底ってスタイルは人類には早すぎたんだな

**デフォルトの名無しさん** · 2017/05/05(金) 16:27:38.21

RESTful API等でサービス間を遅延結合するのは流行ってるしメリットがあるけど
ひとつのプロセス内で遅延結合しても意味が無い

アホは適切な抽象化レベルってものが分からないから
やりすぎてナンセンスになっちゃうんだよね
Smalltalkはアホがナンセンスなデザインした結果死ぬべくして死んだ言語

**デフォルトの名無しさん** · 2017/05/05(金) 17:23:18.30

Haskellは遅延評価が本当に苦痛すぎる
あの辛さはやってみるまで想像もつかなかった

**デフォルトの名無しさん** · 2017/05/05(金) 17:51:23.35

Smalltalkにおいて「遅延結合の徹底」に期待されるのは通常の言語で想定されるそれとは違って
システム構築中に得られた新たな知見を、既に構築済みだったり運用中の部分へ適用できたり
オブジェクトとそのストアを長期にわたって運用し続けるために細胞の新陳代謝を模した試みだから
http://metatoys.org/oxymoron/oxymoron.html
'70年代からほんの数回の再起動で動き続けている同システムは狙いとしては成功しているんだよね

**デフォルトの名無しさん** · 2017/05/05(金) 17:51:28.56

無限リスト扱えるし便利でもあり、バグ取りで厄介でもあるね。
RWHにその辺の解決策載ってるから手元に置いとくと良い。

**デフォルトの名無しさん** · 2017/05/05(金) 17:51:33.32

馬鹿は抽象化することがなんでもえらいと思ってるからね。。

あ · 2017/05/05(金) 19:50:22.56

>>227
意味無いとは言わんがなぁ。
プロセス内でもプロトコル決めてやっとくと、あとでスケールするとか、
固まりへのインアウトが自ずと決まるから可換だと言いやすいとは思う。
やりすぎると自分の重さで死ぬだけで。

**デフォルトの名無しさん** · 2017/05/05(金) 20:29:10.87

FacebookでHaskell採用されたね。

**デフォルトの名無しさん** · 2017/05/05(金) 20:49:47.45

>>216
Haskellと比べてOCamlがシンプルって
SMLと勘違いしてない？

あ · 2017/05/05(金) 20:51:14.85

>>234
してないよw
シンプルってのは字数が少ないって意味じゃないぞ。

**デフォルトの名無しさん** · 2017/05/05(金) 21:21:35.63

>>235
そんなら勘違いしてるね

**デフォルトの名無しさん** · 2017/05/05(金) 21:31:07.05

全然関係ないけど、字数が少ないコードって一目で取れる情報が多くて読みやすくて好きだわ

**デフォルトの名無しさん** · 2017/05/05(金) 21:42:23.21

>>231
時代によって変わる程度問題だけどね。
C++だって、昔はクラスってなんだよ。Cより遅くなるじゃねーかって言われてたらしい。
昔よりも抽象度の高さが問題になる場面は少ない。

**デフォルトの名無しさん** · 2017/05/05(金) 22:47:31.33

いつの間にかHaskellがスレタイから抜けててワロた。

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

取り敢えず拡張性比べるんならプログラム組むべ。
まずはファイル名とキーワードを受け取って、ファイルの中にキーワードがあったらTrue。無かったらFalseと表示するコマンド。

プログラミング自体から離れてだいぶ経ったので、錆びた頭だったがHaskellでどうにか書いてみた。

search部分を拡張してくから、各自searchは自前で書いてくれ。

import System.Environment

search _ [] = False
search s ns | take (length s) ns == s = True
search s (_:ns) = search s ns

main = do
arga <- getArgs
content <- readFile $ args!!0
print $ search (args!!1) content

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

前スレのドアのお題をPharo Smalltalkでも書いてみた
http://ws.stfx.eu/JD8JH4XF3I3U

Go版ももう少しマシな感じにしてみた
http://ideone.com/aFqKsd

**デフォルトの名無しさん** · 2017/05/05(金) 23:36:43.64

だから、使い所不明なクラス書いてどうしろと。
プログラム組みたいのであってクラス作りたいんじゃ無いんだぞ？

**デフォルトの名無しさん** · 2017/05/05(金) 23:59:41.96

>>242
いや別に>>240へのレスというわけではないのだが…

これでいいか？（Squeak Smalltalk、もしくはPharo）

| search |
search := [:fname :keywd |
　FileStream oldFileNamed: fname do: [:file |
　　(file findString: keywd) > 0
　]
].
search value: 'test.txt' value: 'something' "=> true "

http://ws.stfx.eu/1UQT4K8GSVHU

**デフォルトの名無しさん** · 2017/05/06(土) 00:04:14.20

>>240
それだとコンパイル通らないよ

import System.Environment (getArgs)
import System.IO (readFile)
import Data.List (isInfixOf)

search :: String -> String -> Bool
search = isInfixOf

main :: IO ()
main = do
　(word:file:_) <- getArgs
　putStrLn . show =<< search word <$> readFile file

**デフォルトの名無しさん** · 2017/05/06(土) 00:23:53.40

え。。。
通ったけど。。。

**デフォルトの名無しさん** · 2017/05/06(土) 00:29:01.13

うん、普通のデータ処理の比較は面白そうだ。

**デフォルトの名無しさん** · 2017/05/06(土) 00:29:23.53

>>243
おk。
強いて言えば、この後拡張する時、どこまで今のコードから書き換えないで済ませられるかが仕様変更に強い基準になると思う。

**デフォルトの名無しさん** · 2017/05/06(土) 00:33:03.34

>>245
そのままじゃ通らなかった
けどごめんね、詳しく見てなかったけど駄目だったのはタイポだけだったみたいだね

**デフォルトの名無しさん** · 2017/05/06(土) 00:35:03.84

あ、argsをargaってタイポしてた。。。
LinuxにHaskell入れたばかりなのでPCで実行確認してiPhoneで書き込んでるんで、コピペでコンパイル出来ない時はどこかタイポあると思う。

**デフォルトの名無しさん** · 2017/05/06(土) 00:50:29.93

次世代言語勢に参戦して貰わんとだから、第二形態は明日の夜発表って感じで良いかな。
一応、第三形態までの予定。
明後日から夜勤なんで、第三形態どうすっかな。

あ · 2017/05/06(土) 02:06:36.33

>>236
そうなのかなぁ。
例えばそれぞれのどんな例からシンプルさがわかる？
後学のため教えて欲しい

あ · 2017/05/06(土) 02:11:17.59

>>241
Go版、マシどころか疎にしておいたところ密にされてしまったな。
ノブのないドア、ノブはあるけどラッチのないドア
実現する術がなくなったね。

With Withなんて気色悪い無理に継承関係を作ったような型作るくらいならもう継承とか全部捨てたほうがマシ。
もうちょっと真面目にやって。

**デフォルトの名無しさん** · 2017/05/06(土) 03:50:07.06

Kotlinになれるためにアプリを作ってるんだけど、久しぶりにc++触るとセミコロンがうっとおしくなるね
参照、ポインタ、値を自由に扱えてかつ新しい言語の特徴を捉えてるような言語が出てほしい

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

勝手にHaskellをスレタイから省くな。

**デフォルトの名無しさん** · 2017/05/06(土) 07:19:08.10

>>252
前スレの埋め込みを使った再帰型の試みとして、主要なメソッドを再定義しなければならない版より「マシ」と言ったまでで
君のチャンネル版よりマシという意味ではない

それは他言語版と同じ設計で比較しやすくしたって程度だから気にしないで

**デフォルトの名無しさん** · 2017/05/06(土) 07:23:37.59

各自、次世代言語に求めるものが違うのだろうけど、
気を悪くしないで欲しいがHaskell外してKotlinは個人的にはないかな。
敢えて外すなら次世代感満載のAgdaを入れて欲しい。
が、呼び水としての趣旨からしたらHaskellを敢えて外す理由が分からない、個人的な怨嗟？

**デフォルトの名無しさん** · 2017/05/06(土) 08:00:28.21

実用性が乏しすぎるので次世代にふさわしくないとの事
あと前スレでまともなコードを掲示しなかったので、そもそもHaskellerが居ない事が分かった

**デフォルトの名無しさん** · 2017/05/06(土) 08:15:37.40

>>256
Javaより古いHaskellを次世代言語に混ぜた初代スレの>>1がどうかしている。
初代スレはHaskellの美しさを語るエアプログラマーが多かったが
次世代言語の実用性を語るスレに変わってよかったと思うよ。

**デフォルトの名無しさん** · 2017/05/06(土) 08:35:08.14

Haskell推しだが、次世代取れるほどライブラリ充実してないし、速くもないからsmalltalk的な立ち位置だと思ってる。
次世代じゃ無いけど、学ぶべき価値ある言語。

**デフォルトの名無しさん** · 2017/05/06(土) 08:41:48.81

>>255
参考まで、ほぼ同じ設計にした場合の
Ruby版 http://ideone.com/7VnOfe
Python版 http://ideone.com/UngSO8
Scala版 http://scastie.org/30851
Swift版 http://swift.sandbox.bluemix.net/#/repl/59032b64ebfba02b8d274320

**デフォルトの名無しさん** · 2017/05/06(土) 08:43:22.81

>>257
Mix-inとか言われては書けなかったね。
普通のクラス代りなら何とかなったが。
そもそも目的のプログラム作るアプローチとして関数かクラスかなのに、クラス作れは問題としてオブジェクト指向に有利過ぎ。
実際に動くプログラムで拡張勝負のが公平っしょ。
だから>>240提案した。