[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 03/18 02:28 / Filesize : 256 KB / Number-of Response : 1028
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

次世代言語議論スレ【Go Rust Haskell Scala Erlang Elixir】



1 名前:デフォルトの名無しさん [2016/11/18(金) 10:59:09.20 ID:SgtZza8z.net]
いざ、語ろうぞ。

910 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 18:47:41.82 ID:686NvPbu.net]
むしろこうやって2者を区別できてないと決めてかかって、仮想敵を叩き始める人間を量産したのが、Smalltalkの悪いところ
Smalltalk自体が害悪と言っていいかもな

911 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 19:32:02.73 ID:QwZMX6+7.net]
で、OOが2種類ある原因はなんなのか?
静的型と動的型のせいでしょ
直交性なんてないよね

912 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 20:43:29.26 ID:87WOJqFm.net]
>>890
アラン・ケイは別に静的型には反対していないよ
彼の望む遅延結合性の邪魔をしない静的型なら歓迎するはず
d.hatena.ne.jp/katzchang/touch/20080807/p2

913 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 20:55:14.84 ID:87WOJqFm.net]
>>888
いや、だからその「オブジェクト中心」とかいうのをOOPとするのが間違っているんだってわかんないかな
アイデアが提出されたのの早い遅いではなくて、抽象データ型のOOPとメッセージングのOOPはそもそも考え方が異なる
早い遅いで言ったら、抽象データ型のOOPの方がダールやリスコフが早く気づいた分、メッセージングのOOPよりも早い

>>889
でも実際に区別できていないわけだし…

914 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 21:42:59.21 ID:rXluJnty.net]
smalltalkとか懐かしいな。。。
Boolもオブジェクトだったっけ。

(1>3) then: [Workspace display: 'No! 3 is Big!!'] else: [Workspace display: 'Yes. 1 is Small.']

もう十年以上前に触ったきりだからうろ覚えだけど、こんな感じだっけ。
メソッドチェーンが文章的になるの嫌いじゃなかった。

Squeakとかだとコード上のオブジェクトだけでなく、動いてるアプリにもどんなクラスやメソッド持ってるか聞けたり、コード見たり、弄って変更したり出来てたね。
リアルタイムのOS育てゲーム。

上で騒いでるのは静的型言語でも動作中のアプリにクラスやメソッドを聞けて、コード変更と、更新したらすぐに動作に反映出来れば良いって事かな?

アサートとかでメタプログラミングも出来るようになってきたし、コンパイル速度もDelphiみたいに速いのもあるし、コンパイラ内蔵実行ファイルとかでサポート出来なくはなさそうだけど、出来ない方がコード資産守れるから会社じゃ採用されなさそう。

915 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 21:48:40.84 ID:1t5JET4K.net]
関数型は確かにコードが短くなるがわかりやすくはならないだろう
短いということは、それだけ文法に暗黙の了解が多いということだ
このような代物は背後にある考え方とそれによるメリットだけ頂いて、残りは捨てるのが正解
つまりJava8が正しい

916 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 21:53:27.37 ID:rXluJnty.net]
それは関数型、手続き型じゃなくて、クラスやメソッドの命名規則の問題。

917 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 21:59:35.05 ID:87WOJqFm.net]
>>893
プロトタイピングでは威力を発揮するので、動作を検証できたら即座に実戦に投入できるという点に惚れ込んで
ALLSTOCKERを作っているスタートアップの人たちはSmalltalkを採用しているね
https://medium.com/@newapplesho/%E3%81%AA%E3%81%9C%E6%88%91%E3%80%85%E3%81%AFsmalltalk%E3%82%92%E4%BD%BF%E3%81%86%E3%81%AE%E3%81%8B-%E3%81%9D%E3%81%AE2-smalltalk%E3%81%AE%E8%89%AF%E3%81%95-7a3af3cc5823#.8tm02xv3o

918 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 22:00:19.12 ID:1t5JET4K.net]
>>895
関数型の利点は短く書けることだと街宣している人間がたくさんいるじゃないか
彼らは命名規則の話なんて一切していないぞ



919 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 22:13:12 ]
[ここ壊れてます]

920 名前:.95 ID:sIFP3alf.net mailto: >>894
短く済むってことは、良く抽象化されてるって事
つまりそれだけ生産性も高い

文法的に短い事が悪だとかいう考えは改めた方がいいんじゃないか?
ただのコードゴルフとは言ってる意味が全く違うからね
[]
[ここ壊れてます]

921 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 22:15:03.55 ID:rXluJnty.net]
>>896
海外じゃ実戦投入してる会社があるのは当時も聞いてた。
でも多数派では無い。
それぞれ会社の価値観に違いはあっても良いが、それが多数派になるかは別問題。

922 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 22:18:07.57 ID:5MVdS2z+.net]
>>876
オワコンだよ
TSでES201Xと同等の文法+αが使えるのに、
わざわざゴミ屑みたいな新しい文法覚える必要ない

923 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 22:19:27.86 ID:sIFP3alf.net]
まさかコードの抽象化そのものを否定するプログラマがいるとは思わなかったな
Javaも資産使ったコードは短くなるだろ
それと一緒だよ

