次世代言語Part8[Haskell Rust Kotlin TypeScript]
■ このスレッドは過去ログ倉庫に格納されています
スレタイ以外の言語もok
前スレ
次世代言語Part7[Go Rust Swift Kotlin TypeScript]
http://mevius.5ch.net/test/read.cgi/tech/1508403098/ 関数型の後Pythonに戻ったら、それまでとも違うけど関数型でもないコードになった lambdaが書きづらいからとか?
やっぱ関数型プログラミングはRubyのほうが強いのか Rubyと比べてどうかは知らんけど、Pythonのデータ構造や文法ならいわゆるPythonicな書き方が書きやすく読みやすいので関数型特化する必要がないので、関数型には書きにくい なぜ関数型とRubyが、目的と手段なんですか
理想主義と現実主義ではだめなんですか 関数型って何をさすのか
よくそれだけで会話が通じるなと思うわ 言語の標本集合をさすんじゃないですか
現実の言語にはばらつきがありますが、平均すれば理論値に収束する筈だとか 標本がどうのこうのじゃなくて
会話噛み合ってないだろってことだよ
頭でっかちさん rubyのfirst classですらないlambdaだって書きやすくはねーだろ >>658
ほんとにな。
ラムダ一つとったって型なし、型あり
型にしたって、型に依存する型、型に依存する項(関数など)、項に依存する型とか色々あるのに。 PythonicとかPythonistaとか、改めて見るとすごい呼称だ。 >>653
書きにくいから、Python の公式文書では lambda で書いたコードを
手続き型の for ループへ書き換えることを推奨している
https://docs.python.jp/3/howto/functional.html >>656
あれれ、日本国内ではそういう認識が浸透してるの?
世界的には Python の lambda が欠陥であることは広く知られていて、
改善に向けた議論も重ねられたけど、結局、作者のGuido氏が
「解けないパズル(unsolvable puzzle)」と匙を投げたという残念な
結論のまま現在に至っているという共通認識があります
https://mevius.5ch.net/test/read.cgi/tech/1415419907/197/
やっぱり日本在住の Pythonista がガラパゴスなのは昔から同じですね
http://mevius.2ch.net/test/read.cgi/tech/1345123070/70-71/ python のラムダの使い道ってほとんどがソートに渡す比較関数くらいだと思う。 世界的な認識のソースでも貼ってそうな場所にあるリンクが2chの別スレへのリンクで困惑している Pythonあまり知らんけど、上のリンク見てて思ったのは、
1. 自分で高階関数を作れない(ラムダ式が利用できる関数が少ないと書いてある)
2. where節みたいなスコープの限定されたローカルな書き捨ての関数を用意する文法がない(読みにくいでしょ?とか書いてある)
この辺の縛りがあるからでないかい? ごめん、>>669は寝ぼけて適当なこと書いたぽいから、無視しといて。 関数型っのがどういう定義かは分からないけれど、
HaskellとPythonを比べると、パターンマッチが
なくて再帰が書きにくいと感じたり、
基本破壊的だから、わざわざ非破壊で書くのが
めんどくさいと感じる。
内包表記は似ていて良いかな。 Schemeのマクロ定義でパターンマッチを使えるがすごい不人気だったよ
おそらくパターンマッチのアルゴリズムが透けて見えないと人気出ないよ うちのプログラマは大半がコトリンに移ったのでわしらラストを使うことにした 関数型言語のパターンマッチって理論的な裏付けってあるんだろうか 理論的てのが分からんけど、例えばリストを引数にとる関数なら、
空リストとSuccの場合を定義しとけば、帰納的に任意のリストについての適用結果が求められる、
とかそういうの? 評価順序とかモチっと低いレイヤーでの動作規定ってことでないの?
ABIレベルでのさ。 >>676
そうそうそういうの
関数型ってって原理的にはあらゆるものが原始的な計算原理に還元できるものって理解してんだけど
パターンマッチはそういう裏付けあるのかなって疑問 >>679
単なる場合分けだから裏付けもクソもない 補足
パターンマッチは場合分け、つまり条件分岐そのものであり、
通常はそれ自体が原始的な計算原理の一つとして定義されるってことだぞ
だから裏付けなんぞ必要ない 学術的なことは分からないけども、静的型のパターンマッチは網羅性を
コンパイル時にチェックしてくれることが多くて
それが凄くありがたい
動的型言語にパターンマッチを持って来ても上手くいかないのは、
上のメリットが得られないからでは? >>679
上の人が書いてるように、ただの場合分けだと思う。ただ、>>682の人も書いてますが、本当に網羅しているか、を考えると理論が出てくる気がする。
定義域の型が、型コンストラクタで定義されてれば、そいつら全てについて場合分けする、
で、そいつらも型コンストラクタが入ってれば、、てのを続けていけば、全てについて網羅的な場合分けが出来る。
言葉だとわかりにくいですが、Agdaの動画を見るといいと思います。
定理を証明するのに、上の場合分けを考慮する必要があって(漏れたら困りますよね?)、
実際EmacsのAgdaモードだとそういうのを勝手に展開してくれるコマンドがあり、
ゲーム感覚で証明してく感じ。
で、カリーハワード対応を考えると、関数の定義も結局は同じで、実際同じコマンドを使って進めてくことになる。その流れでやれば、後で漏れてる云々は問題にならない。
こんな感じですかね? >>682
動的言語はデータクラスをほとんど使わず、辞書や配列を生で扱うことが多いからじゃないかな
型で分岐するケースがそもそも少ないし、when Some a みたいにパターンマッチと同時に要素を抽出したくても抽出の仕方が定義されていない >>678
俺は最近書いてないぞ。
つまらんからな。 パターンマッチで変数にバインドするところとかあれってどう還元できんですかね? ・頭文字が大文字ならコンストラクタ (引数0個以上)
・そうでなければ変数 (引数なし)
少なくともこの仕様を守れば動的言語でもパターンマッチできるよ 難しく考える必要はない
タプルは関連する複数の値をまとめて扱ってるだけ
レコードはタプルに型名というラベル値が付いただけ
型によるパターンマッチはその型名で条件分岐してるだけ
変数へのバインドはタプルの特定の要素の値にに別名を付けただけ >>682
動的言語どうこうではなく、オブジェクト指向の情報隠蔽とパターンマッチの相性が悪い。
アクセス制御をかいくぐってデータ構造にマッチさせるぐらいなら
オブジェクトを受け取ってからメソッド叩いたり条件分岐したほうがマシ。 >>690
SuccessとFailをパターンマイッチングするんじゃなくて
class Success implements Resultと
class Fail implements Resultみたいにしろ
ってこと? 本物のオブジェクト指向はTrueクラスとFalseクラスを使う
Bool &True::ifTrue(Block f) {f(); return this;}
Bool &True::ifFalse(Block f) {return this;}
Bool &False::ifTrue(Block f) {return this;}
Bool &False::ifFalse(Block f) {f(); return this;} こういうときオブジェクト指向ってアホの自慰っぽいなと思う その次の世代はtemplateを使いvirtualを消し去る
だからifが復活 多次元配列と第一級関数をサポートしている静的言語ってなんかあったっけ? >>697
それサポートしてない言語って何があるの? >>701
多次元配列サポートしてる言語なんて他にはFortran, R, Python, Julia, Racketくらいしか思いつかない
第一級関数は最近増えて来てるけどFortranみたいな古い言語はだいたいサポートしてない >>702
多次元配列サポートすると何の役に立つの? >>703
行列計算とか、その他数値的な解析がめちゃくちゃ書きやすくなる。
いわゆる数値解析や流行りの機械学習からゲーム開発まで、くまなくアルゴリズムが書きやすくなるぜ サポートてのは、数値計算でよく使う引数が2の関数と、そういう関数とと中置演算子との間の糖衣構文が標準でオーバーロード気味に存在するってことですかね? >>704
Racket挙げてるし中置演算子は重要度低いけど、よく使う関数はチューニングされたものを置いておいて欲しいな
Numpyだって標準ライブラリじゃないし、最悪標準ライブラリじゃなくてもいいけど、「数値計算するなら常識的に考えてこれ」という一つに定まっていてほしいな。
あるライブラリはEigenに依存しているが他のあるライブラリはublasに依存してるみたいなのはやめて欲しい >>702
良かった。言語として普通にあるもんだと思ってたから
無いことを想像したこともなかった。 Pythonは多次元インデックスをオーバーロードできるけど組み込みの多次元配列は無い
PythonレベルのサポートでいいならKotlinも同等だね そういえばExcel方眼紙もある意味二次元をサポートしてるな
Excelの異常な人気の原因はそこか 義務教育に向けて親もプログラミングやっときたい、どれが良い?
Pythonとかよく目にするけど、と聞かれた。
どう答える? 相手が挙げて来た言語のメリットを適当に言ってそのまま勧めれば良い
親が教えるためにやる言語なんて何でも良いし、違いがわかる頃には子供は卒業してる
選ぶのも面倒くさい >>712
まずはExcelのVLOOKUPを使いこなせるようになれ
次はVBAをやれ
でいいよ
教える側が何の役に立つのか分からないまま人に教えるなんて全く何の意味もない >>712
教育ママに特定の言語やらせて認識を固定させんな、むしろ子供に害悪だろ
数学パズルでもやらせとけ 子供にはScratchをやらせることになるらしいから、親もScratchをやればいいじゃん >>712
やはり再帰的思考が勘所かと考えていますので、scheme をお勧めしようかと思っています >>712
Haskel
関数型を理解できないバカはプログラミングする資格も意味もなし
保守困難なウンコをひり出すだけのゴミは消えろ
と伝えてくれ >>718
Haskellの綴りも正しく書けない池沼は文章を書く資格も意味もなし
無意味なウンコをひり出すだけのゴミは消えろ >>711
excelは関数型言語だ、と言う人々も居るくらいだからな(笑) Excelはビジュアルリアクティブプログラミング環境と言えばまあ間違ってはないんだけど
二次元配列以外の構造の扱いが難しすぎて、学習用にしてしまうと
他のデータ構造を学ぶ機会がないまま何でも二次元配列に落としこむ悪癖がついてしまいそうで >>721
人間が無理なく扱えるデータは二次元の表が限界なんだよ
考えてみろ
お前がよく使う構造体やクラスのリストや辞書は実質二次元の表だろ
オブジェクト指向では直接深く階層掘ったアクセスは嫌われるだろ?
なんだかんだ格好いい理屈を付けても、結局人間にはExcelのデータ構造が馴染むんだよ >>722
再帰的 or 多相な構造どうすんのよ、ってのはまあExcelの用途では滅多にないとしても
単純に三次元配列が欲しい時もあるし
Sheet増やしだすと急に面倒くさくなるんだよなあ >>723
再帰なんか同じ表の行番号を持たせるだけだろ 3次元以上を汎用に使おうとするとSQLみたいだったり tensor flow だったり
かなりめんどくさいインターフェイスになるのはしゃーない。 まぁ、Haskellで作られたものより、Excelで作られたモノのほうが多いしな(笑)
純関数型(笑) >>719
このようなtypoを防ぐためにも強い型付けが必要なんだよ >>727
変数宣言(型宣言ではない)だけでいいと思うが、それだけでもいいから、事前チェックを可能にしてほしいなあ
python のバイトコンパイル機能は変数名をチェックしてくれるのでしょうか? headerをincludeしてチェックする言語は簡単だけど
コンパイル済みのライブラリの中身を見て名前をチェックする言語は大変そうだ
コンパイル後も情報を全部残しておかないといけない 変数宣言を省略できる機能(スペルミスが検出できない)と、型付けは別だよね?
昔のFortranやBASICは変数はいきなり使っていいけど名前で型が決まる静的型だったし 宣言がない変数は、省略ではなく他のファイルで宣言している可能性がある
そのファイルをincludeするか、全てのファイルを検索する必要がある 下がってから言っても遅いな
レベル高かった頃に、なにこれ高いって評価できる奴が勝つ まぁ、その時から無駄なつっかかりしかできない奴ばっかだったし仕方ないんだろうな。
今更option explicitじみた話に戻るとは。 自分で書いたコードが三ヵ月後に読めないっていうやつは素人
プロは三ヵ月後の記憶喪失を織り込んでる そういう足を引っ張る人には保守受注の代わりに
ベーシックインカムをあげたらいいんじゃないかと言われている
足を引っ張る悪人より善良な怠け者の方がいい しょーもない理想論はいらんねん
こっちはきっちり世間様に仕事回してんねんで
頭の悪いガキは黙っとき ソースがきれい → オタクの自己満足
ソースがきたない → 工数取れて残業代も出る、みんなニッコリ
これが現実やで そんなことしてるから他国の技術に駆逐されるんだよ。。 その理屈だと、まるで必要もない次世代言語で書くやつみたいだな。
汚いソース書くやつは。 次世代言語で書くだけならいいんだよ
故意に汚くするとはいってないから、改善する可能性がある
故意とただの偶然とでは罪の重さが違う 故意にその言語で書いてる以上、もう偶然でもなんでもないだろ。
ちゃんとその言語のメリット、デメリット含めて布教してから使うべきだと思うが。 ちゃんとする可能性があるならいい
その可能性をわざと排除するなら悪質
最初からそう言ってるんだろ まあ大体がカスな開発体制に問題があるところに
新しい言語なら問題解決できる!
とかめちゃくちゃな広告が出回って導入、失敗っつークソパターンがここ20,30年の間繰り返されてるわけだからな。 JSに依存するのはいいがGHCがな
もしもF#がGHCに依存していたら面倒臭いじゃないか ■ このスレッドは過去ログ倉庫に格納されています