924 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 22:19:31.11 ID:5MVdS2z+.net]
>>894
わかりやすいと思うけど
filterとかreduceとかmapとか、自前でforやif組んで書きたいか?

925 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 22:30:41.26 ID:87WOJqFm.net]
>>899
おっしゃるとおり
もっとも、多数派が正義かっていうとそれも別問題だけどね

926 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 22:39:50.78 ID:sZ6PQDwZ.net]
map, fold, filterなどは確かにわかりやすいけど、
再帰的定義は小一時間考えてやっと分かるときがある。
慣れなのかな。

927 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 22:48:55.57 ID:1t5JET4K.net]
>>898
抽象化はやればやるほど良いってものでもない
関数型言語は総じてやりすぎでわかりづらい

>>902
そういうわかりやすいものは奪っておいて有用に使うのが良い

928 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 22:53:56.20 ID:5MVdS2z+.net]
>>905
奪うってなんや
おまんは盗人か?



929 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 23:02:03.46 ID:rXluJnty.net]
>>897
例えばsum関数ってあるじゃ無い?
これって手続き型ならLLでも静的型言語でも基本変わらんよね?
(最近はメソッドに関数渡せるようになってる言語増えたから特に)
んで、関数型言語だと単純なところだとループを再帰で書くから、計算中の値を蓄える変数が一個減る。
ループ命令書くのも減る。
sum [] = 0
sum (x:xs) = x + sum xs
(昔はスタック消費してたが、近年こういう単純な再帰なら、裏で末尾再帰に変形してループに変換してくれる)
次に、じゃあsumの掛け算バージョンが欲しいとする。
Haskellだとproductって関数だけど、言語によって違うのに注意。
product [] = 1
product (x:xs) = x * product xs
はい完成。なんだけど、別にこれで関数型が短いって言うわけじゃない。
sumとproductは構造が似てる。
そこで構造を関数に括り出す。
foldr f n [] = n
foldr f n (x:xs) = f x (foldr f n xs) -- 演算子は特殊な関数で、(+)みたいに書くと2引数の関数になる。
んで、この関数化した構造を再利用する。

sum xs = foldr (+) 0 xs --普通は末尾再帰の構造を関数化したfoldlを使う。
product xs = foldr (*) 1 xs

最後はsumの最後の引数と、foldrの最後の引数が同じだからカリー化で見た目の引数を省略できる。

sum = foldr (+) 0
product = foldr (*) 1

まあ、カリー化が確かに意図を読み取りにくくするかもだが、そもそもLLっぽく対話環境使って単体テストする時に型を調べれば一発で引数何個で、どんな型を求めてるのか分かるし、不満ならトップ関数の型だけ明記しても良い。
カリー化禁止にしたって良い。
ループ構造も関数化して再利用出来るのが大事。

930 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 23:13:38.42 ID:T/QWskV3.net]
なるほど
さっぱりわからん

931 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 23:15:34.04 ID:5MVdS2z+.net]
わからンゴ

932 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 23:16:19.38 ID:1t5JET4K.net]
>>907
正直読む気も起きない

933 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 23:26:19.31 ID:Ks8UPeAC.net]
この程度が分からないとか抽象化を云々する以前だろう…

934 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 23:31:17.10 ID:rXluJnty.net]
悪かった。
んじゃかい摘んで。

ループとかの構造を関数化して再利用できる。
他にも色々あるけど、分かりやすいのがこれ。

LLにも似たことが言えて、こっちはジェネリクスっぽい事が、元々型がないからダックタイピングで同じ事が簡単に出来る。
(代わりに型安全性が失われてる)

935 名前:デフォルトの名無しさん [2017/02/10(金) 23:34:06.32 ID:Nrgs4Acd.net]
>>904
>再帰的定義は小一時間考えてやっと分かるときがある。

いや、再帰的定義は手続き型と関数型のどちらでも難しい

ただし関数型言語や関数型の影響を受けた言語だと、
配列/リスト/辞書/集合といったコレクションの操作は
map/filter/fold といった標準ライブラリ関数が提供されている
だからコレクション(という抽象データ型)を扱う多くの局面では、
(いちいち再帰的定義をするわけでなく、
 もちろん>>834のようにループでゴリゴリ書くわけでもなく、)
豊富なライブラリ関数を活用して簡潔なコードを表現できる

936 名前:デフォルトの名無しさん [2017/02/10(金) 23:46:05.61 ID:Nrgs4Acd.net]
>>905
>抽象化はやればやるほど良いってものでもない
>関数型言語は総じてやりすぎでわかりづらい

世の中で普及しているのは大半が手続き型言語だから、
日常的に手続き型言語で思考している人にはわかりづらいかもね
発想を手続き型脳から関数型脳へ転換するという大きな壁が立ちはだかる

例えば某純粋手続き型スクリプト言語の例:
 LLにおける関数型プログラミング
 echo.2ch.net/test/read.cgi/tech/1345123070/70-71

937 名前:デフォルトの名無しさん [2017/02/10(金) 23:52:38.73 ID:xAAuNbhK.net]
>>910
馬鹿かよこいつやべえな

938 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 23:59:05.09 ID:1t5JET4K.net]
>>912
作る分にはなかなか良さそうだが、そのコードを半年後に見ても理解する自信はない
こんなにまで抽象度を上げなくても、少し妥協して具体的に書いておけば後で助かる
ID:rXluJntyが後者より前者のコードの方を早く理解できるのなら何も言えない

>>914
別に超える必要もない
良い所だけ取って残りを捨てるだけで済む
そのスレで言えば>>79と同意見だな



939 名前:デフォルトの名無しさん mailto:sage [2017/02/10(金) 23:59:56.21 ID:rXluJnty.net]
一応言っておくけど最近の手続き型でもFunc型の導入でループ構造の関数化と再利用は出来るんだよ?
ただ、演算子は関数として扱われないのでラムダ式必須だったりするだけで。

んで、関数型言語はまだまだ抽象化の機能がある。
それらがどんな形で入るのか待ちながら先取りして勉強しておくと将来有利になるし、今も関数型言語だと裏で勝手にやってる事を自分が気をつける事で実践出来るものもある。

940 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 00:09:19.50 ID:uRBrgRbG.net]
>>916
えとね。
構造を関数化してるから、関数名から構造が読み解けるのよ。
耳慣れない関数名だから慣れてないだけで、慣れればむしろ読み易い。
ぶっちゃけ関数合成とか$でカッコを省略とかはメソッドチェーンと思って良い。

と言うか、忘れても他人でも理解する為のドキュメントだろ。
書かない時点でブラックかグループ開発してない。

いくら仕様をそのまま書き下せるって謳い文句の関数型や論理型でも、規模がでかくなりゃドキュメントくらい書くだろ。

941 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 00:20:17.16 ID:PF8ePb43.net]
慣れれば読みやすいとかドキュメントがあれば誰でも理解できるとか言い出す人と、
YESハイブリッドNO関数な俺は永遠に平行線なのでもうやめよう
おそらく分かり合ってしまうと天変地異が起こる

942 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 00:22:14.72 ID:ria0yk5C.net]
>sum [] = 0
>sum (x:xs) = x + sum xs

この手の言語見たこと無かったらこれが関数定義してるってこと自体がわからんのよ
(x:xs)でパターンマッチしてhead|tailに分割してることもわからない
そういう状態だとさっぱりわからないほうが普通だろ

まそういう人こそ関数型を学んだほうがいいと思うけど
それも扱ってるドメイン次第じゃないの

943 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 00:26:19.59 ID:0GjTSBdX.net]
filter処理を
filterと書くか、tempListとforとifを書くか

map処理を
mapと書くか、tempListとforとifを書くか

半年後見て、どっちがわかりやすいかなんて
ひとめりょうねんやろ

944 名前:デフォルトの名無しさん [2017/02/11(土) 00:32:28.22 ID:bFcm8Xsz.net]
>>912
>LLにも似たことが言えて、こっちはジェネリクスっぽい事が、
>元々型がないからダックタイピングで同じ事が簡単に出来る。

LL という言葉が Python/JavaScript/Ruby といったスクリプト言語を
指しているのなら、その認識は誤っている
これらLLはどれも関数型言語の影響を受けて
(>>913でいう) map/filter/fold に相当するライブラリ関数を標準提供している
だから(その適性度に差異はあるとしても)関数型プログラミングを実践できる

またダックタイピングに関しては、LLコミュニティ全体で邪道と共通認識されている
(現在の)LLの特徴の一つは動的型付けであるけれど、データ型を無視する
ダックタイピングは嫌われている(その場限りの使い捨てプログラミングであれば許容されるが,,,)
ジェネリクスやダックタイピングといったデータ型(or 型システム)に関する概念と
手続き型/関数型という計算モデルに関する概念は直交するものであり、ごっちゃにすべきではない

945 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 00:33:39.15 ID:ria0yk5C.net]
個人的に関数型の良さは
小さな関数を合成してパイプラインを作れるところだと思ってる

946 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 00:45:25.28 ID:z0i3VjKa.net]
>>894
本来プログラムは短くかけるもんなんだよ

コードが長くなる理由の大半は

型推論のない静的型宣言
融通の聞かないジェネリクス
ローカル変数の定義、束縛
関数名が長い
引数が長い
ライブラリ使用時の作法、データ制約にたいする適合
ラッパークラス
汎関数使用に制約がかかっている
マクロの使用に制約がかかっている

データ型を宣言するたびに自分で使わない関数をインプルメントするということがビジネスを度外視したドカタ行為であると理解してからOOPを使おうね

次コードが遅くなる原因

947 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 01:02:29.08 ID:ria0yk5C.net]
>>924
>データ型を宣言するたびに自分で使わない関数をインプルメントするということ
ん?意味が分からん

948 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 01:15:27.54 ID:z0i3VjKa.net]
コードが遅くなる原因

アルゴリズムが悪い
アルゴリズムが悪いと思っているが高度なアルゴリズムを設計実装できない
ディープコピー
安全性(バウンダリー、オーバーフロー)
ガベージコレクション
メモリアロケーション
配列を使わない
(ポインタを集約しない)
二分平衡木など木構造を使いこなせない
マルチコアを活用しない
非同期処理を活用しない
IO待ちネットワーク待ち

関数型というのはコンピュータアーキテクチャを知らなくてもかけるようになっているが、何がドメインにおけるbyrefつまり変更しうる点なのか、何がbyvalつまり本質的に不変な値であるかを考えずに書くということはない
何が並行的に処理できて、何が並行処理できないかも概ね予想がつくようになっている


大量のrefオブジェクトが、相互に結び付き合って動的に変化していくようなプログラムはcでかくほうがいい

それは明らかに並行処理不可能で、ポインタによる大量のref宣言がないとガベジコレクトあるいはrefにたいする参照コストが高くつくからだ

一方でそれ以外の分野、たとえば給与計算システムを書くにあたって命令的プログラミングは保守の足かせにしかならない
なぜならば命令型になじめば、必要以上にrefオブジェクトを定義するからだ
関数適用による遅延評価よりも、ポインタ変数の書き換えのほうが、常に高速であるというのだから、仕方のないことだ



949 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 02:21:40.45 ID:Xp+0sQ+z.net]
>>905
なんか駄目プログラマっぽいな
抽象化は手続き型でコードをライブラリにして使用する、というだけでも起ってる事だよ
それとも、使い方を知らないから不要とでも言うのか?

950 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 02:26:38.98 ID:PF8ePb43.net]
>>927
やりすぎが良くないというだけで別に抽象化を否定していない
可読性を損なうほどの抽象化なんてドブに捨てたほうがよい

951 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 02:34:57.87 ID:PF8ePb43.net]
誰もが知っているDRY原則でさえ、時としては不正解になりえる
俺と同じ意見を拾ってきた

postd.cc/on-dry-and-the-cost-of-wrongful-abstractions/
http://プログラマが知るべき97のこと.com/エッセイ/共有は慎重に

952 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 02:57:37.46 ID:Xp+0sQ+z.net]
>>928
手続き型は冗長すぎて可読性を損なうからダメだ、と言うのと同レベル
そちらの言う関数型云々という主張はそれ以前の話だと思うが

そしてDRY原則が抽象化であるというのが解釈間違えてるよ
抽象化という作業には適切な取捨選択という意味もあるから

953 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 03:06:25.79 ID:Xp+0sQ+z.net]
というかDRY原則とか久々に聞いたな
少し和んだ

954 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 03:17:56.37 ID:Xp+0sQ+z.net]
>>925
ドカタ用のOOPはAdhocな実装しかできないのを言ってるんじゃないの
汎用型の操作を挿入したくても、合わせるために後から基底クラスやインターフェースぶっこむとか無茶できないしな

955 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 03:20:13.58 ID:uRBrgRbG.net]
>>928
それは自分でコントロールすればいいだけで、関数型言語を否定する理由にならない。

956 名前:デフォルトの名無しさん [2017/02/11(土) 03:38:55.41 ID:1GGXJcPM.net]
>>921
それ単にライブラリ使うか自前で書くかの違いしか言ってないよね。

957 名前:デフォルトの名無しさん [2017/02/11(土) 05:08:14.46 ID:R87vRIPm.net]
>>886
perl5じゃなくてperl6な

958 名前:デフォルトの名無しさん [2017/02/11(土) 05:18:05.14 ID:R87vRIPm.net]
>>907
言語仕様で再帰はループ最適化されるようになってるの?でなけりゃちょっと、、、



959 名前:デフォルトの名無しさん [2017/02/11(土) 05:31:02.37 ID:R87vRIPm.net]
>>914
関数型がわかりずらいってことは無いと思うが、抽象化のやりすぎが害ってのは程度や周辺の環境にもよる。
実例では、昔bazzarって分散バージョン管理システムがあって当時はgit, mercurialとならんでvcs御三家だった。
UTF-8対応とかsvnからの移行のしやすさとか他より進んでたけど、過度の抽象化・内部隠蔽やりすぎて速度出ないわ複雑化したちゃったわで廃れた。後年中の人が反省してた。
速度については実装言語がpythonってこともあったけど、同じくpython使ったmercurialよりも廃れるのが早かった。

960 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 07:08:44.79 ID:UbYHAA6y.net]
>>907
非常にわかりやすく説明されてますね。
(+) (*)だとまだfoldのありがたみが分からない人がいる気がするので、λ式を使う例も挙げると、
例えば数値リスト中の最大値を求めるには、
  foldl (λx ->λy-> if x < y then y else x) 0
とすればいい。

ループって、i -1の時点での結果(上のx)と、iの要素(上のy)をゴニョゴニョするパターンが多いから、
それらをfold(foldr、foldl)でまとめとこう、ということ。
上の右端の0は、i=0での初期値(最初のx)。
最初はうっ、となるかもしれない

961 名前:けど訓練だわね。
xがi - 1の結果、yがiと見ながらやる。
慣れるまでは全部λ式で理解した方が迷わないと思う。
[]
[ここ壊れてます]

962 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 07:33:46.72 ID:4lMkkL1V.net]
最近プログラミングを始めた初心者なんだけども
プログラミング言語ってのは万能では無くて
それぞれ用途によって成り立ちが違うものだと理解していたんだけども違うの?

それぞれの分野でいろんな方面に(意図的に)特化された言語が出てきてて
それが次世代の言語なんだと思ってた

同じ分野の言語ならともかく
違う分野の言語同士の優劣を議論しても無意味な気がするんだけど…

的外れな事言ってたらスイマセン…

963 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 08:12:27.67 ID:JyXRsfxl.net]
正論言うのは初心者だけか。

964 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 08:16:38.80 ID:uRBrgRbG.net]
>>935
プログラミングから離れて久しいのでうろ覚えだったん。。。
ご指摘感謝。

>>936
5年くらい前までは再帰はスタック消費するからと入門用で、実際には末尾再帰を書いた。
当時もリストを受け取ってリストを返す関数は遅延評価のお陰?でループになってたけど。

965 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 08:20:55.94 ID:uRBrgRbG.net]
>>922
関数型もLLも手続き型のコンパイラ言語より短いのと言われるので、短い理由が意図を圧縮(高い抽象化)とは違うと言うのを伝えたかった。

ご指摘の通り、関数型由来の機能が多いからだが、これはコンパイラ言語にも入ってるので、違いと言うとそれぐらいかと思って。

966 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 08:30:07.41 ID:uRBrgRbG.net]
>>939
特定分野のはある意味圧勝してるのであまり話題になりませんね。
ここで議論されるのは応用範囲が広い事を前提に作られた汎用言語が多いです。

なので、生産性重視か、実行速度重視かのバランスや政治的理由(どんな企業がバックに付くか)でしばしば論争になります。

仕事に使うだけなら流行りの言語でいいですが、いち早く波に乗りたいならどんな言語か?と。

個人的には言語自体は流行らなくても、オブジェクト指向ならsmalltalk。関数型ならHaskellを学んでおくと、突き詰めた先に何が待ってるかが見えて勉強になると思ってます。
ただ、突き詰め過ぎて実践より研究向きなのであくまで勉強用です。

967 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 08:48:31.39 ID:4lMkkL1V.net]
SIの営業を10年位やってまして
自分の売ってる物をちゃんと理解したくて
数年前から暇を見つけては独学で勉強してるんですが
サーバインフラ周りはひと通り理解した(つもり)ので
プログラミングを始めた感じです

ひとまず書籍が入手しやすいpythonをやってますが
同僚のSEに他にどんな言語勉強したら良いか聞いたら

「現状ならjavaやるべきだけど多分衰退するから
もっと先を見据えるなら他の言語やっとけ」

と言われまして次世代言語について調べてる次第です
いろいろあってどれが良いのかさっぱり判らんです…

968 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 09:07:44.10 ID:xeNWfnm4.net]
言語なんて少ししかないんだから思いついたら全部やればいいんだよ
そうすることによって異なる言語間でで共通した部分が浮き出てきて
新しい概念何て何もないんだ、組み合わせが違うだけなんだということが
わかるんだよね。



969 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 09:18:04.26 ID:uRBrgRbG.net]
>>944
SEさんはご自分の立場視点で言ってますが、営業が覚えるべきは自分の会社のサービスは何に役に立つか?どんな強みがあるか?です。
プログラミング言語ではありません。
そのサービスがどう言う仕組みで動いてるかを学ぶにしても、ネットワークの仕組みとか、そう言う概要的なもので良いはずです。

970 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 09:20:33.72 ID:iADUiS1q.net]
>>945
言語なんか少ししかない

971 名前:ニかどんな観測範囲で生きてるんだよ []
[ここ壊れてます]

972 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 09:24:36.21 ID:xeNWfnm4.net]
宇宙に存在する原子の数に比べていってるんだよ。

973 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 10:07:36.85 ID:Xp+0sQ+z.net]
>>939
無意味ではないよ
むしろせっかく各言語の使用者が集まってるのに、議論を放棄する方が勿体無い
例えば初心者なら、学習コストについては興味あるだろう?
虚無主義こそ無意味

974 名前:デフォルトの名無しさん [2017/02/11(土) 10:57:18.09 ID:1GGXJcPM.net]
ループに展開されることを期待して再帰書くってなんか負けてるよね。
最初からループ書けよって思っちゃう

975 名前:デフォルトの名無しさん [2017/02/11(土) 10:58:15.33 ID:R87vRIPm.net]
>>944
俺はpython好きじゃないけど、pythonの選択は良いと思う。
javaは日本の場合は、お役所案件とかクソ面白くない仕事したいとか他に選択の余地が無いからしょうがなくやる感じ。
ブロックが波カッコの方が好きなんだけどなぁ。
pythonはエコシステムがそろってきててポジティブフィードバックができてきてるからそのまま深めるといいと思うよ。
俺も主要linuxディストリブューションのデフォルトpythonが3系になったら真面目にやり直そうと思っている。

976 名前:デフォルトの名無しさん [2017/02/11(土) 11:01:59.47 ID:R87vRIPm.net]
>>950
再帰で書いた方がスッキリ書けるのもあるから、そういうのでスタック消費気にせず書けるようになると嬉しいよ。

977 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 11:15:25.28 ID:U4DU79V8.net]
再帰はスタック無駄消費するしフローチャートに起こしにくいしでいいことがないので、レビューで出されたら突き返してる
末尾再帰がループに最適化されるなら初めからループで書けばいい話だしな。

978 名前:デフォルトの名無しさん [2017/02/11(土) 11:21:17.30 ID:vYnF6jq+.net]
953は高齢おっさん



979 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 11:23:43.12 ID:OKIE+D8i.net]
>>944
これからの時代は知能プログラミング、知識プログラミングになっていきますから、
そういうものに向いていて、最先端のものが次世代プログラム言語です。
ところが、現在この分野で主流のPythonはMITで流行っていたから現在も
使われているだけで、特別理由があってのことではありません。
LISPやPrologも旧世代の言語で次世代というようなものではありません。
現在、その芽もないという状態だと思います。強いてあり得るとすれば、
Haskell。

980 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 11:26:38.99 ID:U4DU79V8.net]
>>954
せめて内容に反論してくれ……

981 名前:デフォルトの名無しさん [2017/02/11(土) 11:29:16.75 ID:fyD8uwxk.net]
最適化してくれるんなら再帰で書くだろ、普通。
なんのための高級言語なんだよ。

982 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 11:45:29.33 ID:bKkZmPiT.net]
コンパイラの挙動を意識せずにプログラミングできないものか

983 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 12:04:05.35 ID:U4DU79V8.net]
>>957
書き手のミスで末尾再帰でなくなった時になにも言わずにスタック使った再帰に変わるのは危険だろ。
なら初めからループで書いた方が間違いが起こらない

984 名前:デフォルトの名無しさん [2017/02/11(土) 12:20:17.71 ID:C+/v5lR8.net]
なんでわざわざ次世代言語スレに古いおっさんが湧くんですかね……

985 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 12:24:49.75 ID:xeNWfnm4.net]
古いオッサンはフローチャートが大好きだからすぐわかるな。

986 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 12:28:02.82 ID:Xp+0sQ+z.net]
再帰の危険性はまあ同意するけど
フローチャートは無いわ
無いというか引くわ

987 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 12:28:40.99 ID:cPTgzj2b.net]
>>953
末尾呼び出しが最適化される文脈なら、
コードとフローチャートは一対一で対応すると思うぞ

>>959
それは書き手の問題でループでもバグは生まれる

988 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 12:52:34.51 ID:qQmrAco8.net]
ふ、ふ、ふ、ふろーちゃーとwww
コード書くのにふろーちゃーと作ってる化石発見wwww



989 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 12:54:30.58 ID:0GjTSBdX.net]
次世代言語スレでフローチャートなんて単語がびっくらポンと飛び出るとは思わなかった

990 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 13:00:04.46 ID:z0i3VjKa.net]
>>944
システムインテグレータなら業務システムうってるわけだ

991 名前:
しかも開発したいわけじゃなく売り物の勉強がしたいと
それならJavaでいいんじゃないの
たぶんもの自体がJavaでかかれてるだろうし、Javaは業務システムでの公用語みたいなもんだ

同僚SEが何を持って次世代としていて何故Javaを終わった言語とよんでいるかによるね

個人的にjavaがダメなところを指摘すると、OOPを強制するところだ、OOPはたいして役に立たない上無駄な構文を沢山導入する、これらはコンピュータのためのものであって、顧客や人間のために用意されたものじゃない

それでも個人的にはjavaをオススメする
あと関数型言語を少し勉強する
(haskell,ocaml,clojure,scala)
個人的には同じjava系言語のclojureかscalaをオススメする
これらの言語はJavaを簡単に呼び出せる

何故関数型を勉強すべきか
1.顧客が必要としているものを記述する上でもっとも短い表現を考えることになる、そしてそれはコンピュータで動作する
2ドメインにおいて不変なものと可変なものの見極めをするようになる、それは要件定義においても、データベース設計においても有効

pythonもスクリプトとしていい言語だからそれでもいい
ただし2.を真剣に考える助けにはならない

それを補う意味でもエリックエヴァンスのドメイン駆動設計も一読をオススメする、これは業務システム設計の本だがOOPと関数型の架け橋たりえる内容を含んでいる、ただ独特な用語が多過ぎて初学者には難しいかもしれない

個人的に関数型が好きなのは、用語の定義づけ、概念の適用範囲が割と明確だから、設計にも活用しやすいことだ、ここで学んだことをもちろんCやC++でも使えるようになる

要は人間様のために書くのかコンピュータ様のために書くのかということを分けて考えられるようになる
[]
[ここ壊れてます]

992 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 15:16:27.69 ID:2PZ2/Gs1.net]
>>950
手続き型でも再帰の方が一般に読み易い。
だけど再帰はスタック消費するから敬遠されてた。
Haskellも最初はそうだったけど、今は違うし、関数型の再帰は上でも言ったけど、ループを関数として括り出して再利用出来るのが良いのよ。

最近のLLやC#でも同じ事出来るけど、演算子も関数ってのが効いててHaskellのが自然に書ける。
遅延評価で無限の数列や無限に繰り返す関数を扱えるのも大きい。
ファイル処理とか大活躍。

この辺はHaskellだと自然だけど、手続き型はFunc型やイテレータ、エナメレータとかって新しい機能の追加で対応してる。
関数型は数学的な関数+データ構造+副作用のある関数ってだけの知識が、手続き型だとどんどん覚えることが増える。
ハイブリッド言語になる程そうなる。

993 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 17:37:28.50 ID:ria0yk5C.net]
>>944
自分でプログラミングできるようになりたいならPython続ければいいと思う
業務システムで役立つ概念とか考え方を学びたいなら>>966の進めてるDDD本を読んでScalaかF#勉強するのが現状ではオススメ
ただ営業ならプログラミングを勉強するよりコードを書かない”SE”がやってる仕事を勉強したほうが100倍役立つと思うよ

994 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 17:44:38.51 ID:ria0yk5C.net]
>>939
超正論
コンテキスト次第でどの言語がいいのかは変わってくる

995 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 17:56:01.24 ID:2PZ2/Gs1.net]
営業なら社長さんか、社長の考え知ってそうな上司から、どんなシステムの使い方を想定してるのか、今後どう進化させるつもりか聞いた方がいいんじゃないかな。
言語って結局アイデア実現させる道具で、より使い易いのが出たら移り行くものだし。
トップがどんなアイデア持ってるかが重要だと思うの。
(もしくはアイデア担当者)

996 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 18:24:10.77 ID:v4Iby9pe.net]
フローチャートがだめな根拠が「古いから」だけでは差別だからな
数学的根拠が欲しい
そうやってフローチャート叩きを利用して関数型が勢力を拡大してる

997 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 18:29:53.26 ID:ria0yk5C.net]
何のためにフローチャートを書くのか、もしくは昔は書いてたのか自問したほうがいいかも

998 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 18:32:20.85 ID:Dru7rPMr.net]
関数型でもフローチャートは有効だけど
データフロープログラミングなんてその最たるものじゃね

フローチャートの逆は、GUIに代表されるイベントプログラミングでしょ

よくUMLのクラス図だしてフローチャートはオワコンだって言ってる奴がいるけど、そいつはuMLすらしらないから放置していい



999 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 18:36:52.20 ID:jrzBmbad.net]
> フローチャートの逆は、GUIに代表されるイベントプログラミングでしょ

そうなんだよね、イベントループからコールバック関数に処理が移る過程を
フローチャートでどう表現すればいいのか分からなくて、独自のチャートを
追加して誤魔化したっけなぁ…

1000 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 19:43:22.33 ID:QWfOXaMD.net]
基本はBASICだよ

1001 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 20:02:46.46 ID:qQmrAco8.net]
>>971
書く時間が無駄だから!!

1002 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 20:07:11.81 ID:4lMkkL1V.net]
仕事から帰ってきたら物凄いレスついててびっくりです
みなさんありがとうございます

pythonをやってみての印象は「何でもできるんだなー」という感じでしょうか
ひとことで言うなら「汎用的」というのがしっくりきました
だからこそ思うのですが、こんだけ汎用的に使えるのに
何で他に多数の言語が存在するのかが不思議でならなかったです

それで他の言語はどんな感じ何だろうかと思って同僚に聞いた答えが>>944ですね

そういった経緯で色んな言語について調べてたのですが
次世代の言語はjavaやpythonといった現行の汎用的な言語に関数型言語をミックスしたものかその逆かっていう印象です

ひとことで纏めるとそんな印象なんですが、軽く仕様を見るとそれぞれ全然違うんですよね…
goやrust辺りは何となく理解できなくも無さそうなんですが
scalaで「えっ?」てなって、haskellで「???」ってなって、
erlangに至っては理解することを諦めました…
唯一理解できたのはerlangのvmに魅力を感じてelixirを作ってしまったという人の心境だけでした…

仕事で使う訳でも無いですが、pythonを書いてるのは純粋に楽しいです
将来的には起業とか考えてるので仕事で使えそうな次世代言語も勉強してみたいですが、
まだ時期尚早(私の能力的に)なんだろなと痛感してたりします

まずはpythonを自由に書けるようになってからjavaとhaskellを勉強してみようかなと思います
いろいろなアドバイスありがとうございました

1003 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 20:16:03.84 ID:2PZ2/Gs1.net]
Erlangはそんな難しい印象なかったが。。。
Prolog由来の大文字がウザかっただけで。

Haskellは基礎を学ぶならプログラミングHaskell。
んで、モナドとはなんぞや?を理解したいならすごいH本へ進むと良いよ。

初心者はむしろJavaとかよりHaskellのが算数・数学に近いから馴染み易い。
Javaから行ってもいいけど、Haskell覚える時はJavaは一旦忘れて、数学をプログラミングに広げたのがHaskellだと思えば良い。
(実際、紙と鉛筆があればプログラミングと動作の確認ができる)

1004 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 20:28:42.84 ID:C+B9fCOA.net]
フローチャートが描かれていたのは、紙に書いて専業のパンチャーに
打ってもらった時代の名残り。今はエディタを操作する速さにチャート
編集がついていけなくなった。
フローがわかりにくい部分のみをチャートに書き出すのはありだろうが
そもそもそんなコードは書くなっていう

1005 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 20:41:24.76 ID:v4Iby9pe.net]
>>979
その理屈だと、キーボードとコマンドの速さに、タッチパネルとGUIがついていけない

1006 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 20:43:04.84 ID:7Nq7SR91.net]
>>978

>初心者はむしろJavaとかよりHaskellのが算数・数学に近いから馴染み易い。

これ、自分もそう思ってて、
会社の初心者のエンジニアにこう吹き込んでプログラミングHaskell渡したら、
舐めてんのか的なリアクションだったわ。

実績ある?布教したいので、うまいやり方を教えて欲しい。

1007 名前:デフォルトの名無しさん [2017/02/11(土) 20:49:32.91 ID:WuFir4ww.net]
次世代言語はいつまで経っても次世代のまま。
SwiftやKotlinの様な中庸な言語の方が余程将来性ある。

1008 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 20:50:51.13 ID:2PZ2/Gs1.net]
それはもう、エンジニアとして初心者でも、それなりに手続き脳に固まってるんだと思う。

手前勝手だが、パブーにHaskell入門以前ってepubの本置いてるので、使えると思ったら読ませてみて。
(パブー Haskell で検索)

あんまり純粋関数型言語ってブランドに振り回されてもいけないと思う。



1009 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 20:52:11.41 ID:Dlx8qt0u.net]
初心者なら環境作りも楽で強力なIDEの恩恵が受けられるF#がいいと思うなあ
もっと関数型について深くまなびたいとなったらHaskellやってみない?という流れが良いんじゃないかな
HaskellはHello,Worldまでが遠すぎるから初心者にはどうかなあ

1010 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 20:55:58.54 ID:2PZ2/Gs1.net]
え、JavaやPythonの環境構築と変わらんが。。。
あれ出来なかったらプログラマ以前の問題。

1011 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 20:56:30.71 ID:Dlx8qt0u.net]
いやプログラマじゃなくて初心者の話でしょ

1012 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:04:17.29 ID:2PZ2/Gs1.net]
>>982
Haskellは永遠の次世代言語何だろう事は承知してるが、学ぶべき言語である事に変わりはない。

1013 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:07:57.21 ID:2PZ2/Gs1.net]
>>986
全くの初心者も一応?想定してるので無問題。
あれで拒否られたら、ただの食わず嫌い。

1014 名前:デフォルトの名無しさん [2017/02/11(土) 21:08:58.10 ID:0eM0mGZz.net]
Haskellは言語仕様は好きだけど、学べるまでが遠い
Stackがもっと整備されるまではコンピューター初心者に勧めるものじゃない

1015 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:11:13.26 ID:Dlx8qt0u.net]
いやまあ環境構築の部分は別にそこまでこだわらなくてもいいんだけど
要はより簡単に始められて、簡単に出力するプログラムもつくれて、間違いもIDEに指摘してもらえるってこと
HaskellはHelloWorldまでに学ぶことが多いから初心者に向くのかなあと思ってね

1016 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:15:17.00 ID:2PZ2/Gs1.net]
なぜstack。。。
そこまで応用出来んでも、十分既存の言語使うのに役立つ知識を吸収出来る。
アルゴリズムをコード丸暗記馬鹿とかに効果覿面。
(おいらの事だ)

1017 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:15:25.18 ID:v4Iby9pe.net]
初心者に静的型付けを布教するな
Java初心者にはジェネリクスを教えないし
C++初心者にはCを教える

1018 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:16:47.99 ID:9jDGkB4H.net]
エディタを、Haskell用に補完も出来る、コンパイルも出来る、バッファ内でghiが動くように持ってくだけでも一苦労だわ。



1019 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:20:21.10 ID:Xp+0sQ+z.net]
純粋関数型と言うが、よく考えたら結構ひどい宣伝だな
真面目に製品レベルで組もうとすると、traceやunsafePerformIOが増えてくし
そこまで行かずとも、IOUArrayとか使ってるだけでIOだらけになって、純粋って何だっけとか思い始める

1020 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:21:28.63 ID:2PZ2/Gs1.net]
>>990
それこそ、Haskell知ってる人(>>981)が身近に居るなら、その人に聞けば良いじゃない。
それでなくてもHoogle教えれば勝手に調べられるし。

1021 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:23:10.42 ID:Xp+0sQ+z.net]
>>993
leksahとか使ってあげてよ…

1022 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:24:23.52 ID:7Nq7SR91.net]
>>983
ありがとう、見てみるよ。

1023 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:27:00.53 ID:7Nq7SR91.net]
>>995
いや、解説するまでもなく、渡して一時間でごめんねー自分そこまで賢くないから、
ごめんねー、
と、ややおこで返却された。

1024 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:27:29.82 ID:2PZ2/Gs1.net]
>>993


1025 名前:待て待て、ただの学習用になぜそこまで環境整える。
普通に好きなエディタでいいよ。
何も本格的に使う訳じゃない。
良い概念覚えて知ってる言語に活かせってんだろ?
[]
[ここ壊れてます]

1026 名前:デフォルトの名無しさん mailto:sage [2017/02/11(土) 21:30:05.06 ID:0GjTSBdX.net]
「フローチャートは時代遅れの厄介者」

1975年初版発行の『人月の神話』より

>1975年
>1975年
>1975年

わかるか?

1027 名前:過去ログ ★ [[過去ログ]]
■ このスレッドは過去ログ倉庫に格納されています






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<256KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef