◎正当な理由による書き込みの削除について： 生島英之とみられる方へ:
次世代言語Part8[Haskell Rust Kotlin TypeScript] YouTube動画>3本 ->画像>4枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1512137301/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
スレタイ以外の言語もok
前スレ
次世代言語Part7[Go Rust Swift Kotlin TypeScript]
http://2chb.net/r/tech/1508403098/ SwiftがなくなってHaskellが復活とか笑っちゃいますね！
結局Haskell批判してたのエアプだけだったし、実のある批判が出るまではええじゃろ
まぁランダムでスレタイに入れる言語を4つ選ぶプログラムとか書いちゃえばいいのよ
つまり毎回スレたて人の好みで言語が決まるのですね。
乙。だがGo入れろ
Haskellは前の議論で次世代から落ちたはずだけど？
あとRustなんて言語未満いれるな
面接でたまに、特定の言語けなす応募者が居るけど、
じゃあどんな言語が好きですか？なぜその言語が
良いと考えるのですか？と聞くとダンマリ。
いいんじゃねーの？
特定の言語をマンセーしてる奴よりか、
言語の問題点を把握してる奴のがプログラマとしては信用できるし。
このスレは特定の言語をマンセーする人は少ないな
その代わり知らない言語を批判する人はいるけど
sから始まる言語を批判すると、気持ち悪い信者がワラワラと湧いてくるよ
漏れなら面接で、Rust, Elixir, Kotlin, Haxe の良い点を聞く
>>16 まあ好きだって言った言語に対して狙い撃ちされる会話の流れを
理解してるって意味ではいいんじゃねーの。
結局、自分が不愉快だったってだけの話だろそれ。
TypeScript 入れるくらいなら PureScript 入れたらいいのに
そもそも次世代言語とかいうものそのものが、大企業の広告塔でしかないからな
GoとかTypeScriptとかRustとかモロそれ
コンパイラがGPLでライセンスされて活発に開発されて、特定の企業集団に開発が握られてない言語だけを数えるべきでは
この点でオレオレ実装と、政治でねじ込んだクソ古いgcc実装しかないGoや、llvmバックしかないRustは除外される
Typescriptもアウト。まともな次世代言語は存在しないと言ってもいい
>コンパイラがGPLでライセンスされて
なんだろうこの臭気
「批判」とか「政治」とか大雑把なジャンルしか認識できない奴はいっぱいいる
記憶力が足りないのか
そもそもリアルタイムで論破すれば記憶力いらないのに、反射神経が足りないのか
言語の成り立ちっつーか、誰が開発しててどこが意思決定権持ってるかは重要だぞ？
Javaコンパイラのバグを握りつぶしたOracleの記憶はまだ新しい
言語はプログラムを作るものなのに、その言語がブラックボックスかしてたら、そんなもん使うべきではない
どんなリスクがあるか分かったもんではない
GPLはクサイと言われるが（実際面倒な話なのは承知してるが）、
GPL以外のライセンスでは、後付けでブラックボックスかできてしまう
だからGPLのコードベースで開発がすすんでいることは重要
BSDやAPLでコンパイラをリリースしたら「次世代言語じゃない！」ねえ ┐(´д｀)┌
ID:72s6oBNC
今日のガイジ
便所ブラシことペチプーでも書いてればええんやないか？
>>29 なんで次世代言語のGPLライセンスは重要って言っただけで肥溜めに頭から突っ込まれなきゃいけねえんだよ
土人かよ
Haskell Rustあたりは仕様を知ってるだけで嫉妬されるレベルなんだろ
そりゃ実装はブラックボックスでもいいかなってなるだろ
>>32 いかにも実際の仕事をしらないお偉いさんが机の上でこねくりまわした感がある
言語が何であろうと使ったことがないアプリはソース読めないぞ
読む前に使い込むべきだ
使う前に読めると思う方が机上なんだよ
やっぱHaskell入ったんだな。
よっぽど悔しかったんだろうなあ。推しなのに。
AKB総選挙かよw
労力が見合うかは分からないけれど、
大抵のコンパイラはソースも公開されてない？
>>33 >いかにも実際の仕事をしらないお偉いさんが机の上でこねくりまわした感がある
その評言が当てはまるのはHaskellでもなくRustでもなく Go 言語
>>36 まさかMITやAPLとGPLの違いが分からん奴がこのスレにいるとは
>>30 >なんで次世代言語のGPLライセンスは重要って言っただけで
違うだろ
お前さんが
>>19 で言ってるのは、コンパイラがGPLでなければ
次世代言語には数えられないってことだったろうよ
>>39 そうだが？
ないと次世代として認めがたいっていうのは要素として重要ってことと矛盾するのか？
あとな、言語屋の端くれとして言わせてもらうと
まあ成果物（特に公的研究機関）の公開の際にGPL採用するって選択肢はほぼないんだわ
>>40 はあ？
>>30 の「言った『だけ』」の「だけ」の部分が大嘘だろうがよ
PHPが相応しいかどうかは知らんが、まあガイジ乙ってこった
結局このスレの住民も、ジョブスの作った快適な牢獄で永久に囚われる方がお好みってか
ほんとディストピアになったな
>>41 HaskellはともかくGoやRust、Typescriptは研究機関の成果物じゃなくて単なる企業の広告塔だろうが……
成果物ではなくて広告塔でもなくて自社製品を作るためにできた副産物だろ。
Rustが研究しているのはジョブズではなく静的型付け
牢獄になるとすれば静的型付けが牢獄になるんだよ
>>44 >結局このスレの住民も、ジョブスの作った快適な牢獄で永久に囚われる方がお好みってか
>ほんとディストピアになったな
あ、ガイジというよりはキチガイのひとだったか
>>47 >牢獄になるとすれば静的型付けが牢獄になるんだよ
一部のLISPer除いてRustの型システムでは型が付かない正当なコードが書きたいのに書けない！なんてやつ殆どいないだろ
静的型付けはQBみたいな奴だ
牢獄と契約は似たようなものと思うか全然違うと思うかは人それぞれ
じゃあどんな言語が好きですか？なぜその言語が
良いと考えるのですか？と聞くとダンマリ。
>>38 ソース読めれば、ブラックボックス化は
防げるんじゃないの？
あなたが上げてるライセンスで、
ソースを読んではダメってモノは
ない気がするんだけど。
厳密に言えば配布されているソースと配布されているバイナリが違う可能性は存在するけどな
わかりやすい罠でも仕込まれてない限り検証不可能だろ、GPLであっても
>>53 GPLでない限り、どこかの瞬間にソースをクローズドにできてしまう
その違いくらい分かっとけ
>>56 そういうものは単にソースが公開されているだけで、企業にとって都合の悪いコードは入らない
開発姿勢の問題
クローズドにされた派生物は元のオープンソースにその企業なりの変更を加えたものだろ。
他の人はクローズドにされる前のオープンな方を使い続ければいいだけ。
>>59 元コードのライセンス自体を変えられたらアウト。MITやAPLなら不自由なライセンスに変更することが可能
GPLならそういうことは不可能
今時、GPL真理教のご登場とは、驚きだな。
そういう人は、次世代言語がgccに組み込まれるまで、待ってたらいいと思うよ。
新しく配布するライセンスを変更することはできても、一旦ライセンスされたものを過去に遡って
変更するなんてことはそのライセンス自体にそのような規定がない限り無理。
新しく配布するライセンスを変えるって話なら(その権利がある者なら)元がGPLだろうが可能なのは同じ。
GPLも違反の場合の措置は国の法律に従うとかそんな規約だった気がするから、
国によっては過去に遡って棄却とかあるんじゃねーの？
言語屋の端くれって何者なんだ。
工学博士の端くれぐらいまではギリギリ言ってみようかとも思えるけど、言語屋って凄いな。
こんなところで喚くしか能のないゴミ屑が
ライセンスうんぬんで不利益被るほどの立場なわけないだろ
大人しくプェチピィで下痢糞プリプリしてろよ
>>1 前スレ終盤でも名前挙がってたが、Elmバズってるな
本スレがない言語(Elm Nim Crystal他)もスレタイ候補でいいか
ElixirからElmの流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。
https://ubiteku.oinker.me/2017/12/02/skepticism-about-oo/ OOを批判するのはいいけど消去法で関数型とか思うのは大間違い
消去法するくらいなら対案を何も出さない方が正しい
関数型の定義はよく分からんけど、第一級関数は欲しいな
redux（react）触ったやつがelmに流れてるんだろうな。
js+redux+immutable.jsの組み合わせだったらelmってことかね
「じゃあお前はどんな言語なら満足なんだ」ってしつこく聞かれてるから言うが
次世代言語かって言われたら微妙だからあんま挙げる気はなかったんだが、理想はVala
Cにトランスパイルされるから速度は良好、コンパイラのライセンスはLGPL、構文は比較的モダン
ただ今時の他言語と比較するともう一声ほしい
バラ、初めて聞いたわ
よくそんなマイナー言語知ってるな
GNU狂儲じゃない人にとってはValaなんてC#の劣化コピー未満だし、
C#は現世代言語だから次世代には不適格だろう
その性能を見せてくれたら変わるかもしれんけどな
.NETのメモリを食い尽くす糞戦略GCが無いというならまあ……
Cにトランスパイルされて性能良好という点ではnimと丸かぶりな上
基本的にnimのほうが融通がききそうな気はするけど
GObject互換が有利に働くケース(例えばcairo呼ぶとか)ではValaの方がいいんだろう、たぶん、知らんけど
まあだからValaが次世代言語とは一言も言ってない
例えばNimのコンパイラが(L)GPLになってくれてれば全力で推すよ。でも現実はMITだ
>>60 Linuxなど極一部の例外を除いて、今時のまともなOSSは基本的に全て企業様が開発しており、
寛容にも乞食に対して提供してくださっているものである
GPL信者が主張する、企業が成果物をGPL化するメリットとして、
「コミュニティからの協力を受けられる」というのがあるが、(乞食共の協力がどれだけ役に立つかは別として)これには落とし穴がある
GPLで公開してるものに対して乞食がプルリクを出し、これが本家にマージされた時点で、本家のソースがGPLに感染するということだ
これは企業にとって到底受け入れられるものではない
GPLは企業のオープンソースへの参加の障害になるんだよ
>>75 補足
本家のソースがGPLに感染するというのは、開発元の企業自身が、ソースの使用にあたりGPLに従わなければならなくなるという意味な
成果物をドブに捨てるようなもんだ
そういうものはデュアルライセンスで公開するんじゃないか普通。知らんけど。
逆に考えれば自分がただで作ったものが企業の金もうけに使われるのを防いでるわけだろ。
そういういみでGPLは必要。
>>78 そう。つまりこういうことだ。
ユーザーからのコミットを受け入れるというポジティブな理由でオープンソースを採用するならGPLは不適切。
オラクルのように、有償契約への誘導を前提としてオープンソース版を撒き餌にするなら、
成果物の盗用を防ぐ意味でGPLが適切。
本来OSS信者が批判すべきなのはどちらだろう？
一度落ち着いて考えてみよう。
だから「自由ソフトウェア」と「オープンソースソフトウェア」は違う概念って話だよな
そもそも企業が主導してる開発は、企業の恣意が入るわけで、自由ではない
今は乞食に恵むことが点数になるからそうしてるだけ
乞食に甘んじるならそれでいいかもしれんがな
一念発起して自分の畑を開墾することになったときに、GPLがないと企業に土地を盗まれたり、いつのまにか乞食に占拠されたりするんだよ
だからGPLの言語は重要なんだよ
もっというと、
・プロジェクトにコミットした個人乞食にとって、そのプロジェクトの最新の成果物を継続的に利用できる利益を守るのがGPL
・開発元の企業にとっての利益を守るのが「寛容なライセンス」
ということだ。そして、下記の理由から、後者を優先したほうがOSS全体にとっての利益が大きい。
・一般に、個人より企業の方がOSS遥かに多くの貢献をしているから、企業の参入を促したほうがOSSは拡充する
・当たり前だが、利用者にとっては寛容なライセンスの方が利用しやすい
>>78 別にGPLは金もうけに使うことを防ぐためにあるわけじゃないよ。
実際、金もうけだろうがなんだろうが単純使用については制約を設けることを禁止してるわけだし。
個人で出来る開発なんて限られてるから企業が参入してくれたほうがいいし、企業は慈善団体じゃないんだから利益考えるのは当然だろ
企業がーステマがーって気持ち悪すぎる
わざわざ次世代言語スレに来て、
「俺ルールにより、全ての言語は次世代ではない！！」
ってマ？
GPLは自分が作ったものだけじゃなく使ったものにも影響を及ぼすからなあ
LGPLが一番マトモなんじゃないかと思ってるんだが
>>81 OSSが拡大しても自由ソフトウェアは拡大しない
まあ言語スレでやるべき話題ではそろそろなくなってきてるのはすまん
望まれてないから拡大しないんだ、ってのが分からないところが儲
>>19 まあ、大企業がサポートしてるからこそ信頼性が増すんだけどね。
弱小勢力の作ってる言語なんざいつやる気が無くなってサポート停止するかわからんのに
使ってられないよ。
サポートを永久に続けさせたいとは思ってないんじゃないかな
ただ、無料版だけサポート停止して有料版に移行させる手口を防ぐだけでいい
このガイジの言葉を全否定するが、別に言語の処理系のライセンスがGPLだろうと非GPLだろうと
その言語で書かれたプログラムのライセンスには何も影響しない
Javaの処理系がクローズドソースだった時にJavaコードがオープンソースにできなかったかってことを考えればすぐ分かる
言語の仕様がオープンなら、もしこのガイジの懸念どおり処理系をオープン→クローズドソースにされたところで
本当にその言語が有用だったらクローンの処理系が出てくるだけのこと。open-jdkやらmonoが良い例だ
要するにこのガイジ、ライセンスのことを何も分かってない知ったか
ガイジを殴るだけのレスだと何なので
Haxeみたいな「書いた端からあらゆる言語にトランスパイルして使う言語」ってやっぱりコンセプトとして駄目なのかね？
最近のいわゆる次世代言語って、おおむねネイティブ（もしくはJavaマシンコード）にコンパイルする系ばっかのはず
例外はTypescriptとHackくらいか？
93,94をまとめると
GPLなコードを再利用しつつ有料版に移行させるのは無理
コードを捨ててクローンするならOK
>>94 Javaに関しては、openjdkを勝手にフォークして改変したものを出回らせたら特許侵害でオラクルに訴えられるよ
特許の利用はあくまで公式にリリースされたopenjdkに対して認められてるもので、
弄ったらJavaとは認められなくなり即訴訟
>>97 すまん、open-jdkっていうのは不正確だったな。IcedTeaって言った方が正確だった
まあ厳密にはIcedTeaも当時のSunの協力あってのことで、勝手フォークでやった訳ではなかったんだが……
>>95 中間言語のせいで遅くなってる直接アセンブリ(機械語より広い意味で)にできるなら効率的なのにグギギギギ
というのを気にしなければトランスパイラでもいいんじゃね
Typescript→Javascriptぐらいなら気にならんだろ
Scalaとか思いっきりJVMに足を引っ張られてた例と思う
ちょっと話は違うけど可変長配列を値返しできる言語を主にC系のことしか考えてないバックエンドで実装すると
mallocして返すかForthみたいにデータスタックをもう一つ用意するかぐらいしか方法がない、みたいな
書いてからもっといい例を思いついた
トランスパイル先に選ばれそうな言語(CとかJVMとかJavascriptとか)って
どれも末尾呼び出し最適化が保証されてないから関数型言語なら避けたいはず
末尾再起最適化なんかトランスパイルの段階でできるだろ
自分でやってみりゃわかるけど、別の言語への変換って細かい仕様のすり合わせが難しくて
どう頑張っても変換結果は綺麗なコードにはならんよ
>>101 自身への末尾「再帰」は変換できるが、末尾「呼び出し」一般はかなり難しい
特にモジュールをまたぐとまず無理
トランスパイルする時点で全部gotoにしちゃえばいいんじゃねえの？
ヒープは馬鹿でかい配列切り出して貸してやりゃ良いじゃん。
一番現実的だと思うけど。
と言うか間違えられてかわいそうだな。
トランスパイラだから、トランスパイル先の言語の作法を守らにゃならん、なんてトランスパイラは
どっちつかずのゲテモノになるなんてのが歴史的にある程度わかってきたんだから、諦めて超高級マクロアセンブラとして使うべきだと思うが、
やっぱそのトランスパイル先の美しさって必要なのかねぇ。
>>105 ありがとうありがとう
で、goto式だと呼び出し先も含めてひとつの関数にまとめないといけないので
他の関数をtail callしているのがつながって爆発的にコードサイズが膨れ上がる
JVMだと64kbの壁があるとかないとか
https://togetter.com/li/280057 またモジュールを超えるとアクセス制御にかかったりもする
>>100 javascripというかecmascriptは末尾再帰の最適化は仕様になってる。
Cにはlongjumpがある。
これを使えば親の関数へどこへでも飛んでいける。
末尾再帰もオプションで設定できる。
>>109 JVMだとgotoが相互に飛んでない奴らで一つの関数にまとめるしかないな。
ただ、一つの関数が64kbまで、ってそこそこ余裕あると思うよ。
関数に関数をおさめようとするから爆発的に長くなるというか、実質、関数の後ろにおまけ付いたコードが量産される事になるんだと思う。
呼び出してる側まで全部展開してしまうと割と短くなる。
昔、ホントにそういうトランスパイラ作ったけど、割としっかり動いた。
動的なメモリ確保をほとんどさせられなかったからそうなっただけだけど。
>>112 ホントに高級アセンブラだよなぁ。
jsへのトランスパイラは現状、
jsが、webにおける機械語的な立ち位置
だからというのはわかる。
でもcへのトランスパイラってどんな意味があんの？手抜きとしか思えない。
手抜き出来ることはメリットだろ。
実装と仕様は分けて考えるべきだからな。
手抜きっつーか、Cに変換しておけば、おおむねどんなlibcでも石でも対応するコンパイラがあるってことでは
GoみたくあらゆるものをGo内で完結させるための車輪の再発明だとか
Rustみたく欲しい環境のtripleがあるかとかtierがいくつだとか
そういう言語機能と直接的には関係ない部分のサポートに関する労力をまるっと切れるのがでかい
一時期のaltJavaやaltJSの乱立を見てると、その分言語の質が上がるかって言われたら怪しいけどな
あとllvmの台頭で、ある程度その辺を再利用できる環境が整ったから、直接機械語吐いた方がよくなりつつあるのもあるか
>>117 自分で言ってんじゃん。
llvmだったら中間コードまでのトランスパイラ作れば最適化とバイナリはくまでやってくれるしそこまでやりゃ良いのに。
あとgoの車輪の再発明はありだと思う。
画像変換したくてimagemagicのlibに依存する羽目になるとか勘弁。
車輪の再開発はありとか自分が作る立場でも同じこと言えんの
>>115 最適化とかそういう所にそれほど苦労しなくなるかな
手抜きといえば手抜きなんだけど
gccをバックエンドにするなら変な石対応が簡単だし
vc++でも食えるように書けばWindowsでも余計なもの要らないし
intelのコンパイラでゴリゴリに最適化かけたりとか、
静的ビルドでワンバイナリ作りたいからCの方のコンパイルオプションでリンクしよう、とか
既存の処理系に乗っかるのはメリット多いと思う
>>118 llvmが台頭してきたから相対的にCトランスパイルの魅力なくなってきたよなって話で、
昔はCトランスパイラで既存のコンパイル環境に乗っかるのがよく行われてたって歴史的な話な
gccが中間言語仕様を意図的に隠してた弊害とも言える
実質的にはトランスパイルだろうが何だろうが、とりあえずは関係ないが
今時ライブラリ構築を0からするというのは自分一人が使う自分専用言語だと考えても
汎用言語としてはあり得なくて、何か既存の言語のソレにフリーライドせざるを得ないわけで
となれば何に乗っかるかという部分から考えるし
それが決まってから具体的な実装方を考えるし、なんだったら自動的に決まってくるわけで
余談だが、良くある乗っかり先としては、CとJavaと.NetとJSがあるが・・・
ただ、例えばネイディブコードが良いと考えてC言語系のライブラリに乗っかるとして
C言語のABIはかなり古臭いわけで、あと、ヘッダファイルの存在がかなりエグイわけで
(windows.hをそのまま読み込める自作コンパイラとか書ける気がしない)
その言語で何かCのライブラリを使いたいときCヘッダファイルを適切に移植したのち
使いやすくするためにラッパークラスまで書くとしたら
これはもう多少気に入らない部分があってもC++を使ったほうが楽だし
ヘッダを移植するツールで自動生成する方針でも古臭いCのAPIを直接叩くのなら
何のための新言語か分からないし、だからといってラッパー書くのはバカらしいし
大概のCライブラリにはC++のヘッダも付いてることを考えるとそのままC++使ったｂﾙうがマシ
もしC言語のヘッダを直接読めるように言語を設計するとなるとマクロなども考えると
C言語と文法的に互換性が有るように言語を作らなければならないということで
これまたあまり作る意味が無い、というか多分C++
なんで、素晴らしい言語仕様を考えることは出来るかもしれないし
頑張ってコンパイラを作ることも可能かもしれないが
結局ライブラリをどうするのかという部分が一番の問題で
0から構築するのはあり得ないから何かに乗っかるわけだが
当然乗っかり先の制約を受ける
特にネイティブコード系は一番普及しているABIがC言語のソレであり
気に入らないのでひたすらラップしまくる日々か
諦めて次世代言語の機能を生かせずアンセーフとか言っちゃって直接叩くか
Wiｎ鯖で運用されない = Win鯖で使えない
だからな
リーナスが死んだら終わりな言語とかよく使えるな
どうでもいいが長すぎる文章は読まないからな。もっと要約して話せ
>>127 君の言っている意味がよくわからない。
言語？
>>128 今のリーナスは、リリース担当兼広報。
実際のリリーススケジュールとか開発機能とかは
スポンサーの企業が決めている。
リーリスリリースリーリリスリリリリリーリスリー
リーリナリリーナリーリリナリリリリリーリナリー
Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。
https://ubiteku.oinker.me/2017/12/02/skepticism-about-oo/ ブログ記事は信用しない
マウント取るためだけの批判の連鎖がよくあるんだと、フロントエンド界隈で学んだ
OCamlをやるとプログラム中でオブジェクト指向を使った抽象化が必要な場所はほとんど無いことに気付くよ
オブジェクト指向って抽象化なのか？
プログラミングで扱うのは本質的には「操作」だが、それは人間にとって抽象度が高く理解しづらい(と考えられていた)から、
仮想的なモノに見立てることで具象化したのがオブジェクト指向だろ
メモリとかハードウェアまわりを触るのが具象で
オブジェクトのような仮想的なものを扱うのが抽象だと思っていた
>>139 OCamlのOの意味を考えたことあるかい？
>>143 名前に入ってようがなんだろうが OCaml で 殆ど誰もOO しないのは端的な事実
正確にはocamlに文法として用意されたclass/objectを誰も使わないという話で、代わりにモジュールを使って抽象型も多態もするわけでそれはそれでOOの一種だとは思うな
関数型言語をやたら持ち上げてるけど
OSを関数型言語で書いてみてよ。それでバグか少なかったら関数型言語の優位性を認めるよ。
>>147 >代わりにモジュールを使って抽象型も多態もするわけでそれはそれでOOの一種だとは思うな
ぜんぜん違うから
だがそこから説明すんの面倒くさいのでもういい
>>148 >OSを関数型言語で書いてみてよ。それでバグか少なかったら関数型言語の優位性を認めるよ。
高水準言語でOS書けって頭悪すぎないか
Rustを関数型と認めるゆるい基準なら Redox がある
>>146 言語の糞さと、周りの人間が糞だからってことばかりで、全然説明になってないな
>>137 >マウント取るためだけの批判の連鎖
これなくすだけでよくなるプロジェクトって世の中に大量にありそう。
>>149 俺も書いてからしまった面倒くさくなる話やと思った
やめとこう
オブジェクト指向ってそんなにだめかな？
そのオブジェクトに対する操作をそのオブジェクトに持たせるってわかりやすくていいけど。
immutable.jsのレコードみたく、
メソッドは新しいインスタンスを返す関数と強制すれば関数型とも共生できると思うんだけど。
別に悪いってことはないだろ。
結局、状態や依存をどう管理するかって話なわけで、極論言い始める奴の
いうことなんて話 2 割くらいにきいてりゃいいと思うけど。
JavaScriptのようにハッシュテーブルとラムダを使う言語は関数型と共生できる
じゃあハッシュテーブルを使わない言語はなんで使わないのか？
その答えは、関数型とオブジェクト指向の対立とは全然関係ないところにある
まずデータをどれだけ圧縮できるか考えるといい
次に圧縮されたデータを展開する関数を作る
>>151 >言語の糞さと、周りの人間が糞だからってことばかりで、全然説明になってないな
はははははははwwww
ま、がんばれw
typescript使っててasync awaitが便利なんだけど煩わしい。
mapとか関数呼び出しを伴う操作で非同期処理に戻るのが、
たまにミスって放置しがち。
lintツールで指摘するなり監視する機能が欲しい。
先行してるC#とかはうまくやってるの？
ミスを指摘するしか能がない批評家に存在価値はあるのだろうか
>>164 ミスを作り出す無能に価値はあるのだろうか
何がミスなのかもわからず客が文句言ってるからで判断するバカ営業よりは価値がある。
This Woman Created a Programming Language with Privacy Baked In
Haskellの型クラスって凄く良い機能だと思うんだけど、地味に数学感足りないよな
NumってなんだよNumって。もうちょっと分解しろよって感じだ
Numeric preludeあんまり使われてないみたいだし
HaskellはStrictData拡張とStrict拡張が入った事で
実用的な次世代言語になる可能性が出てきた
型なし能なしのゴミ屑言語の何がいいんだろうな
ペチパーは論外、ルビーもガイジだわ
動的型付けというだけで別に型がないわけではないので注意
>>168 あれはSmalltalkってゴミ言語がヒントになった機能だからね
なぜ最初から高階多相にしなかったんだろう
自己書き換えもできないハスケルはプログラム言語と呼ぶに値しない
純粋関数型プログラム言語（自称）ハスケルw
Haskellは+や-といった演算子がNumに取られてるせいで
オーバーロード的なことが非常にやりにくいのが不便
<+>みたいな演算子は独自定義できるがなんかダサい
詭弁でもなんでもないだろ
静的言語の型こそまやかしだと思うが。
特にそれがただの「コンパイラだけが知っているメモリへの格納方法」である言語は、動的言語の型よりも型がないと言えると思うけど？
はいはいペチパーはPHPスレから出てくんなクソが
君の大好きな肥溜めPHPみたいな動的型付け言語に型はねーから
まあいくら静的型でも本物のコンパイラはこんな性格悪くないから気にするな
ここにいるやつはコンパイラの守護霊だ
動的でも静的でも最近は型は強くする方向にはあるかもね。
c とか perl に比べれば java でも python でも十分型を強くしてる印象。
真に型がない言語とはfortran77みたいな言語のことだと思う
PHPだとは言ってないのにな。
そもそもPHPと口に出すのこいつぐらいじゃね？
>>173 Smalltalkは自身がゴミ言語であるだけでなく
後世の言語にも負の影響を与えてるので
本当に害悪だな
>>185 はいはい
サボってないで早く保守作業に戻ってくださいね（藁）
型情報に限らず情報ってのは冗長な部分が省略される
省略したからといって必ずしも情報が失われるわけじゃない
皮肉も理解できないペェチピィコンパイラ並の低脳ガガイノガイがおりゅってマ？ｗ
>>190 型情報があるだけでなく情報を取得するアルゴリズムがある言語
アルゴリズムがあればモンティホール問題みたいに計算を間違えるやつが続出しない
>>186 多重ディスパッチ出来る言語が型なしってことはないだろ
>>180 君が型理論を知らないことはよくわかった
ばーかw
>>195 ぺちぱーがwwwwww
型理論をwwwwwww語るwwwwwwww
今年一番笑ったわwwwwwwwwwwwww
PHPをけなしてるだけのやつって、ほかの言語知らないから、PHPをdisって心の平穏を保ってる、可哀想なやつなんだろうな。
頑張れよ。
因みに、俺もPHPerは害悪だから滅びろって、思ってるけどな。
自己書き換えできるかどうかでプログラム言語と呼ぶかを決め奴がなんか言ってる
けなすってーかただの事実言うてるだけやん
ゴミ言語のペチプァ～さんは何をそんなに怒ってるだ今さら？
興味ない人間からすれば
いやもうわかったから。。
という感想しかない。
PHPをdisっても顔真っ赤にして反論してくるヤツが居ないからツマラナイ
PHPを必死に否定すること自体がよくわからんけどな。
そもそも作者が全部認めてるレベルのテキトーな言語なんだから、
PHPやってる奴ほど「そうだね、だから何なんだろう？」って思うような気がする。
よほど無念な思いをしたんだろうか。
型話の荒れかたが凄いな
静的型付けの言語は実行時前に型の整合性を検証し
動的型付けの言語は実行時に型の整合性を検証する
で、前者はRTTIを基本的に必要とせず、したがってわざわざ保持しないので
（とはいえHaskell含め多くの言語でトリックが用意されているのだが）
メモリ空間についてオーバーヘッドが減り、型検査も事前に済ませておいて
実行時にはしないので、速度についてオーバーヘッドが減る。
ていうか、トイ言語でもいいから動的型の言語の処理系を実装したことがあれば、こんなのは間違えるはずのない話でな。
ホットにパッチ当てたいとかそういうごく特殊な要求がある場合には
動的型検査の方が優位性を持つことがあるけど、そうじゃない場合で
（たとえばH-Mくらいの範囲内で）静的に型のつかないコード書く必要なんて
まあまず実際にお目にはかからないよね
だけどその程度のことは皆わかっててやってることだから
いちいちドヤらなくてもいいと思う
なんだかんだ言ってweb系はjava以外はphpかrubyが大半を占めてるんだから
静的言語最強とはならない気がする。
静的型言語の安心感には満足している、つまらないミスを弾いてくれるから、頭の弱い私にはぴったりだ。
動的型言語の「綴りミスも許さない」方針にはついていけない
それとも動的言語でも option explicit な使い方が可能なのでしょうか？
option explicitにしたとしても、variantで宣言したら無意味だよね、Dictionaryのキーにあらぬものを使ったら落ちるよね、ってところでゴタゴタ言ってる。
ホントに宣言してないレベルの変数アクセスは大体の言語の静的解析で見つけられるんじゃないかな。
PHPの$$変数とかは無理だろうけど。
テストは型検査みたいな静的検査と違って本質的に安全性を保証できないのでお門違い
型検査を有り難がるのはテスト書かないドカタだけって結論出てるけどな
お門違いの型の変数投げ入れて、
型エラー例外をトラップするようなテストかけばいいじゃん。
まあ手間なのはわかるけど、少しは頭使えばいいのに。
テストかかなくても、ソースを書いていること自体テストもかね、入力補完強化も兼ねるからいいんじゃないの？
それで動的型にする見返りがあるんなら良いんだが、何もないからなぁ
邪悪なことがしたい、以外のメリットが無い
少なくとも次世代言語の土俵に上がれないのは確かなので
このスレでミソカスな扱いになるのは仕方がないだろうな
サクッとプロトタイプとしてフロントエンド作るなら圧倒的に動的のがラクだけどね。
規模が大きいんなら確かに静的でないと厳しいかなと思うけど。
プロトタイプで作って流行ったら作り直すならいいけどね
規模大きくなっても使い続ける企業多すぎ
>>217 variant 型を使うなんて、まるで void * だけでコーディングしろ、と強要しているようなもの
型の恩恵を自ら捨てる選択には疑問、Java の嘘嘘 generics にしてもありがたいくらいだ
俺なんかは型を書くのがそんなに面倒か？と思うし
あちらさんは型のテストを書くのがそんなに面倒か？と思うのかもしれないが
仮に、この二つが同程度の面倒臭さだったと仮定したら
その時点でバランスしてしまってるわけで・・・あとはもう自明
ただこれは昔の話で、今は型推論も普及してるから、更に
シンプルに考えて、型のテストはどこかの段階で絶対にやらなければならない
避けて通れないものとしたとき、じゃー何処でどのようにやるかという事で
どうせ不可避なら静的型のアプローチの方が良いだろうとなるだけで
システムでサポートせず人力でテストするって方向はまるで
アセンブリのようで逆行しているわ
ただ、動的型付け言語の御大将は、あの lisp 族だからな…奴らには勝てない…
Land of lispにHaskellのが良いって書いてあるから静的片付けの勝ち
ローカル変数→型推論があるので型を書く必要はない
公開関数などの型→動的型付けでもコメントなど何らかの形式で型を書くので静的型付けだから書かないといけないという事はない
よって静的型付けの勝ち
型でコーディングは出来んし、証明でビジネスは動かん
結局きちんと動くものをいかに速く作るかってだけの話だろ
本当に静的型が「きちんと動くものを速く作る」ことができるなら、とっくにYesodがRailsを駆逐してる
そうじゃないってことはRailsの方が、強い動的型の方が優秀なわけだ
まあPHPみたいな弱い型付けの言語は論外だが
Railsなんて駆逐されるほど使われてるの？
Google、Microsoft、Amazon、Facebook、twitterなど、有名な会社で使われてるのを聞いたことないが…
正直技術力のないベンチャーが使ってるイメージしかない
rust は別に好きじゃないんだが型に関するアプローチに関してはいいと思う。
関数の引数では型を気にするけど、内部は型推論で暗黙的に設定されるっていう。
>>227 Option Explicitとはその程度のもの。
あと、Variantを器用に使ってるシステム見たことあるぞ。
バカとハサミは使いよう。
>>233 初期のTwitterはRailsだぞ？
顔本はPHPだ
>>236 脳内でHaskellとRubyに対応付けてくれよ……
>>237 Railsなどという負債を抱えていたいい例やね
>>237 いや知ってるけど、それはその2つが駆逐された話じゃねーかｗ
twitter は erlang に移って、その後やっぱ性能出ないから他のにしたって話じゃなかったっけ？
こうみると言語にこだわるのは技術力のない証拠に思えるけどね。
まあ十分な技術力があればJavaを使うからなｗｗｗ
goroutin は意外とリークがめんどい、
erlang の軽量プロセスはそこまで性能が出ない
scala の互換性はひどすぎる、
では、この領域をカバーする言語は？
ってのはあるかもね。
同期的にかけるasync awaitの良さを知ってから
gorutineもしんどくなってきたわ。
見た目命令順になるのが一番分かりやすい
>>246 デバッグとスタックトレースが難点だけど、メリットの方が大きいからお世話になってます
元からイベントの投げつけ合いで書いてたからどっちも便利だと思うけどな。
lambdaの中にlambdaを書くのを繰り返すと大量のインデントと括弧が出てくる
インデントと括弧が不要になるのが一番重要
>>249 それって Python 限定の話だろ
Python は公式ドキュメントで関数型プログラミングには不適切と
表明しているくらいなんだから、それくらい我慢するのが Pythonista だよ
コールバック地獄は何故地獄かって話だからPython限定ではないと思うが
>>249 引数とかにlambdaを直接書くスタイルはそれが苦にならない人達がやっているだけで、
それが読みにくいと感じるならフラットに展開しちゃえばいいんだぜ？
Promiseやasync/awaitでcallback地獄解消なんて書いている記事の大半も
本質的な部分はこっちだったりして。
ただ
>>246の言うように上から実行順に書けるというメリットはある。
コールバック地獄は、JS の、co, Koa などのジェネレータランナー。
iterator, generator を使ったもの
yield Promise.all
みたいな書き方
try{
yield Promise.all(非同期の並行処理)
}catch(err){
}
ジェネレータランナーは、非同期処理を同期的に書けて、
非同期処理を、try/catch できる
Promiseは何度も帰ってくるものや、一度も帰ってこないかもしれないものが書きづらいんだよなぁ。
名前の通りだから仕方ないんだけど。
Promiseとawaitで解決できるのはcallbackを使うものの中でもとても限定的なパターンだと思う。
無いよりマシだけどね。
コールバック地獄は慣れれば天国だろ。
実行速度もコールバック地獄のほうがプロミスより速いしな。
>>257 おう、高級言語よりアセンブリの方が速いし一生アセンブリ使っとけよ
>>256 何度も返ってくる物:rxjs
一度だけ返ってくるもの:Promise+async/await
>>259 借りてきすぎて統一感ゼロ。
いっそコールバック書くか、全部イベントでこなすかや全部rxか、全部Reduxのほうが潔い。
awaitで延長される変数のライフタイムが勿体無さすぎる。
>>258 そういう世界もあるので一概に笑えんし、少なくとも取ってつけたで満足して「これがあるから問題ない」と開き直るよりは、
コントロールを保ってモノ作ってると思うけどな。
ポリフィル(笑)
rxもかなりめんどくさい。概念はシンプルなのに
操作メソッドあんなにいるもんか？って思うわ。
Advent見てても人気ねぇし、Rxは流行らんな。
>>216 >動的型言語の「綴りミスも許さない」方針にはついていけない
変数宣言省略と動的型付けをごちゃ混ぜにするような人はプログラムしないほうがいい
>>216 >動的型言語の「綴りミスも許さない」方針にはついていけない
変数宣言の有無と型付けを区別できない人はプログラム書かないほうがいいと思う
>>216 >動的型言語の「綴りミスも許さない」方針にはついていけない
変数宣言の有無と型付けを区別できない人がプログラムを書くのは型エラーです
大事なことなので3回書きました
>>223 >それで動的型にする見返りがあるんなら良いんだが、何もないからなぁ
>邪悪なことがしたい、以外のメリットが無い
こういう人って
邪悪なことって具体的にリストアップしてよ
と言うと二度と帰ってこないw
>>262 適材適所なのかなぁ。
目下の問題を解決するためにこうなっちゃいました、いい感じなんで標準クラスにするべき！に見える。
どーせwebworkerとかserviceworker、webdsocketにイベントの投げ合いなんだし、もとのようにイベントで制御するのが一番に見えるけどな。
一度きりならonce、何回も呼ばれるからon。
eventEmitterってブラウザでも使えなかったっけ？
無けりゃそれぐらい書いても良いけど。
動的型付けの恩恵を一切受けないコードを書くなら
動的型でも型推論で補完が効くし、
補完が効かないなら動的型の恩恵を受けるようなコードを
知らないうちに書いてるってことだよ
なんでもガイジというか、ガイジがいっぱい沸いているだけ
同じ人間でも脳の構造の違いにより考え方が全然違う。
つまり生まれつき脳の仕組みが全く違う人達がいる。
仕組みが全く違うというのがもし本当なら
速度のみを測定するベンチマークが信用できなくなる
だから仕組みは同じで速度だけが違うと考えるのが無難である
>>272 rxはSubject使い始めると一気に邪悪化するからな
型があれば解決するかのように思ってる人が生き方を改めてほしいな。
実際問題、それだけに頼って地雷踏んだときはコアダンプ読む型なんて飾りですみたいなオッサン呼ぶ事になるんだし。
だがそれは型による静的検証をしない理由にはまったくならない
別にやればいいじゃんとしか言いようがない。
大抵糞どうでもいいキャストを付け加えるどうでもいい作業に時間を追われるだけだけどな。
静的型があれば全て解決するとは誰も言ってないが
動的より良いというだけだぞ
そらフレームワークに乗っかって用意された関数を呼ぶだけのドカタには
静的型の制約なんて関係ないだろうね
メタプログラミングなんてした事ないでしょ？めんどくさいよ静的型だと
こいつ相手をドカタかつメタプログラミングをしたことない奴と決めつけて何がしたいんだ……
なんで静的型のほうが動的型より良いって前提で話を進めるんだこいつらは……
そんなに静的型が好きならYesodでRailsレベルのシステム構築してみろっつーの
そんな面倒なこと要求するならお前も何か動的言語でRails並のもの実装しろよな
静的型なら動的型より生産性高いって主張してる側が実装しろよ
なんで実証をこっちがやんなきゃいけないんだよ
実証責任を押し付ける上にテーマまで押し付けんなよ
テーマ量子化学で良ければ無限に実証してやるがやるか？
静的型の言語はいちいちキャスト書いたり無駄にコード量がかさむ抽象クラス書いたりしてコード当たりの生産性低くなるし
メタプログラミングがかなり面倒になるしで、動的型と比べて工数が倍以上かかる
型チェックで検出できる程度のエラーなんて単体テスト書きゃ確認できる程度のモン
テスト書きたくないクソプログラマ未満には魅力的に映るんだろうがな
>>295 ってこっちは主張してて、その実例として、RailsとYesodを提示してる
静的型を優位に推したいなら、逆の事例でも提示してみろって話だ
動的と静的は兄弟のようなものでお助けあっていきているんだね。
おぅん？
なんだその妄想。静的型でもテスト書くぞ
それにJavaじゃあるまいしちゃんと書いてりゃキャストはいらんしょ
メタプログラミングはともかく、その二つは言語の問題じゃない
言語の問題じゃない所を挙げて優位を主張すれば良いなら
↓みたいなこと書けばいいのか？
動的型は引数の型情報をちゃんと書かないから人のコード読むのめっちゃしんどくて生産性が低くなるし、テストが足りずにいざ動かしたら意外な所で引っかかるボケコードも存在する（しかも型があれば引っかからないような所）
いちいちクラスのメタ的なマニアックな機能を使って書いた本人以外の読解がそれなりにしんどいコードにして拡張性を下げたりし始めるし
コードを読む時間が倍以上かかる
実例としては動的型付けとしてaseとpyquante、静的型付けとしてvaspとbigDFTでも提示しておこうかな
こんな感じでええんか？
挑発に乗って色々滅茶苦茶書いたものの実は俺は静的信者では無かったりする
>>298 コードリーディングの過程で型情報がほしいって言うのは一理あるな。そのために間違った方のハンガリアン記法使うのもアホ臭い
ちゃんと設計してればキャストはいらないっていうのは、静的型言語では整数と浮動小数点数の組み合わせで四則演算すらできないって問題がある。OCamlがわかりやすいな
これを無理矢理できるようにHaskellみたくNum型クラスみたいなのを導入するとオーバーヘッドがかさむ
テストについては、結局型が通るか通らないか程度はテスト書く過程で見れるだろって話で、きちんとテスト書けばその程度の差は優位性にはならないんじゃないかってことな
そりゃテスト書かないと静的型でも動的型でも壊れたコードだ
>>300 ＞静的型言語では整数と浮動小数点数の組み合わせで四則演算すらできない
いまどきの静的型付け言語でそんなものがあるのか？静的型付け言語の意味をわかっているのか？
Scalaはこの問題を暗黙の型変換で対応してるが、これはこれで闇を醸造してるよな
演算子オーバーロードを嫌う人がいるのは事実
演算子オーバーロードすると実行時にオーバーヘッドがかさむというのは嘘八百
組み込みの数値型は自動変換する言語が多いし
静的・動的と関係ないね
>>288 そうでもなかろう。
蛇足という言葉もある。
生産性ってのはもう少し厳密に扱われるべきだと思う。○○の場合は、とか。
>>300 間違ってない方のハンガリアンならば、型なんてどうでも良いと言う事もわかると思う。
ユーザ定義型に出来れば言う事無いけどね。
>>307 そうだな。正しい方のハンガリアン記法なら、静的型のコンパイラに頼るよりはるかに健全な運用ができる
別に静的型でもやりゃいいと思うが、コンパイラに頼るのに慣れると面倒に感じるのかね？
静的型でチェックできることは、単体テストを書く過程で自然とチェックできる
静的型のチェックにより、メタプログラミングが書けなくなり、本質的でない型合わせのための余計なキャストも増える
結局この二点なんだよな
可読性についてはまあわからんでもない。正しい方のハンガリアン記法でも、接頭辞の管理はコード上にないからな
IDEのサポート込めば確かにリーディング速度は上がると言える
>>309 ＞静的型でチェックできることは、単体テストを書く過程で自然とチェックできる
逆だ、
単体テストでのチェック内容の一部は、テストを書くまでもなく静的型でチェックできる、だ
テストを書くまでもなく、成果物の品質を一定のレベルまで引き上げるのが静的型の特徴だ
メタプログラミングはそれようの総称型を使えばよい
本質的でないキャストは総称型（ジェネリクス）で基本的に全廃できる
>>311 ＞テストを書くまでもなく、成果物の品質を一定のレベルまで引き上げる
だからって単体テスト書かないって訳でもなかろう
その単体テストを書く過程で型検査などは自然とテストされるということ
型チェックをテスト書かない言い訳にするのはそれこそ最悪
ジェネリクスで不要なキャストが撤廃できるなら、それはそうなんだろう
上で挙げた四則演算問題がジェネリクスでなんとかなるとも思えんが
>>311 ジェネリクスをきちんと使えばキャストはほぼ全てなくせるが、
メタプロはジェネリクスだけじゃどうにもできないだろ。
あと、ジェネリクスとC++のテンプレートは似ているようで全然違う。
メタプロに関しては動的言語のほうが簡単なのは事実。
ただ、本当にメタプロが必要になるケースになんてあまりないと思うんだが。
>>312 別にテストを書かない言い訳とかじゃなくて、
静的型なら動的型に比べてテストを書く量を減らせるということだろ。
テストを全く書かなくなることはないけど、テストの量を減らせるというだけでも
そこには立派な価値があるということが言いたいんだ思うが。
>>315 たぶん
>>300の
>静的型言語では整数と浮動小数点数の組み合わせで四則演算すらできないって問題がある。
てやつのことだろ。
それって、単に言語の性格の違いのような気がするんだが。問題と呼ぶほどのものか？
走らせないとわからないテストより前に、コンパイルでエラーが検出できたほうがいいやろ
テストについて一から勉強しなおしなさい
静的型と動的型の対立をいくら勉強しても新しい発見はない
次世代の静的型を考えてるやつらは現在の静的型と対立するのだ
静的型と静的型を対立させる
どっちが勝つか全く予測できないから全く新しい成果を出せるのだ
コンパイラがバグもなく絶対的に正しければな。
コンパイラにそこまでの期待を背負わせた結果がc++の現状なわけだ。
ユーザーの仕様要求にはぼろくそ文句言う奴に限って、
コンパイラに理不尽な要求してる奴が多いってのはほんとなんなんだろうな。。
>>317 コンパイルだって走らせないと動かないとおもうんだが
結局テスト走らせるのもコンパイル経由するんだからかわんねえだろ
>>320 かわるねえ、テストはテスト書かなければならないし、すると書いたテストが間違っている可能性も否定できない
コンパイル時の型チェックは、つまるところソースの矛盾をつくのだから、それだけでソースの検証になりうる
ただ、型情報はコンパイル結果には含まれないのが普通だから、いうなれば無駄を書いているわけだ…
>>321 結局「型チェックあるからテストの手が抜ける」論者か。話にならんな
>>322 それはお前の思い込み、テスト不要とはひとこともいっていないだろう？
動的型付け言語でメソッド先頭に引数型チェックをずらずら書いてるコードを見た時は心底アホだなと思いました
>>322 その言い方は「手を抜く」ことに関して批判しているのように聞こえるな。
プログラマなら手を抜くことに積極的なのはむしろ褒められるべきことだと思うが。
手を抜かないことを美徳とするなら伝統工芸の職人さんにでもなれば。
少なくともそんな考え方をするような人間はプログラマには向いていないよ。
>>324 そんなに自分のバカさを自慢しなくても…皆よくわかっているから
>>300 javaの場合はクラス間のキャストと整数、小数間のキャストが同じ構文だから分かりにくいけどあれ全くの別物だから
後者はどちらかというと関数に近い
例えばStringをObjectにキャストしても変数の値(=メモリアドレス)は変わらない
でもlongをdoubleに変換したら変数の値自体が変わる
これは大きな違い
静的型付けでもテストはいるけど数を減らせる
わざわざ機械がチェック出来る事を人がやる意味は？
あとオーバーヘッドどうのこうのって動的型付けの方がオーバーヘッドでかいやん
>>324 いや、それが、Java の本番コードでは執拗な null チェックはかかせないようですよ、はじめてみたときは目をうたがったな…
>>328 静的型はより少ないテストデータで同等の品質を確保できるという実証データはある？
>>329 今時NotNullアノテーションで対応するけどな
>>330 説得力のある実証データはたぶんないだろうな。
だが逆説的に、動的型でも静的型と同等のテスト量で同等の品質を確保できる
という実証データがないだろうこともやはり同じだ。
「型付け」と「テスト量と品質」に関係性は「あるかもしれない」し、「ないかもしれない」。
そのことについて議論する価値はあるかもしれないが、
説得力のある実証データがないことが静的型付けを批判する理由にはなり得ない。
ちなみにあまり説得力のない実証データなら腐るほどある。
何故それらに説得力ないかというと、
テストの品質というものを正確に数値化できないからだろうな。
つまり、品質を正確に数値化する方法がない限りはそのことについては誰も実証はできない。
まずは品質の数値化について誰もが納得できるような方法を考えることからだ。
そして、それが簡単にできれば苦労はしていない。
静的型と動的型の言語で、同程度の品質を担保するために必要なテストの量が変わらないと仮定するなら、
メタプログラミングのしやすさとコードリーディングの難易度を天秤にかけるだけの話になりそうだ
キャストについては、さすがにGoのinterfaceやらJavaのObjectは別として、それが本当に「本質的でない」場面があるとはどうしてもピンと来ない
上で例に出されてるOCamlの浮動小数点数と整数の演算だって、本来この2つを四則演算した結果が
浮動小数点数になるか整数になるかは本来非自明だから、どっちかに明示的に型を揃えろっていうのは
静的型動的型関係ない問題だと自分は思う
メタプログラミングについてはこれももう出てるけど、本当にそれが必要かって言われるとなあ
確かに記述量自体は短くなるけど、間違いなく可読性とトレードオフになる
「ノコギリと刺し身包丁の優劣」みたいな無意味な話はつまらん。
メタプログラミングみたいなのは型システム関係なくunsafeみたいな感じで一部分に閉じ込めて使うのが普通だからな
最近は、Pythonでも型アノテーション書くようにしてるよ。
見返した時に、コメントで型情報を書くよりは
楽なんで（；´∀｀）
>>340 静的型でもあり動的型でもある不思議な言語
TypeScriptは静的な型検査をしたいから作ったんじゃないんか？
新しい言語の新しい議論でもあるのかと思って開いてみたら
20年前くらいの動的vs静的の罵り合いしかなかった
5ch死んでるな
そう思うなら貴方にはこのスレは向いていなかったのでしょう。どうぞ卒業なさいませ
>>334 >説得力のある実証データがないことが静的型付けを批判する理由にはなり得ない。
完全に同意するし、同様に、
説得力のある実証データがない以上は動的型付けを批判する理由にはなり得ない。
と思うね。
説得力のある実証データが無いとは限らない得ない。
発見されてない可能性のあるものを存在しないと断定し得ない。
>>347 信頼できる具体的なデータを出してから出直してきな、ばーか！
信頼できる具体的なデータがないことはなり得ない。
完全に同意するし、同様に、
信頼できる具体的なデータがない理由にはなり得ない。
そういう白いカラスを探すような真似をせんでも。
動的静的、どちらも良いものだし、どちらにも反対側に寄せるような機能も今時はある。
そういう意味では「静的型付け言語だから間違いが少ない」と言う発想は明後日というか「間違うなと言うだけの話」として扱われても仕方ないっちゃ仕方ない。
今まで一回もキャストやポインタデリファレンスを使ったコードを書いたことがない奴だけがギリギリ石を投げても良いと思うが、そんなやつはごく少数だろ。
チェックが厳しくなるのは良い事だが、それがないと物が作れない(はず)なんて言うのは補助輪付きの自転車を指して「これが至高の自転車だ、なぜなら倒れないからだ！」って言うのと同じくらい暴論。
そういう奴がRustのコンパイラにバタバタと倒れていくのは至極愉快だけどな。
最初からそれぐらい考えて作っとけよ、と。
数値を引数にとる関数作ったら
境界値やゼロ値をテストするのが静的型
数値文字列オブジェクト思い付く限り全てテストしないと発狂するガイジが型無し池沼
こういうことでしょ？
>>352 境界値やゼロ値をテストするコード書けば、文字列オブジェクトが入ってきたらエラーになるから
動的型でもそんなテストは必要ありません。
そんな当たり前の事も分からないなんて、君は本当に低脳だな。
逆の発想でしょ。
数値以外で呼んでなけりゃいいんだから、呼び出し箇所で引数が数値と推論できなければエラーにしときゃいいじゃん。解析上で。
仕様として数値しか取らないなら、数値に対するテストで十分でしょ。
静的言語でも数値以外を渡す方法が無いわけでも無い。程度論。
静的言語でもヒステリックなチェックが必要な案件もやっただけに、ホントに夢見てるんだろうなって思うわ。
引数を手当り次第にチェックする、という解法しか出て来ないのがそもそもキチガイじみてる。
スタックもメモリも疑え、みたいなプログラム書いたこと無いんだろうな。
>>356 おまえはまず自分がバカであることを自覚しろ
話はそれからだ
型無し能無し糞バカパーエッチパーのバカがなんだって？
早く10年熟成のウリジナル社内フレームワーク保守する作業に戻れよ
どーやっても無関係のPHPをけなしたいんです！
というある種の精神的ハンディキャップを持ってるみたいだから仕方あるまい。
考えてみたけど、むしろPHPの問題は型があったとしても多分変わり無く問題としてあり続けると思うな。
QCやると
>>335は痛感するがな。
品質保証しなかった物が万一起こす損害と、品質保証したから避けられた損害はイコールじゃないし、
品質保証してしまった時点で、避けた損害の計上は机上の空論になってしまう。
避けるも何も起こらなかったんじゃないの？と過剰な心配とみなされがち。
起こっていたに違いない、と言うのは確かに空論だからな。
「改善できている品質」自体を点数化(そしてある程度これは王道もある)しても、「改善しなかった場合の品質」が見積値のままなので、恣意的と言われても仕方が無い。
同様の問題にコストカットもあるが、これも最初から織り込んで当初目的を果たしてしまうと話がややこしくなる。対費用効果が品証と同様に、実績値と見積値の比較になる。正しい比較じゃないのは確か。
一番、営業部や企画部や、ことによると開発部とも喧嘩になる数字。
なので、これに関して実証値を出せと言うのは、同じ事を、2つの方法で、全く同じ能力の人間が、二の轍を避けるというバアイスをかけないために初見で行った場合、の数値を出せと言う、無茶苦茶な要求になる。
パラレルワールドが発生してそれが一つの状態として観察出来る神が存在しない限りイチャモンのつけ放題。
要は無意味。
バイアスがどう間違ったかバアイスになってるわ。以外に読めるもんだな。ごめん。
>境界値やゼロ値をテストするコード書けば、文字列オブジェクトが入ってきたらエラーになるから
それをテストで確かめるんだろうが
>>360 当たり前やン
PHP7になって型サポートが入った！！とか嬉ション漏らしてるペチパー見て
心底あの界隈のレベルの低さに辟易した
>>364 そこなんだよなぁ。
>>353は、動的静的どちらでも同じようにテストを書くことになるんだから
「結果、テストを書く手間（量）は一緒だろ」と言いたいんだろうが、
型については「テスト時に確かめるのが動的」、「コンパイル時に確かめてくれるのが静的」という違いがある。
「テスト時だろうがコンパイル時だろうがきちんと確かめることには変わりないんだからいいだろ」
という意見が動的派の主張のような気がするんだが（俺の勘違いだったら指摘してくれ）、
個人的にはテスト自体にバグが含まれる可能性があるという点で違うので、静的のほうが好ましいと思う。
コンパイラにバグがない保証はないがその可能性はかなり低いし、
まして、どこの誰が書いたかも分からないテストと比べればどちらが信用できるかは明らか。
静的でもテスト自体にバグが紛れることはもちろんあるが、型についてはコンパイル時にチェックされるので、
型チェックだけに焦点を絞ってみれば、やはり静的言語の方が信頼性は上だろう。
>>365 すごく良い意見だと思う。
そもそもテストがあるのは人間は間違えるからというのが前提だからで、
そしてそのテストを書くのも人間なのでテスト自体も間違えている可能性がある。
それでもテストを書くのはチェックによって間違いを完全になくすことはできなくても
ある程度まで減らすことはできるという考えがあるからだろう。
そして、その考え方でいくとテストを重ねれば重ねるほど信頼性は上がるということになる。
つまり、テストのテストを行えば2重チェックとなりさらに信頼性が上がることになるが、
テストのテストを書くというのはあまりにもアホらしいので普通そんなことはしない。
つまり、通常のテストでのチェックは1重のチェックまでが限界となる。
それに対してコンパイラはコンパイラ自体がしっかりとテストされている。
つまり、コンパイラによる型チェックは言い換えればコンパイラ自体によるチェックと
コンパイラのテストによるチェックの2重チェックを同時に受けていることになる。
この考え方でいけば、ただのテストは1重のチェックだが、コンパイラによるチェックはそれだけで2重チェックとみなせる。
つまり、コンパイラによるチェックのほうが信頼性が高いということになるはずだ。
一応理論はしっかりと通っているはず。
自分で書いといてこんなこと言うのもなんだが「なんだかこじつけな気がして、あまり気に入らない」。
誰か論破してくれ。
コンパイラにバグはないとかさ。。
とりあえずvcを一通り使ってみてから言ってほしいな。
浅はかすぎる。
まあしかし静的チェックと動的チェックを両方やるならいいと思うよ。
これは結局、仕様と実際の動作のどっちもしっかりチェックする必要があるってこと。
一般的な話をvc固有の問題で批判する方が浅はかと言わざるを得ない
型も書けないような奴が
正しいテストを書けるだろうか？（irony）
それ以前に、めんどくさいからって型書きたがらないような奴は現実にはほとんどテストなんか書いてないんだよ
動的型でテスト書けば問題ないだの必要なテストが増えるだのテストの正しさだのというのははっきり言って机上の空論
そもそも彼等はテストを書かない
そんなこというと、動的型付け言語を使っているから型を書いていないって人より
auto/varを使って意識的に型を書かない人の方がテストを書かない傾向があるって
言っているように聞こえるけど。
>>373 そりゃ静的型でも型書かない奴は山ほどいるだろ
テストを書いているということを議論の前提にしていることが全くもって非現実的だと言ってるんだよ
テストの目的は実装のバグを探すことだけか？
むしろ仕様をチェックすることが最も重要だよ
バグは直せばいいだけだが、仕様はうっかり変更されたら直せない
死んだ人が帰ってこないのと同じ
動的型の言語仕様を捨てて静的型に移行するのが難しい理由もその辺にありそうだ
テストすら正しく書ける気がしないドカタにはメタプログラミングなんて無理
>>375 テストの目的は変化を検出することだよ
作って運用開始して終わりならテストなんか手動で十分
>>366 それもまぁ程度論だろ。
一部の人間があったら良いなと思ってたものが出来たから嬉しいってだけの話で、
全体に対してどうと思うほうがちょっとおかしいよ。
テストのテストを馬鹿にしてるが、書くからな。
何重まで上に上がる？というのは論点がずれてて、要件定義書でテスト仕様書をテストする。(詳細設計なんかは無視する)
紙の上でかもしれんし、直交表書くかもしれんし、色々あるが、
要件定義や詳細設計からテストだけ書いて、その妥当性も判断せずにオールグリーンこれでオッケー、ならそれは間違ってると思う。
間違えない前提ならテストは要らない、はその通りで、どの開発レイヤにも「この場ではこれは間違っていないとみなす」というブラックボックスがある程度発生していく。
単体試験なんかで担保して、レイヤがあがるにつれてブラックボックスは増えていく。
そこにワザワザ、ヒステリックテストをする必要は無い。
ブラックボックス側から数値しか出さないなら、数値以外をチェックするのは過品質に近い。
>>367 細かくいうと「結局製品として必要な質を担保するのに必要なテストコードは変わらない」っていう主張な。少なくとも自分はこう思ってる
あくまで主観だし定量的に示せないんで上で上がってる通り空論といってもいいがな
少なくともコンパイルとLinter通った時点での品質は静的型が上なのは否定しない
が、自分の経験上、型チェック程度は他のテストのついででチェック進むから、そのせいでテストコードがかさむとかそういうケースはそうそうないはずなんだよな
もちろん「テストコードと、一種の証明である型チェックの性質は違う」とかそういう理屈も理解してるが、
結局「製品としての質担保」という観点で見るなら、その程度の手段の差は全くもって関係なくなる、というのが自分の考え
この辺はテストに求める役割に対する考え方の違いかもしれん
あとPHPディスに絡めようとしてるやつがいるが、PHPは静的型動的型の以前の部分に問題があるし、
この議論で少なくとも自分が動的型言語の念頭においてるのはPythonやRubyだからな？
>>368 論破じゃなく、補足になるが、特に業務でプログラミングするならコスパ考慮して選んでるからねえ。
現実の工数は、要件変動も含めその時点でのコンパイラ・インタープリタで拾えない部分の不整合によるものが大きい（まだ合理化されてないとも言えるが）。
プログラミング言語の歴史見ると判るが、静的・動的とも互いに相手のいいところを取り入れて進化してきてる。
同時に、世の中のニーズ（個人が計算リソースを持つようになった、など）に対応した形でも変わってきている。
これは適用可能な領域を広げようとした結果。
オレ個人の例で言えば、業務要件＝＝＞計算モデル＝＝＞候補言語を複数選択。
その後、プロジェクト要件（期間、要求品質、メンバースキル、関係者が蓄積しているプログラミング資産など）との組み合わせが適しているものを勧めている。
なので言語仕様やライブラリ含めた挙動だけ比較しても、それはツールとしての現在の瞬間の姿を見てるだけなので、その評価が未来にも、業務にも適用できると考えるなら早計。
>>380 静的型が上というか、帳尻があっている、と言うことはわかるから、一つの方向としては正しいと思う。
ただ、本当にあっているか？小数は桁落ちしてないか？まで考えると、静的型でも、どの道ピアレビューなんかで担保するしかない。
これは言うとおり、ついでに型が充分かも見る、という動的言語のピアレビューと工数としては変わらん。
静的型のメリットで最も大きいのは依存関係が静的にほぼ完全に把握できることでしょ
自社事業の開発で常に動いているものを弄るなら、これ以上に心強いものはない
依存関係はどっちでも同じ程度じゃないの？
RoRみたいに、そのディレクトリに置いたら勝手に使用される、を想像してたら違うのかもしれんけど。
動的型も静的型も、リテラルでのimportやrequire、参照設定とusingでそれなりに決まる部分もあれば、
Node.jsだと変数でのrequireや、CなんかでのLoadLibraryなんかでも動的ロードなんかで全く決まらん事もあるんだし。
依存関係の解決はちゃんとそれ用に何か用意した方が良いと思うけど。
モジュールの依存関係は型と関係ないね
「モジュール＝型」とかいう超怪しい等式に依存するのは嫌だね
テストコードはテスト対象のコードより明快なものが一般的で、明快であれば人の目で判別しやすいってのも考慮すべきよ
テストを重ねるほど品質が上がるってのは空論だし、1重しかテストしないのは妥協してるからというわけでもないよ
>>386 IDEのメソッド呼出元の検索とか使ったことないのか？
規模が大きくなるとあれがないとやってられなくなるぞ
>>368 形式手法でコード自動生成しててもやっぱり高信頼性のためにはテストは必須だぜ？
>>389 なんだ、そんな事か。長々書いて損した。
動的言語のIDE使ったことある？
いや、IDEじゃなくてもいいや。VSCodeと適当なNode.jsのプロジェクトでさえ、それなりに効くだろ。
>>388 テスト自体は1重でも良いとして、何らかの方法でテストの正当性は担保しないの？
それじゃただ書いたコードが書いた意図どおり動いてる確認で、意図が正しいかのテストにはなってない気がする。
意図が正しいかの証明は要件定義と設計書の間でのみ行われる、ってのが普通なのかな。
要件に寄らず、テストは最低8重ないとダメ
スレのレベルが低すぎる……��♂
>>389 良く訓練されたPHPerは超力Grepを使いこなすから問題ないんだよなぁ
メソッド呼出元検索、、今回ほど仕様バグが沸き起こる思いをしたことが無い…
>>391 > 意図が正しいかのテスト
って何だよ意味不明。
必要なテストがされているかが重要だろ。
数だけ多くたってダメなんだよ。
つまり、動的型言語は山ほどテスト書かないとダメって言いたいんだろｗ
一応確認なんだけど動的言語じゃなく動的型付け言語の話なんだよね？
>>399 強い型付けの動的型言語なら、値に対するテストを書けば型に対するテストは不要です
assert(x > 0) というテストを書いたのに、さらにxが文字列かどうかテストする必要ははありませんね
反論するなら反例を出してくださいね
クソくだらない長文はいらないので
>>400 型ってのを、CPUのプリミティブでしか考えなくて良い業務プログラムならそうだな。
問題は、今時そんなトイプロジェクトが少ないって事。
>>402 つまり、幽霊型とか依存型あたりを使い倒さないと今時のプロジェクトはまわらない、という認識でいいのか？
そりゃその辺りを使い倒さないと回らないプロジェクト前提なら、動的型付けでは無理な話になるが
それが必須な状況が、動的型付け言語のメタプログラミング並みに思い付かないぞ
>>400 用途による。
弱い型付け言語でも、型無言語でも値に対するテストで充分な場合もあるし(要は、不正値が渡されてる時点で異常であって、その場合の動作は不定として構わないという要件の場合。よくある)
逆に強い型付け言語でも、強い磁界やノイズ源の間際で使われるようなものを書くときにはキチガイじみたテストもする。
a=170,b=85,a+b==255みたいなアサーションすら稼働コードにも並ぶし、それが成立しなかったらリセットかかるようにする。
ちなみにvscodeでnode.jsのコード補完が効くのはtypescriptの型情報の恩恵を得てるから
>>404 むしろ動的型付けの出番が増えるけどな。
昔ながらの単純なOAアプリには不要だが。
>>405 長文書かずに反例を出せ、って書き込みにアンカーつけてまで
反例無しの長文書いててワロタ
具体例がなくても、長文を書けば何か言った気になれるからなｗｗｗｗｗｗ
>>404 幽霊型や依存型って動的型付けなら普通にコードでやっていることを
静的な型で表現しようとしてがんばってる例のあれのこと？
>>410 >静的な型で表現しようとしてがんばってる例
まあそういう事になるよね。
もともと計算モデルが違う（＝問題解決へのアプローチが違う）
プログラミング言語同士を比較すれば、「一方は率直に実装できる」
フィーチャーが有るのは当たり前だしね。
理想はプロジェクト毎に最適の計算モデル、言語、スキルを揃える事だが
現実には、そういう要素が有ることを知らなかったり、教育投資を捨てたく
ないって理由で、合っていないモデルで無理やり進めてるのが現実。
>>400「強い型付け言語である場合、値のテストをすれば型のテストはいらない」
>>405「弱い型付け言語でも型のテストがいらない場合がある。また、強い磁場中の利用であればa=170,b=85,a+b==255のようなキチガイじみたテストをする」
あガガイのガイ
>>410 動的型で項書き換え最適化や実行前の証明が普通になされているというなら、まあそうだね
うん、反例の一つかと。
～あるし、～する(こともある)。
前者は言う通りにそれ以下のテストだけど、後者は型テストももちろんするし、その周辺のメモリの値すらテストする、って事なんだが。
カナリア知らんとかはやめてくれよ。
次世代で証明されると期待される定理を今使う
クレジットカードみたいなやつ
動的型付けってそういう仕組みなんだね
ID:9wTQQ92p
こいつくせえな話が通じてねえ
例のガイジか
通じてないのはそっちだと思うけど。
理解できければ全部レッテル貼って理解を放棄するクセはいかがかと思うが。
人に理解してもらえることが当たり前だと思ってるようでは人生経験浅すぎるな。
現実とはそういうものだよ。
そこまでは言ってないがな。
まぁ、どうおかしいか理解させられない時点で同じ穴の狢かそれ以下なんだろ。
理解させる、という側の能力だけを評価するなら。
そこまで卑下しなくても良いのに。
>どうおかしいか理解させられない時点で同じ穴の狢
あDHDには何回か丁寧に説明してやったし、その度に「そういうことか。理解してなかった」って言われて来た
もううんざりだ。おまえであることがわかった以上もう説明せんよ
「AならばB」に対して「Aでないときには～」って話をして
反例になってると思う
>>415ってプログラマとしてヤバない？
ヤバい人がいても最近は誰も批判しない
批判は建設的じゃないと考えられているから
>>424 それが実現すれば理想的なんだが現実はそう上手くはいかない。
こんな会話が発生している時点で建設的じゃない批判が起こっているという悲しい事実。
現実もほったらかしにしてるわ。
だからまともにテストのないコードがあちこちにある。。
暗黙的な静的型付けが主流になると思う
頭の良い人間が多相を明示的に駆使して必死に辻褄合わせするんじゃなく、
コンパイラがフロー解析を頑張ることで人間に負担をかけずに厳密な静的型付けを実現する
メジャーどころだとTypeScriptはそういう方向へ向かいつつあるね
ドカタ部門やハッカー部門など、部門ごとに次世代言語を決めた方が良さげ
HaskellのIOモナドみたいのが主流になってきたら
実行時型付けも局所的に使えるけど
全体としては静的型付け、みたいな感じになりそう
コードのどの部分で静的型チェックするのかってのが争点になるかもね。
>>439 単に新しいものでは地獄がまだ見えてないかもしれないだけかもしれんぞ。
とりあえず言っとくが
cobol だって perl だって vba だって php だって当時は新しかったんだよ。
>>446 lisp のどのような特徴が、あなたをして神の言語と判断させるのか？
LISPは神がかってるけどSmalltalkはゴミ
もう30年くらい前なのか、むかし16M位のメモリーのワークステーションで
ＬＩＳＰやってた連中は、メモリが足りないからＬＩＳＰは流行らないんだみたいな言い訳言ってたけど、
個人用ＰＣに３２Ｇのメモリーが詰める時代になっても同じこと言ってるんだろうな。
アンアン
ｏ
ｏ＿ /）
／＜＜
12月24日の午後9時から翌25日の午前3時までの6時間は
1年間で最もセックスをする人の多い「性の6時間」です。
貴方の知り合いや友人ももれなくセックスをしています。
普段はあどけない顔して世間話してるあの娘もセックスをしています。
貴方が片想いしているあの綺麗な女性もセックスをしています。
貴方にもし年頃の娘さんや姉・妹がいて、いま家にいないのでしたら間違いなくセックスしてます。
貴方と別れたあの娘も貴方がその娘にやってきたことを別の男にやられています。
貴方の将来の恋人や結婚する相手は、いま違う男のいちもつでヒィヒィ言っています。
すべてを諦めましょう。そして、ともに戦いましょう。
lisp が流行らんことから導ける唯一のことは結局algol系のシンタックスじゃないと
流行らんということ。
括弧がわかりにくいからインデントで分かりやすくする。
だから括弧にはほとんど意味は無い。
それパイソンやん。
Lispの系譜にあるPythonが生き残って
Smalltalkの系譜にあるRubyが死んだのは
必然だったな
rubyって「お前はもう死んでいる」状態なのに、
それは言わない御約束なのかな？
インデントもまともにつけられないクズペチパー以下のゴミ屑は論外として、
括弧は多少あった方が見やすい
pythonはちょっとクセがある
smalltalkは実開発前における分析設計用ツールとしていいんでないかと個人的には思う。
サービスやどのくらい急ぐかにもよるけど「動作する仕様書」としてそのまま本番投入って荒技も使えるしね
スタートアップ界の異端児！産業機器 x IT x SmalltalkのSORABITO株式会社
https://thepedia.co/article/1068/ Smalltalkのコードって死ぬほど読みにくいよね。
やっぱり古臭い言語はダメだな。処理系もなんかモッサリしてて古臭いし
こんな話題にまでHakellぶち込んで来て
どんだけHaskell嫌いなんだ……
嫌いってのは対等な関係だから割とうまくいってる
もっと差別的な感じになったらやばい
Haskellの今は知らないがfull importしまくってたり色んな演算子を作って使いまくって変数名も省略しまくりで
お世辞にも読みやすいとは言えなかったぞ
変数名というか型名がaとかbとかcとか
だがジェネリクスの可読性が低くてもジェネリクスが淘汰されることはない
ソースコードの不備をAIで見つける富士通
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/122501258/ 英数字や記号といった文字列の固まりであるソースコードを、
テキストデータとしてではなく、画像として分析するという。
>>478 面白そうな技術だけど、ビジュアルがヤバいｗ
どうせlintでもかければ良い話なんだろうなって気がするわ。
画像ベースだと
教師データで使用頻度の高い変数名を使うと高得点
みたいな奇妙なテクニックが生まれないんかね
画像でやってるからそういうのは起こりにくいのかも。
インデントが無駄に深くなってて、無駄な空白が広くとられてるとかは
結構簡単に診断できるかもね。
でもそれって人間が見てもわかることだよな。。
美しいコードがあったら1回しか書かないのはもったいないからコピペする
>>478 写真のオッサンどものザ・無能・SI感がヤバみ
>>483 人間が見てもわかること、って気軽に言うけど、それ「普通の彼氏がほしい」くらいの無茶振りだと思うぞ。
定量化してくれるんなら便利じゃん。
あと、画像を解析してるから、内容の是非じゃなくてバグを生みやすいような姿を検知してる、ってのは
古株のおっさん連中への強烈なエクスキューズになると思うわ。
内容の是非を判定するモノに関しては、どうしても静的解析と仲良くできなかったような連中が狂ったようにアンチする。
Rustスレみたいになる。
>>486 いやだから定量化のツールなんて今まで腐る程作られてるわけだけれど
結局、それを無視する輩に何言っても無駄だってことなんだがな。
人間の指摘は無視して機械の指摘は受け入れるとかどこか歪んでると思わんのかね？
ルールベースだろうと機械学習だろうと結局は受け入れ側の問題なんだが。
>>487 富士通が作ったとなるとおじさんたちには説明しやすそうだけどな
筋が悪いと思う
目的は定量評価そのものではなく、悪いところを改善することだろ？
ディープラーニングでスコアを付けられたところで、どうやったら良くなるのか分からんだろ
決められた最低スコアを満たすために深夜にPG達が死んだ魚のような目でインデントをいじくって試行錯誤する姿が目に浮かぶわ
>>488 いや富士通がやったことだからやばげなんだろw
googleがやったとかならおじさん受けはいいかもしれんが。
>>487 確かに定量化のツールは腐るほどあるが、
「本当の意味での見た目」を定量化したのは割と初めてじゃない？
面白いと思うけど。
無視する輩ってどこから来たのかわからんが、たいがいそういう奴は決まってしまえば無視はしない。
無視する事は出来ないから導入自体を見送らせる。
そこで、ルールベースじゃなくて「雰囲気」を一つの指標にするってのはアリだと思うけど。
機械の指摘ももちろんだが、機械の指摘をもって人間が指摘するんだから、あんまかわらん。
それに、そもそも人間の指摘も無視するわけじゃないだろ。
人間の指摘を無視するやつはそもそもプロジェクトでは長生き出来んだろ。社会人なんだから。
二元論じゃなくて、新しい尺度じゃね？
受け入れ側の問題と断ずるのは簡単だが、何故受け入れさせる事が出来ないか、ってのはそれを推す側の問題だと思う。
教師データをどう用意したのかは激しく疑問だな
Apache Foundationとかの定評アルOSSのソースを○、
富士通のSIのソースを×として学習させて、与えられた画像が○の方である確率をスコアとするんだろうかw
>>492 才クロマティック数とかさ、普通に気にしてりゃそこまでひどいことにはならんわけよ。
ツールの数はおれは十分だと思ってるけれど、結局そういう地道な数値なんてのはむしするわけだ。
ただただ新しい指標作りましたっていうアリバイ発明のためだけってのは
この業界では昔からいっくらでもあるわけで警戒するのが普通なんだよ。
https://msdn.microsoft.com/ja-jp/library/bb385914.aspx 受け入れられない理由はそいつの能力と与えられる時間の割合の話にしかならん。
地道に受け入れる体制をつくるかそういう奴を切るかの二つしかないのに
糞みたいな幻想にしがみついてるだけだわ。
>>494 お前さんの書き込み見ると、アンチを装った信者って評価になるけどな。
>>490 お前がプロパーエアプなことはよくわかった。
ワインゴ大将軍、循環的複雑度でコードのヤバみ検知してる最先端エンジンでその富士山・・？のなんとかよりずっと前から最先端だけど話する？
>>497 技術的には全くどうでもいいけど、
それを客にどう売り込んでるかとか導入後実際に成果出てるのかとかとかは気になる
>>494 無視するんじゃなくて、理解出来ない人間も居るんだし、そいつらを黙らせるのにも便利だと。
アリバイじゃないよ。わかったふりをさせて承認印を押させるような行為がアリバイだろ。
大体、営業や経営がシステムの事を深く理解する必要は無いし、大本営直下の人間ってのはそのどちらか寄り。
それは戦略上の必要悪なんだから、切る切らないの議論としては話にならん。
そいつらが見る時に、今までは言っちゃえば騙して盲判を押させてただけだろ。
地道なツールを無視するんじゃない。それは今までどおり開発部で使えばいいじゃない。
perlやhaskellをやったら、コードはやっぱり短い方が良いなって思うよ
でもコードの長さという指標はほとんど無視されているのが悲しい
haskellってそういうジャンルなのかよ
受け入れられないわけだ
短くするつもりは全然ないのになぜか短い
これなら受け入れられるか？
やばい全然勉強してないとか言いながら高得点を取る現象と同じ
やりたいことが全部標準ライブラリーに入ってるからじゃね？
ちょっと聞きたいんだけど
便利なライブラリが揃っているって
事と
その言語が優れているって事は
全く別の事だよな？
Haskellで1年前のコードをデバッグするの本当に地獄。
いろんな言語の悪口言ってるｗ
Debunking Myths About Programming Languages (and More)
>>508 マクロを追ってくのは面倒ではあるが
一つ一つ展開してけばそこまで無理ゲーではない。
しかしhaskellみたいに正格評価でない言語はバイナリイメージが描きにくいし
やっぱり辛いんじゃないかな。
Haskellのバイナリはイメージ出来んな
でも出来る必要あるか？
する必要がない人が使うんだろ。
良いじゃん、バイナリサイズが大きかったり、メモリ消費が多かったり、動作が遅ければ計測すれば。
大きくなるだろうな、メモリたくさん使うだろうな、これじゃ遅いだろうな、なんて気づきは無駄らしい。計測が全てらしいわ。
また半狂乱になって必要性の無さを説くのを眺めるのもめんどくさいし、そういう言語だって理解でいいんじゃねえの？
どうせPythonとかでもバイナリイメージ描かんじゃろ？
Haskellは動的言語以上にそっちの方向いっとる
そっちの極みやね
おまえら、いつも「これはどんなバイナリ」とか考えながらコーディングしてんの？
バカじゃないの？
俺も数学科出身なんだけど、層の理論ってプログラムと関係ないと思う。
だけど、↓みたいに数学的基礎付けが欲しい人はいるのもわかるが。
Haskellと層
https://qiita.com/makoraru/items/ab891a60d4dfe4bbf649 バイナリイメージっつーか
結局デバッグってどの時点かで想定の値と違ってるところを探るってことになるわけで、
その評価のタイミングとか考える必要があるじゃん。
そういう評価のタイミングがわかりにくい言語だとデバッグがきついんだよ。
一応、タイミングという概念から解放されるための参照透過性なのでは？
解放されたいのはわかるが実際は違うんだから仕方ない。
言語でいくら定義しようが、ノイマンマシーンはそんな風には動かないんだから。
実行できない仕様記述言語の方が初心者に優しい
バイナリとかメモリとか気にする必要がないことが明確になる
実行できる機能を追加したら言語の評価が下がる
もちろん実質的な価値は上がるが、評価と実質が乖離するのは初心者には難しい
実際Haskell 使ってて、タイミング気にしないといけない状況って何よ？
>>524 メモリが無限にあるならサンクがどれだけ作られても気にならないけど
実際は違うから適当なタイミングでサンクを潰す必要がある
それもそうか。たしかに妙なところで妙な泥臭さが顔を出すな
>>468 読んでみて面白いと思ったけど、「動作する仕様書」ってのがいまいちイメージ出来ない。
参考になるURLとか知ってる人居ますか？
>>525 同時にそれはオブジェクト指向の謎でもある
実数と整数の間に "is a" 関係は存在しないのか？
>>515 動的言語じゃん。
まあそれでもどう解釈されるかとか、これじゃinline展開されんな、とかはJavascriptでも考えるが。
>>518みたいにしない人はしなくても良いようなプログラム書いてるんだろうし、無駄だよ、この議論は。
>>528 古いけどこれとか参考にならないかな？
「分析・設計ツールとしてのSmalltalk」
http://web.archive.org/web/20131025032224/http://www.sra.co.jp/public/doc/GSletter/vol.26/smalltalk/smalltalk.pdf
本当に必要なのは、コンパイルの通る仕様書じゃないか？
動作する仕様書です！なんて出して、「それで動くんだからいいじゃん、はい保守」
なんて言われた日にゃ地獄の始まりだろ
Smalltalkerにはソレで十分なんですよ
なんとなく動けばok。エラー？握り潰せば？の世界だから
動作はするけどなんだか速度が遅いから最新機種の方がいいじゃん、はい購入
これがマネタイズだ
>>533 あまりに動的性を追求しすぎててインタープリタ言語と勘違いされがちだけど
Smalltalkも（VMで動くJavaがそうであると言える程度には）コンパイラ言語なので
「動く」以上はコンパイルは「通っている」んだな、一応ｗ
もちろん533が言いたいのはそういうことじゃないことは分かっているんで、マジレスすると
型システムのチェック（のことだよね？）を通すのにコスト（主に人員や時間）をかけられる程度に
急ぎでない（つまり「仕様が固まっている」）のならSORABITOとかで求められる
「必要なら本番投入も可能な動く仕様書」的側面はきっとあまり役には立たないだろうね
>>533,534
こっちにもマジレスすると、実際そのとおりで
Smalltalkの設計者ら（アラン・ケイだけど）は
ひどいと「地獄」とまで形容されるそれ、つまり本番投入後の要求変更を必要不可避なものとして捉え
天国とまでいかずとも他言語には難しい後からの大胆な仕様変更をも支援できる動的性を
この処理系（環境を含む）に付与することに腐心し、それはある程度奏功している
「ソフトウェア工学」は矛盾語法か？ -- アラン・ケイ
http://metatoys.org/oxymoron/oxymoron.html Smalltalkの底を流れる設計思想 -- ダン・インガルス
http://web.archive.org/web/20041016084842/http:/marimpod.homeip.net/chomswiki/24 TDDの「ひどい仮実装でもとりあえずグリーンにするのを優先し、そこから重複を除去（リファクタリング）」
というとんでもない発想が生まれ得たのもSmalltalkのこの大胆な変更への追随力があったから
>>533 きみには孫請けSIer根性が染み付いているようだねッ 彡⭐
Pythonよりすっきり書ける言語がないという事実
>>539 lamdaが糞
finalがない
privateがない
はい完全究極ロンパリオン・ギガアタックEx
>>540 そんなゴミクソ仕様の塊よりすっきり書ける言語がないという事実
>>540 ×lamda
○lambda
>>540 Y コンビネータをすら記述できない lambda 仕様が特にコンパイル言語にも氾濫しているが、いったい何の役に立つんだ？老害避けのつもりか？
>>541 おまえのいうすっきりって何だよ
俺はTypeScriptですっきり書けてるが？
俺なんかXenoExtraUltraGigaJetHyperUltraMiracleSuperコンピータだが文句あるか？
>>545 君の芸風とても好きだ！
＞UltraGigaJetHyper**Ultra**
またTypeScriptか。
いい加減ちょっと落ち着いてほしいな、推しの人は。
言語仕様はごった煮、出来上がるのは微妙に汚いJavaScript。
async awaitをネイティブのasyncじゃなくてトランスパイルした結果なんて変数のライフタイム無茶苦茶長くなるし。
言語としてのTypeScriptはいろんな意味で何でもできて良いと思うけど、今の実装としてのTypeScriptって微妙だと思うんだが。
単に書く時にスッキリかけても、ちょっと違う気がする。
>>547 普通にコンパイルオプションの問題だし。
outputをes2017に指定すればいいよ
>>548 そうじゃなくて。だからネイティブのじゃなくてトランスパイルさせたらって前提付けたんだけどな。
なんかあそこまでやるなら、JSとの相互運用諦めてもっと汚いコード出せば良いのに、と思ってしまうんよ。
>>549 TypeScriptのトランスパイルコードを直接いじることは無いからなぁ。
なんでそんな状況になったの？
>>550 弄ることは無いが、あるべき姿になるようにTS側で書き分ける事はあるかな。
くっそ遅い関数がなんで遅いのかを調べにかかった時に、モヤモヤした覚えがある。
genericsとか、型ごとの関数をちゃんと作ってほしいけど、一つだったり。今違うかったらすまん。
その時は、これでJIT結果捨てる事になってる…って気づいて、素直に沢山関数を作った。
コンパイラと言うならもう少しVMの仕様を鑑みても良いと思う。
特定のブラウザの現在のバージョンに最適化しろってこと？
お前それ自分がコンパイラ作る立場ならやろうと思うか？
やろうと思うならお前がコード書いてプルリク出してやればいい
確実にリジェクトされるだろうけどな
wasmが吐き出すjavascript気になるマンが出てくるに100000000000000ジンバブエドル
気にしないでいいって保証が欲しいのはよくわかるよ。
確かにTypeScriptは実際に書いてるとめちゃくちゃ次世代感あるが、
それはReactとかReduxとかのメジャーを作ってる奴らが関数型厨だからで、
次世代なのは、言語というよりはライブラリという感じがする。
PHP書かされてたときは辺境の島国で首輪に繋がれて石器で木の実取ってる気分になったわ
>>552 特定のブラウザじゃなくて。そういう発想がセンス無いの。
複数の型で同じ関数を呼ぶとかストールするのはほとんど当たり前と言っても過言じゃなかったりするけど、それを「特定のブラウザの問題でしょ？それよりこんな新しい機能ついたよ」って毎回押し切ってくるのがTypeScript。
AssemblyScriptなんかは好きだけどね。
TS使うプロジェクトにはたまにプルリク送ってるけど、最終的にはTSっぽくないTSのコードになるよ。
>>559 だから、特定のどうの、ではなくて、概ね大半の処理系でJITに乗るようなコンパイル結果出せって言ってるんだけど？
無理した小奇麗なJSっぽいコード出さなくても良いじゃん、って。
V8だと何バイト以下なら関数はインライン化される、とか細かい癖も確かにあるけど、だからこそ小奇麗で無くていいと思うんだが。
もしかして、今TypeScriptでジェネリクス使っても、JITは結果破棄しないのかな？
そうならごめん。
要はTypeScriptの実装が良くないということなんだろうけど、使う側からしたら
パフォーマンスやフットプリントが許容範囲を超えない限りは気にしないかな。
実装が中途半端、かな。JSに引きずられすぎだと思う。
Cで言うとexternしない関数が関数としての形を保たなくても良いのと同じ様に、exportしてないものを似たようなJSのコードにする必要は（もはや）無いと思うんよね。
許容範囲次第なのは確かだけど。
言語としては新しくて良いと思うが、処理系として微妙ってのはそういう所。
>>562 ジェネリックをソースレベルで展開なんかしたらフットプリントが増えて
JavaScriptで一般的に言われるパフォーマンス(つまりロード時間)は落ちるよ
おまえらなんかよりずっと賢い連中が作ってるんだから
問題なんかあるわけねえだろ
バカか？オレオレFW作りたがり坊やのペチプァなのか？
>>564 ブラウザだけで動かしたい訳でもないし、起動時のパースのフットプリントをどうこう言うのであれば、今のNodeのnode_modules自体、既に無茶苦茶でしょ。
それも、最初に一発パースするからそうなるんであって、bootstrapとその後に分ければいいんでないの？
>>565 ペチプァ言いたいだけだろうが、ペチプァ連呼して悦に入って問題を理解できないやつにゴタゴタ言われたくはない。
ID:dTmScpvt言ってる事そんなにわけわからんくもないのになんでこんな事になってんだ？
正義を徹底するより中途半端の方がいいと思ってる奴はいっぱいいるから
>>564 トランスパイラである以上多かれ少なかれそういうオーバーヘッドは避けられるものじゃないと
思うけど、問題はそこでTypeScriptがBabel等と比較して出来が良くないのかどうかだね。
過剰な最適化は開発のスピードを落とすしバグも増やすからな
いいか、喚くだけなら頭がPoorのペチPoorでもできるんだよ
わかるか？わからんやつはペチプァだけだが
>>571 おまえは気が狂っている。
一刻も早く病院へ行け。
ペチPoorはおつむもおちんぎんもPoorでかわいそうね
>>570 そろそろコンパイラと言うなら、最適化フェーズに入って欲しいわ。
ずーっと(確かに欲しいのはわかるが今でなくて良いだろうと言いたくなる)新機能つけ続けてるじゃん、
>>579 そろそろ課金するフェーズだろ
お金を払ったら悪口言っていいし、悪口言われたくないならお金稼ぐのをやめればいい
>>581 課金するフェーズはまあ別に妥当な値段なら買うよ、マジで。課金して良くなるならね。
VSより高いとなるとちょっと考えるけど。
自分でプルリクせえとなっても、suggestionの段階で同じ様なパフォーマンスのためにJSの形変える系の話は、みんな却下されてたはず。
要は皆
>>568の様な形で、中途半端で良いと思ってて、どん詰まりはもっと先だろと楽観視してる。
もはや単なるリンタ。
無意味に計測だけしても無駄でしょ。
推論からの計測で計測からの推論かと。
どこを計測するか考えてる時点で推測しとるって事だからね。
>>582 そもそもTypeScriptは単なるリンタだろ
お前がプルリクを出すべきなのはTypeScriptではなくV8
「推測するな 測定せよ」みたいないわゆる格言に対してそんなガキみたいな屁理屈捏ねられてもね……
>>589 意味を理解しない格言や誤謬を招かんとする格言の使い方には一言言いたくなるじゃん。
そう信じて計測だけする奴が可哀想だ。
どう考えてもV8にコミットするのが筋だわな
別にTS批判君が全ブラウザをやらなくても、効果的な改良なら他もすぐに追従するだろう
まさかJIT結果だのVMの仕様だのｷﾘｯが付きそうなレスしてるのにC++やネイティブコンパイル分からないとか言わないよね
wasmにGCが搭載された暁には
いくらでも頑張って欲しい
>>595 いや違うだろ。
なんでTSのコンパイル結果がクソなのをV8が面倒見るべきかわからんが。
普通にコンパイラとして真面目にコンパイルすりゃいいのに、って話で、
トランスパイラならトランスパイラと名乗れば良いのに。
よくもまぁこういう擁護ができるなぁと思うわ。
V8や他のJSエンジンは、JavaScriptの処理系であって、TypeScriptの処理系じゃねえんだから。
それこそ、TypeScriptが吐き出した中途半端なJSに対するチューニングなんか必要ないだろ。
V8側のスタンスは「最初からJSで書きゃ良いだろ、asyncが欲しい？考えてやるよ」と機能の面では歩み寄ってきたじゃん。
そういう意味で、wasmに振って、ちゃんとコンパイルするAssemblyScriptはいい方向だと思うが、
tscの方向性は微妙としか言い切れんと思う。
TS自体がなんで未だにJSに引きずられる必要があるのかわからんが、皆がそれで良しとする理由は「中途半端で良いから」なの？
コンパイルした時点で型が消えるのに、JITに引数の型に対して何種類か載せ続けるべき関数(ジェネリクスだった関数)なのか、それともany受けてるただの関数なんか、それこそプロファイル取ること自体無駄じゃん。
最初から型ごとに吐きゃ良いのにって思っちゃいかんのか？
名前の通りbetterJS以上の認識は無いな
少なくともtscだろうとtstだろうと単なる名前に拘る奴は居ないと思う
>いかんのか？
いいと思うよ
>>598 実行時に型ごとにJITを分けるのって割と一般的な最適化手法だろ
型ごとにjsを生成すると言っても結局それらはみんな同じコードであって型情報なんて残らないんだから、
それが適切に最適化されるかどうかなんて処理系次第だろ
jsに型アノテーションを導入しろというなら理解できるが、あんたの主張は無茶な言いがかりにしか見えないな
補足
最適化されるかは処理系次第、といったのは、結局、型ごとにjs生成しようが
JITは実行時の型を利用して最適化することには変わりないんだから、本質的には大した違いはないという意図だぞ
ヘボいと言うなら複数の型に適切に対応できないJITがヘボいんだよ
>>578 主治医の先生にもそう言ったのか？
ちゃんと薬のめよ。
>>601 型ごとに生成すりゃJIT破棄しないだろ。
ちょっとは挙動わかって言いがかりつけてんの？
>>605 まともな実装なら型が数種類あるくらいならJIT破棄しないよ
妄想でごちゃごちゃ言ってないで検証コード載せなさいよ
どっちが馬鹿かはっきりするでしょ
>>606 あ、そうなんだ。それは良い風に変わってるんだな。
俺が見たときはほとんど整数、たまにエラーを表すオブジェクトのときに、毎回オブジェクトの時にJIT捨ててたけど、古いといえば古い話だし。
まぁプロファイル次第なんだろうな。
>>607 どっちが馬鹿とかじゃなかろうが。
そういう発想がマウンティングとかいう発言に繋がってんの？
>>609 ホントだな。
過去スレの印象で言ってるもんだと思ってたわ。
まあ新しい言語やるやつの動機の7割はマウント取りたいで合ってるよ。
x >= y または x < y などと変数でごちゃごちゃ書いてないで定数にすればわかる
変数は妄想だ
妄想するな計測せよ
まあ個人の体験談みたいなものを根拠に主張したって賛同はされんわな
コードが出てこないと改善の有用性も見えないし抽象的な話で止まってしまうよ
そーだな、ぜひともHaskellで書いた次世代言語らしいサンプルが見たいもんだ。
他の言語は出たのにな。
HaskellとKotlinとTypeScriptのサンプルが出なかった時の話だろうか
サンプルコードが出るとダメな言語は一目瞭然だったりするからな
Sから始まる言語とか
ダメな言語の批判ばかりだよな
よかった言語の名前は出せない空気になってる
そいつは例のあDHDだろう。Haskellユーザーがいないこのスレで触ったこともないHaskellを叩き続けるガイジだから触れない方が良い
文句なしの打っ千切り糞言語賞ナンバーワンはPから始まるあの言語だよなぁ
PooHPoorの話はおいといて、好きな言語の話をするのは良いな
ブレストの「批判をするな」がいかに大切かわかる空気感だね
ブレストは頭の中だけで行動が伴わないので批判しなくていい
厳しく批判されるのは実行に移そうとした時
マンセーしたきゃ勝手にすりゃいいじゃん。
現実で文句言われるよりここで言われる方がマシだろ。
現実でニコニコ
ネットで陰口
美しい国ジャップランド土人村
ネットは筆記試験のようなものだよ
筆記試験もネットと同じような批判をされて面接重視になった
Elmってどうなんだろ。インスパイアされたhyperappとかいうのがあるけど。
新しいjsライブラリは結構TypeScriptサポートしていて嬉しい
全てのJSプロジェクトはTypeScriptにしろ
棒案件で立ち上げ時にクソバカの老害オッサンがJSでコード書き始めたせいで
どんだけ苦労したか
TypeScriptは認めるがBabelはほんとやめてほしい
わざわざビルドを面倒にするだけの見返りはどう考えても無い
Babelないとjsxも書けないし新しい文法も使えないぞ
糞まみれの生JSに戻る気か？
TypeScriptもいずれノーマルjsに吸収される
>>636 それ理想的だね。型を最初からサポートしたほうが良い。
typescriptを中心に据えてオプションで型無しをサポートする方針にしたほうが処理性能向上に寄与する気がする。
あとnumber型を廃止して
>>621 もう叩いてないぞ。
割と興味出てきたのに、誰も、ここが良い！を言わないからつまんねえのって思ってるだけだよ。
スレタイに入れたいだけじゃねえの？って。
正直、使ってみた感じは悪くないけど、この便利な言語でこういう事すると楽かな？みたいなのがあんまり思いつかんので、良いサンプルは見たいな。
GoのGoroutineやchanの気軽さとか、erlangのプロセスの考え方みたいなのとか。
Haskell使った有名なアプリってなんかあるの？
>>641 linuxを、デスクトップ用途で使うならいいけどなぁ。
wafとかで革新的なやつとか無いのかね？
関数型の後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)」と匙を投げたという残念な
結論のまま現在に至っているという共通認識があります
http://2chb.net/r/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 再帰なんか同じ表の行番号を持たせるだけだろ
３次元以上を汎用に使おうとするとSQLみたいだったり tensor flow だったり
かなりめんどくさいインターフェイスになるのはしゃーない。
まぁ、Haskellで作られたものより、Excelで作られたモノのほうが多いしな(笑)
純関数型(笑)
>>719 このようなtypoを防ぐためにも強い型付けが必要なんだよ
>>727 変数宣言（型宣言ではない）だけでいいと思うが、それだけでもいいから、事前チェックを可能にしてほしいなあ
python のバイトコンパイル機能は変数名をチェックしてくれるのでしょうか？
headerをincludeしてチェックする言語は簡単だけど
コンパイル済みのライブラリの中身を見て名前をチェックする言語は大変そうだ
コンパイル後も情報を全部残しておかないといけない
変数宣言を省略できる機能(スペルミスが検出できない)と、型付けは別だよね？
昔のFortranやBASICは変数はいきなり使っていいけど名前で型が決まる静的型だったし
宣言がない変数は、省略ではなく他のファイルで宣言している可能性がある
そのファイルをincludeするか、全てのファイルを検索する必要がある
下がってから言っても遅いな
レベル高かった頃に、なにこれ高いって評価できる奴が勝つ
まぁ、その時から無駄なつっかかりしかできない奴ばっかだったし仕方ないんだろうな。
今更option explicitじみた話に戻るとは。
自分で書いたコードが三ヵ月後に読めないっていうやつは素人
プロは三ヵ月後の記憶喪失を織り込んでる
そういう足を引っ張る人には保守受注の代わりに
ベーシックインカムをあげたらいいんじゃないかと言われている
足を引っ張る悪人より善良な怠け者の方がいい
しょーもない理想論はいらんねん
こっちはきっちり世間様に仕事回してんねんで
頭の悪いガキは黙っとき
ソースがきれい → オタクの自己満足
ソースがきたない → 工数取れて残業代も出る、みんなニッコリ
これが現実やで
そんなことしてるから他国の技術に駆逐されるんだよ。。
その理屈だと、まるで必要もない次世代言語で書くやつみたいだな。
汚いソース書くやつは。
次世代言語で書くだけならいいんだよ
故意に汚くするとはいってないから、改善する可能性がある
故意とただの偶然とでは罪の重さが違う
故意にその言語で書いてる以上、もう偶然でもなんでもないだろ。
ちゃんとその言語のメリット、デメリット含めて布教してから使うべきだと思うが。
ちゃんとする可能性があるならいい
その可能性をわざと排除するなら悪質
最初からそう言ってるんだろ
まあ大体がカスな開発体制に問題があるところに
新しい言語なら問題解決できる！
とかめちゃくちゃな広告が出回って導入、失敗っつークソパターンがここ20,30年の間繰り返されてるわけだからな。
JSに依存するのはいいがGHCがな
もしもF#がGHCに依存していたら面倒臭いじゃないか
気の科学 ★朝は気合いで起きる★ 雑学
なんかTypeScriptのジェネリクスがどんどん変態じみてきたんだけど、ジェネリクスってこういうもんなの？
これならgoに乗んなくていいなぁ
>>756 欲求は際限なく広がって、そしてゴミの塊みたいな仕様になるもんだ。
ずっと前からTypeScriptは手段と目的をどっかで履き違えたと言ってたが、最近シャレになってない。
Goの割り切りは納得に値するよ。あったら便利なのは認めるけど。
Cppのtemplateみたいに、それだけでチューリング完全になってしまう前に、最初から入れない、やるならgenerateで別立てで勝手にやれと言う割り切りしたのは英断だと思う。
>>757 ジェネリクス関連のエラーメッセージは本当に意味がわかんないよね。
ユーザー視点ではimmutable.jsとかでも補完が効くのは便利になっていいんだけど、
いざ型関連エラーが出た時にエラーメッセージから原因を予測するのが困難なんだよね。
rustもあんな感じなの？
正直TypeScriptはエラーメッセージをわかりやすくする方向に軌道修正頼んます。
>>758 変性注釈とか、やりたいことはわかるし、なぜ必要かもわかるが、一方でjsとどんどん乖離していって、jsのプロジェクトと繋げるときに結局any使うことになったり、グダグダも良いところだと思う。
TSだけでもの作るんなら、良いと思うが、そうなるとJavaScriptにコンパイルできる必要もなく、逆に早くwasmなんかに対応しろとか、ネイティブにTSの良いところを保ったまま実行できる環境出せとか、色々文句が言いたいけど、
全部ほったらかしにされてるからな。
ずーっと言語の改良してる。
一方的にjsのライブラリを使用する分には問題ないだろうし、その資産にただ乗りできることこそ
jsとの相互運用性を維持する理由だろう。
言語仕様としては奇麗だけどライブラリが揃わなくて実用性がいまいち、みたいになるよりは。
>>760 jsのライブラリ側が自由な感じのライブラリだと定義ファイルが無茶苦茶ややこしいものになったりするし、なかなか微妙だけどな。
ライブラリが揃わなくてイマイチ、は確かに無いか。ほとんどタダ乗り出来るからなぁ。
>>761 せめて関数のオーバーロード定義みたいなことが出来ればコードが整理しやすくなると思うんだよね。
つまり
export function h(name, attributes /*, ...rest*/) {
// 省略
return typeof name === "function"
? name(attributes || {}, children)
: {
nodeName: name,
attributes: attributes || {},
children: children,
key: attributes && attributes.key
}
}
ってあった時に
export function h(name: string, attributes:obj /*, ...rest*/) {}
export function h(nextFunc: (attributes:obj)=>void, attributes:obj /*, ...rest*/) {}
みたく出来れば型定義自体も綺麗にできる気がする。
でも今のTypeScriptってこれできんよね。
あと詳しい人に聞きたいんだけどやっぱりジェネリクス一つとっても
言語によって全然仕様が違うのかね？
だとしたらGoはコードジェネレートと組み合わせも考慮したちょうどいい便利さの
ジェネリクスというのも考えていて実装を見送ってるのかも。
でもGoにはそれ以前にnull安全を実装してほしい気がするが。
レシーバがnullの可能性があったりnull周りに罠があるんだよねGoは
>>762 オーバーロードってまさにそんな感じでできた気がするが。
ジェネリクスは途中から入れるようなもんじゃないと思うがね
型自体はフラットな構造で、階層構造はHaskellみたいに型の境界（型クラス）として作ると綺麗にまとまりやすい
型≒クラスで、型自体に階層構造を作ってるような言語だと、ジェネリクスの使い方が面倒よ
Javaの<T extends ClassFoo>とかＣ#のin/outとかは元の型システムに合わせて入れないといけない面倒な部分
TSの元々の型システムはよく知らないけど、ダックタイピングできるならジェネリクス入れる必要がないし、
クラスがあったり型に階層構造があるなら面倒なのはしょうがない
むしろJavaScriptさんが悔い改めるべきではないか？
Goでレシーバがnilになれるのは案外便利だぞ。
あれは罠ではない。
型や型クラスに階層構造持つのはいつでも便利なわけではないと言うか、結局コンパイラ都合を押し付けられてるだけな気がするけどな。
その辺、後出しジャンケンできるGoのinterfaceの方が楽な事が多い。
ジェネリクスは、コード上別の箇所に出現する型Aと型Bが同一であることを明示することにより、型情報の損失を避けるために使うんだよ
ダックタイピングは関係ない
C++やHaskellをやってる人は
>>765みたいに混同しがちだけど、JavaやC#だと多態とGenericsをわりとはっきり区別する文化がある
TypeScriptのGenericsも同様に、型の同一性を示すマーカーとしての性格が強いね
「型が同一である」の定義がわからない
犬型と猫型は異なるともいえるし同じ動物型ともいえる
この辺の仕様を捨ててからジェネリクスを追加するのが基本
もし両方入れてゴミ言語ができたら
捨てられないのが原因ともいえるし追加したのが原因ともいえる
それに対して型の制限を型でなくしたのがHaskellの型クラスやRustのtraitだし、型を分解する事で非同一性を示すのが多くの言語にあるパターンマッチじゃないの
型階層のある言語でアドホックに型クラスをやりたいなら別途Comparableみたいなインスタンスを受け取るようにするだけだろ
ジェネリクスと区別するっていうのは端的にはそういうことで、実際に引数として明確に分かれることになる
JavaやC#, TSだと型引数に制約を付けることで中途半端に似たことができてしまうのが微妙に直行してなくてダサいけど、それは基本的にあまり使われない機能
すまんComparatorの間違いだ
補足しとくと、直行してないというのは例えば具体的には <T extends Comparable> と (T obj, Comparator<T> comparator) みたいなののことな
>>767 便利さを教えてほしいな。
純粋なnilと型があるけど中味はnilって正直わかりづらくないかな。
reflectionのお勉強をしないと理解できない。
Goのインターフェースは後出しジャンケンってのは面白いな。パクらせてもらおう
>>768 このへん詳しく知りたいな。
C++とかHaskellのジェネリクスってTypeScriptとかと違うの？
>>773 それがnilでも、メソッドチェーンできる。
だから、errを伝搬するのに便利。
末尾のDoなんかで、本当の結果,errorとして取り出せば良いよ。
いちいち失敗構造体なんぞ書かんでも良い。
Nullable的に使える。
どっちかというと下回り書いてるときに便利かも。
>>774 C++はテンプレートを使ってダックタイピングができる
Haskellはアドホック多相を使って
>>772でいうcomparator引数に相当する要求をTの型制約に含められる
>>775 なんかサンプルある？とょっとイメージがつかめない。nilでメソッドチェーンができるのはわかるけど、それがメリットになるかな？
結局nilを、返してるメソッドがエラー状態な訳で、そいつが暫定的な値を返せばメソッドチェーンはできるよね。
>>777 暫定的なオブジェクトに、レシーバ書いてくの？
Hoge().Get().ReadAll().AsString()
で、毎度nilチェックとか暫定レスポンスのオブジェクト置いてたら非効率じゃん。
ToXXX以外の関数が、Hoge()の返す型やinterfaceを返せば楽じゃない？
Getに失敗したかReadAllに失敗したかが必要ならまた別だろうけど、だいたいひとからげにして問題ない事の方が多い。
>>779 error情報を最初から諦めるってことね。
とにかく最終結果がnilだからメソッドチェーンのどっかで失敗してんだろーなー。くらいの感じなのか。
標準ライブラリでそういう実装してるのあるかな？reflect.Valueとかかな。
あれメソッドチェーンできる代わりに不正なメソッド操作するとpanicしててなかなかしんどい。
>>780 ちょっと違うけど、protobufあたりはもう少し有意義に使ってたな。
流れをぶった切って悪いけどTypeScriptはさすがMS。開発リソースたっぷり。という余裕を感じる。vscodeと一緒に毎週くらいの勢いでアップデート繰り返してる。
ジェネリクスの気持ち悪さもエラーメッセージがわかりやすく進化する感じで直してくれれば全然良いので頑張ってもらいたい。
goのことは全然知らないんだが、型付きnilとやらは実行時ディスパッチしてくれて
その型のメソッドにnil引数付けてやってくるという理解でOK？
まずメソッドではなくて、ちょっと変わった構文のの関数ぐらいに受け取ったほうが良いかも。
Foo.Bar()は
Bar(Foo)と、
Foo.Bar(a,b)
は
Bar(Foo,a,b)と同じぐらいの意味。
だからFooがnilでも(ポインタに対してのレシーバであれば)呼べる。
やはりメソッドチェーンは何回も値 (nil) を返すのが気になる
Haskellでは
((Nothing >>= f) >>= g) >>= h
こうするとNothingのパターンマッチを3回するのに対し
Nothing >>= (\ y -> f y >>= (\ z -> g z >>= h))
これなら1回だけ
記号がなくても右結合がきもい
h(g(f(x))は右結合
x.f().g().h()は左結合
こんなのをありがたがるくらいならCommonLisp書くわ。
goの場合nilの場合分けを関数の中でしなくちゃいけないわけだろ。
それが嫌だからモナドができたわけだからな。
メソッドチェーンも嫌だからasyn/awaitとかdo構文が出来たわけで
全部が劣っているな。
秀でるのと、こねくりまわすのは違うからな。
原理上、変態構文と純でも何でもないモナドで出来るとか抜かすぐらいなら、nilチェックするほうがマシ。
コンパイラはモナドをコンパイルエラーにしない
一部の人間は忖度してモナドを自主規制する
コンパイラと人間はどっちが正しいかというだけの話
機械と人間の両方に指図されるのは不自由過ぎる
両方採用するのは過激派
どっちか一つだけにした方が中道という可能性がある
goにいまさらnil安全は無理かな？
python3並の断絶が起きちゃう？
そもそもnil安全にする必要もない。
その変数に型的にnilが入ることが無かろうがあろうが、
他の言語のnullとはちと違うレベルでnilを取り扱える。
タプルで返す前提だと大した問題には無いと言うか。
他の言語は、nullに本来のその型が持つ意味以上の意味を与えてしまうからわざわざnull安全にしないといかんのでは？
タプルで値が返せるから必要ないってただの理屈の上の話で、エラーチェック漏れをおこしたり、エラーチェックしててもnilの入った変数を次の処理に引き継ぐミスは起こり得るだろ。それを防ぐのがnil安全なわけで。
俺も
>>797と同意
>>796の言ってることはいまいちよく分からん
nilに余計な意味を与えるからダメとか言ってるがnil自体がそもそも余計だと思う
nilは便利すぎるがゆえにチェック忘れ系の地雷がある
ポインタ演算みたいに強力な機能は同時に危険も引っ付いてまわる
そういった機能は出来うる限りは排除・制限していくべきだと思う
nilに余計な意味を与えないための基準がnil安全なのでは？
同僚のコトリンのコードがビックリマークだらけで、こりゃだめだと思った
だから、便利に使わなければ良いと思うんだが。
参照にしない限りnilにはなれないし。
>>797 すまん。番号ズレてるな。以下訂正
> 俺も
>>796と同意
>
>>795の言ってることはいまいちよく分からん
スマホアプリ使ってると時々ズレるんだよな クソが
そのせいで自分で自分に同意するというアホな文章になってやがる
>>798 基準がどうこうってnil安全な言語ってのがわかっていないのかな?
設計思想とかの話じゃなく言語仕様の話をしてんだけど。
つまり変数に明示しない限りnilを代入不可能な変数が作れるってのか
nil安全な言語ってこと。
TypeScriptなら
let some?:number = null; // OK
let some:number = null; // NG
ってこと someにnullが入っている可能性をコンパイル時点で排除できる。
Goだって
func hoge(s *Some) {
// sが絶対nullじゃないことが保証されるスコープ
}
func (s? *Some) SomeFunc() {
if (s != null) {
hoge(s)
}
hoge(s) // NG コンパイルエラー sがnullである可能性が残っている
}
みたいな感じで書ける。?が使えると仮定
>>803 しょぼ！
その例はnull安全の中でも一番弱いやつ。
書き方を気をつければnullを避けられるってだけ。
本物のnull安全はスコープ単位ではなく、型検査が通ればプログラムにnullによる誤りを完全に排除されるんだよ。Haskellのように。
>>804 elmも実行時エラーを完全排除できるというのを売りにしてたね。
しょぼくても学習コスト最小でメリットは十分享受できる。
とりあえずelm触ってみようかな
>>804 haskellはそんな事の前にもっと解決すべき問題を解決できる言語になってくれ。
動的型で解決できる問題はすべて静的型で解決できるし
もしこれが嘘八百だと証明されたとしてもそれはそれで大きな成果だし
いずれにせよHaskellは静的型の歴史に貢献している
でも需要はハケスル（笑）＜＜＜＜＜ＰＨＰで圧倒的な件w
歴史に貢献するって、ラテン語でもあるまいし。
実用言語にしてよ。
実在するだけでは不満か
実在すら怪しいものがあったらもっと不満だろ
実用よりも実在の方がモチベーションが強い
>>809 ラテン語は良い喩えだね。印欧語ヒエラルキーの上の方にいるし。
俗ラテン語を見て、どこが欠落してるかの見通しが良くなる。
Haskellも足りてないけどさ、型理論的に。そういう点でもラテン語あたりなのは妥当。
コンパイル時に解決できるならそれに越したことは無いが
そのための学習コストは増大する傾向にあるよね。
Elmはブラウザのviewに特化したDSLとして学習コストを抑えてる。
Rustもメモリリークを静的に解決しようとするけどそのためのコストはかなり高め。
何事もバランスだよね。
>>811 そう。
そんなに格いるか？確かにあれば便利だけど前置詞のほうが実質簡潔じゃねえの？とか、
今更ラテン語使う必要無いだろ。足りない語彙を現代語から借用するの？とか、
ヒエラルキーの上位と言うより、広がる枝の根本にほうっておかれた存在だろ。
全く次世代で無い。
Haskellの熱心なアンチが全くのエアプだった事件があるので、そういう意見はHaskellに精通していることを示さないとなかなか受け入れられないと思うよ
まあカス仕様を必死に守るのにコストかけるくらいなら
goみたいにコンパイラの性能上げてもらった方がよっぽど有益だったりはする。
>>814 エアプって言葉好きだなぁ。
正直触ってダメ出ししたぐらいだけど、精通せんでも文句は言える。
ラーメン食いに行って「まずいわこれ」って言って、店主に「じゃあお前はこれ以上のラーメン作れんのかよ」「それだけラーメン食って言ってるのか？」ってキレられても困るだろ。
客観的にまずいもんはまずい。まずいと誤解されるものもその次にまずい。
意識高い系のおもちゃとして使うんじゃなくて、なんか使えるプロダクト出してから言ってくれよな。
古代言語を次世代言語スレで出すんなら。
>>815 https://taiyaq.com/contents/YgxOd3YjadMa5c793O1j1d9VX goの設計思想自体が依存関係解決の高速化だったりコンパイル速度優先の実装みたいだね。
ジェネリクスみたいなコンパイル時の計算速度に大きく影響を与える仕様はなさそうだ。
(あっても限定的な機能になりそう)
goにはクラス階層も無いんでしょ？ジェネリクス以外の多態が無いならまだ綺麗に導入できる可能性がある
swiftはバージョンアップで型推論を入れるようなスジの悪い進化を進めてるから好きになれんよ
コンパイル速度優先の上で云々ということであれば
goがDelphi/FreePascalを超えてるかというのは正直疑問
>>820 goはinterfaceによる多態が既にあるから、そこにジェネリクス入れるとJava同様になるぞ
>>821 現在も絶賛コンパイル速度更新中だからいいんじゃないの。
そもそもdelphiって古すぎて早く見えるってだけでは、、、？
>>822 interfaceを進化させるイメージでジェネリクスぽいものを作るんだろうね
現状複数のinterfaceを受け入れる可能性のある変数は空インターフェース(interface{})
(javaでいうところの何でもありのObject型みたいなの)
にするしかないのがツラミになってる。
ここを改善する方向に進化させるでしょう。
直積型をつくるのはできてるから直和型(union)をサポートして
someFunc(o interface{}) error {}
みたいなのを
someFunc(o A & B) error {}
someFunc(o A | B) error {}
みたいにできればいい。TypeScript好きだからこうなったら感動する
古すぎて速いってのは正しい
あとはジェネリクスがない言語は古いと認識できたらもっと正しい
>>824 俺がダサいだけでhaskellが良くなって実プロダクト出てくるならいくらでもダサくなるわw
>>825 TypeScriptの最近のジェネリクス変態進化ぶりを見ていると
ジェネリクスが正しいという意見も
なんとも言えないかも。
言うほど変態か？
JSによるOOPの実装方法や、即値を型として扱うTypeScriptの特性を十分に理解してないと
new () => Tとかkeyofなんかは分かりにくいかもしれないけど、それはGenerics以前の問題だろ
基本的には必要以上の驚きのない自然な仕様だと思うよ
>>829 それくらいならいいけどさ
https://qiita.com/Quramy/items/b45711789605ef9f96de とか見てみると分かる。
辛いのはユーザ側だとしてもエラーメッセージで巻き込まれることないだよね。
ジェネリクス関連のエラーで一発で問題がわかったことが殆ど無い。
>>830 これくらい何とも思わないな
所詮は型アノテーションを正しく引き継ぐためだけの仕組みだぞ？
生成されたコードをデバッグしなきゃいけないテンプレートとは訳が違う
>>831 こういうエラーメッセージを吐き出すジェネリクスが分かりやすいだって？
![次世代言語Part8[Haskell Rust Kotlin TypeScript] YouTube動画>3本 ->画像>4枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/CTJXwJr.png)
>>832 こういうエラーメッセージと戦うのが辛いのって結局途中経過を追えないってことなんだよね。
goはコードジェネレート前提だったりする。
そっちだと分かりやすいコードを吐いてくれれば追いやすい。
>>833 つまり言語仕様の問題じゃなくてコンパイラが途中結果を出力しないのか問題なんだろ？
MSが改善すれば済む話
完全に論理が破綻してるね
>>832 C++ とて似たようなものだ、ジェネリクスのエラーメッセージは総じて汚らしい
>>834はコンパイルがクソ遅い言語に対しても
問題は言語仕様じゃなくてコンパイラの所為だと思ってそう
>>834 論理がはたんしてるか？
というかコンパイラの挙動と言語仕様を分けて考える意味がわからない。
言語としての素晴らしさはそれを囲むエコシステム全体を含めて語っていいと思うが。
>>836 これ。ジェネリクスは人間に牙を向くのが辛い。ライブラリ開発者でうまくエラーをラップできたりすれば良いんだけどね。
>>832が分かりにくいのって、structual-subtypingで特定のメンバの型に互換性がないのを
「型同士の互換性」の単位で出力してしまってるからじゃないか？
TypeScriptならVSCodeに代入元と代入先の型を展開した状態で比較するビューが付けば解決だと思う
>>840 あと、もしかしてこう書きたかったんじゃなりませんか？ みたいにannotationをコンパイラが出してくれるとかね。
rustってそういう感じだっけ？
ちなみに
>>832 のエラーはTypeScript2.5.3では出ない。2.6以降にすると出るようになる。
コードとしては何の問題もなく動くんだよね。
バージョン上げるたびに修正するのしんどくて放置してる。
そのうちまた型システムだけでチューリング完全になるんじゃねえの？
する必要の無いものをチューリング完全にしてしまったが故にえらいことになったプロジェクト見てきたし、
そもそもコンパイルの時点で無限ループしかねないとかどんな闇言語だよって話になってくるじゃん。
Scalaも型システムだけでコンパイラ止めれたっけ。
c/c++ のヘッダ処理なんかもデバッグしやすくするのとコンパイル効率は
かなりトレードオフがあるってのが一般的。
だから visual studio が内部で変なことガツガツやってるわけで。
そんなもん２、3年本気で仕事すりゃわかることだろうと思うんだが
なぜか理論よりの人間は事実を認めない傾向にある。
チュリ完であることそれ自体が問題なのではなく、デバッグ回りが弱すぎるのが問題なのだ
>する必要の無いものをチューリング完全にしてしまったが故にえらいことになったプロジェクト見てきたし、
それ、「えらいことになった」原因が本当にチューリング完全のせいだったのかね。
少なくともc,c++の依存関係解決の遅さの解決のためにgoが生まれたってのがgoogleの言い分なわけだし、遅いは遅いんじゃないの。
goにプリプロセッサが無いのも意味があるわけで。
ちなみにredoxというrustで書かれたosはコンパイルは早いんだろうか。lunuxと単純比較はできないだろうけども
>>848 そうだよ。何を想像してるかわからんけど。
そりゃチューリング完全であることが問題なんじゃなくてそのチームに問題があったんだろ。
世の中にチューリング完全なシステム(言語)は腐るほどあるわけだし。
なんでも「チームが悪い」と言えばいいのだから簡単だな。ばーか
できちゃうことが問題なんじゃないの
c++の型システムがチューリング完全だと自分たちだけがコンパイル速度に気をつけても
依存しているサードパーティライブラリまでは保証できないでしょ。
だったら言語側で制限がかかっておいてほしいって話。
Cの依存性解決も#ifdefを駆使してプリプロセッサの自由度を持って後付で解決していた。
プリプロセッサ自体便利なものだけど、それが原因でコンパイル速度の低下を招いた。
というのが
>>819 に書いてる。
汎用性がある機能はなんでもできるからこそ、コンパイル速度を落としたり迷惑を書けることも可能。
swiftもGoも後発言語だけどプリプロセッサのってないもの
rustのマクロの自由度は知らんけども。
テンプレートやマクロで無茶をする奴が
コードジェネレータで無茶するようになるだけ
>>856 少なくともGoのgenereateはコンパイル時毎回動くわけじゃないから。
あるC++のファイルを変更したら
そのファイルがincludeした全てのコードを再コンパイルする
型情報のみをincludeすればいいのに型ではない値とコードが大量に入ってる
この値とコードが原因だよね
チューリング完全はそこから生じた結果の一つ
>>853 まあバカな奴をチームに入れないためにc++を採用しないって主張をするリーナスは
ある意味正しいな。
>>858 それはちょっと違う
そもそも今時フルコンパイルなんてそんなに重いものではない
C++がまずいのは、includeしたヘッダのコンパイル結果をコンパイル単位(.cpp)を跨って共有できないことだ
プリプロセッサのせいで毎回変わる可能性があるからな
>>864 リーナスはc++がクソだって言ったんだよ。
その次に使う人間もクソが多いって言ったの。、間違えんな
リーナスはもともとアセンブラーやからのうｗｗｗ
Cは複数のCPUのアーキテクチャーに適応するためにどうにゅうしたわけやしのうｗｗ
c++はいつになったら#importを導入するんだ……
linux もだいぶヘッダマクロでテンプレみたいなことはやってる。
もちろん型安全ではないがそれでもc++のテンプレート使うよりマシという判断をしてるわけだよ。
>>862 メメタァプロプロミングってやつンゴか？
jsのhyperappみたいに300行くらいでreact + reduxなライブラリを作ったように
haskellでも小さなコードですごいことをしてみせる実用ライブラリってあるかな？
jsのhyperappみたいに300行くらいでreact + reduxなライブラリを作ったように
haskellでも小さなコードですごいことをしてみせる実用ライブラリってあるかな？
すごいことってなんだか感情的だな
実用というのも感情かもしれない
コードから改行をスペースに変換して一行にするライブラリーを作ればいい。
プリプロセッサは遅くないぞ
C++のテンプレートやコンパイル時処理のほうがよっぽど遅い
RustもSwiftもプリプロセッサを排除する代わりにC++と同じようなことをやってる
>>877 プリプロセッサが遅いんじゃなくてプリプロセッサに依存したビルドが遅いんだろ
コンパイル単位という時代遅れな概念さえなければ話はずっとシンプルになる
コンパイル単位ってコンパイル高速化するためのものと思ってたんだけど、今は無い方が速いのか？
文字列処理は結果をファイルに保存して再利用しやすい
クラスやオブジェクトの処理はファイルシステムと連携が難しい
かといってファイルシステムがない環境でも動くコンパイラを作る意欲もなさそう
>>877 プリプロセッサが、遅いかどうかはどう作るかによるのでは？
何でもできる分、遅く作り込むことも可能。
だからgoとかは組み込みのimport機能を作ったわけで。
>>875 jsのhyperappに感動してしまったから
感情的になってしまった。
300行でしかも比較的読みやすいコードで
react+reduxなライブラリが作れたことにびっくりしたんす。
勉強用の教材としてもうってつけ。
こういうのが他の言語のライブラリでもないかなと思って。
>>879 ✕高速化
○メモリ節約
今の1/1000のメモリでデカいウンコを無理矢理出すための手法で、今となっては百害あって一理なし
>>883 make -j での高速コンパイルに感動することしきりです、いつか 32thread な CPU を買おうと思っています
なぜかプログラマー板に立って放置されてる
nimのスレ立てるか
boost 大好きな奴がビルドのベストプラクティスとして
1ファイルに全て書く言うてたな。
バカとしか言いようがないが面倒だから黙ってた。
小規模なら1ファイルに全て書いても問題ない
普通に書いたら数百とか数千ファイルになるようなものなら馬鹿で間違いない
インターフェースとその実装とかは、小規模なら同じファイルに書いてるのもよく見かける
世の中にはhaskell使い結構居るっぽいのになんでここには全く居ないんだ
githubやstackoverflowまで行かないと出会えんのか
一つのファイルに書かなくても
複数のファイルをつなげて一つにするプログラム書けばいいだろ
そのやつ馬鹿やんなｗｗｗ
昔の偉い人はトップのファイルにだけインクルードを書く手法をつかったらしいからな。
これは複数のファイルを一つにつなげるプログラムとおなじことやんな。
分割できないのはC++のtemplateだけ
Cは問題ないからほとんどの言語はCのライブラリに依存する
他言語から利用するならさすがにファイル分割せざるをえない
templateって分割できないの？分割してる俺は異端だったか
優秀なコンパイラ使ってるんだな
そのためのexport構文は実装が難しすぎて廃止されたんだ
Vector<T>の内部で無引数のVectorを利用するだけみたいなパターンがある
このパターンに従ってなければ異端視されるリスクはあるだろう
Railsってなんだかんだいって未だに人気があるみたいだけど、
なんでなん？ Rubyって動的言語だよね？ PHPを使ったフレームワークとどこが違うの？
なんであんなに1強状態で人気があるの？
Rubyの魅力とセットで教えてください。
優れているわけではなく、バカチョンで作れるから安易に選ばれやすいのだろう
Railsで始めてみることより、仕様が固まったら次のまともな言語やフレームワークに移行できるかの方が重要
実際、それに失敗（あるいはその必要性すら見越せず）して炎上する案件も後を絶たない
小さくは産めるが大きく育てることはできないのがRails
バカチョンなのはphpじゃなくて？
なんか意識高い系が使ってるイメージなんだけどRoR
ザッカーバーグはphpでボコボコ作ってたんだから作れる奴は作れるんだろ。
>>903 でも言語ごと見直してるよね つ hack
>>899 これに誰もコメントできないということは意識高い系エンジニアはもう2chにはいないってことかな
煽られたのでレスする
>>899 エコシステムが優れているの一点に尽きる
日本語のユーザーが多いので大抵の問題は検索で解決する
とりあえずgem入れれば大抵のことができる
Rubyであることは恐らく関係がない（Rubyの魅力ってなんだろ？ないんじゃね）
このような特長によりラピッドプロトタイピングでは他の追随を許さないため、
早急に成果物が必要なWeb系スタートアップなどでとても重宝される
ユーザーが多くて問題が検索で解決するということは学習コストが低いので、
プログラミングが全くわからないという初心者にも人気
誤解を恐れずに言えば、PHPなどの他の言語のRoRライクなフレームワークは、
Rubyを新たに学習するのを嫌がった既存言語のユーザーのためのパチモンである
次世代言語スレで枯れたスクリプト言語の流行り廃りなんて話題にしたくないって人が多いんだろ
結局javascirptが古いようで最新の技術なんだよね。
>>908 Rubyが嫌いって結局ガッツリハマった人の意見じゃないなぁ。
結局外から観測してる人の意見じゃん。
やっぱりいないんだな。2chには。
ちなみにRubyの良いところって多分プリミティブ型が存在しないことなんかなと
完全に純粋なオブジェクト指向言語を目指したって作者の人も言ってるし。
数字にメソッドが生えているのはたしかにすごいと思った。
>>912 あとElixirはかなりRubyに影響を受けてると聞いた。
だからRubyには魅力があると考えている人は確実にいる。
数字にメソッドといえば Kotlin もそうだな。
>ちなみにRubyの良いところって多分プリミティブ型が存在しないことなんかなと
心の底からどうでもいいわ。
>>915 まぁそうよね。俺もRubyを外野から見てるから、正直それがどうプログラミングに役に立つかわからない。
でも、今もiOS開発でcocoapodsが使われてるなら
あれは設定ファイルがrubyで出来てるはず。(DSLを作りやすい言語だとも聞いた。)
>>909 捨てられない、壊せない、低学歴のゴミ捨て場
池沼保守が更なる池沼保守を招き、公共事業になる
COBOLですか？いいえ、ペチプァです
>>911 https://anond.hatelabo.jp/20170501085956 ＞JavaScriptはDOMを書き換えるためだけに存在している書捨てのクソ言語であって、サーバーサイドを書くために存在している言語でも、100万行からなるバベルの塔の建設に耐えうる言語でもない。
>>918 JSも毎年進化してるしasync-await周りの進化を楽しみにしてます。
array系メソッドのasync-await対応入れて欲しい。
TypeScript全然今現役だし。むしろこれからじゃないの。
結構型定義ファイルを最初から提供してくれるライブラリも増えてきたし。
動的言語の良いところは連想配列と無名関数だぜ
オブジェクトとか参照透明とかいう思想を無視して使うと良い
日本語ですらこうだからな
英語でこれをやられると日本人は詰む
rubyで作ったものといえばhomebrewとかchef、vagrantとか環境構築系統の奴が多い気がする。
でもPHPってなにげに関数型っぽい性質を思ってるよね。
requestを入力にresponseを出力するだけの機能しか作れないわけだし。
ただ言語自体が副作用を許容するのが残念なだけで。
いや関西型でしょ
細かいことはどうでもええねんやで～ って感じ
細かい組み込み関数は暗記しなくていいとPerlの作者は言ってる
でもみんな人の話を細かいところまで聞いてない
そして、組み込み型が存在しない言語があれば完璧に覚えられるんじゃないか
完璧に覚えられないPerlは欠陥品じゃないかと誰かが思いついた
詳細を暗記しなくていいって言い方は何か違うな
全容を理解しなくても使えるみたいな言い方だった
誰も全容を理解できないほどグチャグチャなだけじゃないか？
ゴミの中から使えるものを探し出すマイニング言語だな
機能を詰め込んだ言語はどれも同じようなこと言うが、
あればどっかのバカがドヤ顔で使うもんなんだよ。人が分からないこと機能を使うことがそいつの生きがいだったりするし。
覇権とはつまり無料で伝わってくる評判や情報
たしかにソースコード自体はただでもらえることが多いが
全ての情報が無料になるとは限らない
Dartまだ生きてたんだな
flutterで久々に名前聞いたわ
死産だろ
AltJSはTypeScriptだけでいい
Flowのある今、TSですら要らなくなりかけてるしな
コヒースクリプトとかいう究極の糞ゴミもあったなそういえば
javascriptのpython的な感じのnode.jsが
サーバ側javascriptとかいってわけのわからない何をするものかわからない
説明しかないウェブ上にないから選択肢にならないのが駄目なんだよな。
Dartの戦略はosから全部google製に置き換えるという壮大なものっぽい。
flutterはUI部分はビデオゲームみたいに0から作り直してるからAndroidの断片化問題を回避してる。
結論はdart死んでなかったんや
自社で使ってねえ、いつ投げ出すかもわかんねえプロダクト使えるわけねえだろ
Angularなんて全く自社で使ってないから、案の定グダグダでReact対抗なんか遙か遠く、Vueにすら劣るゴミやン
>>942 わかる
自社で作ったフレームワークを自社が使わないってどうなのよ？って思う
まだベータ版だからとかそれなりの理由があるならともかく、そうでなければ
自分の作ったフレームワークは使うに値しないって言ってるも同然だよな
そんなフレームワークを使う気になれないし趣味以外で使う奴の気が知れない
さすがに手を出しかねるよなあ
flutterに関してはアーリーアダプターさんに頑張っていただいて、僕はレイトマジョリティになるでござる
angularみたいに色々ごった煮するよりか
reactみたいに単なるviewライブラリって割り切ってもらった方が個人的には好みかな。
Googleって社内の開発に関しては保守的な印象
Googleともなると、新しい玩具に飛びつくことが長期的にどれだけの利益または不利益を生むかが定量的に分かってしまうんだろうね
逆に、つかえねえ自社開発ツールを
>>943みたいな理屈で開発環境として現場に押し付けるのもどうかと思うが
公開しないんじゃなくて、できないレベルで使えない、公開したら株価下がるレベルのやつ
ある程度は公開してフィードバック貰わないと腐るよ
>>949 いや、自社開発のクソみたいなツールを使えと言っているわけじゃないんだが…
例えばReactはFacebookが作っていて、Facebookは自社でReactを積極的に利用してるわけだから
そういう開発者自身が積極的に利用してるツールじゃないと魅力を感じないってだけで
あと、公開するなとも言ってないんだが…
自社では利用してないツールなら正式版としては公開するのはどうかと思うってだけで
ベータ版としてならむしろ積極的に公開してほしい
Googleはコード資産が膨大だから全てをAngularに置き換えるのは到底無理な話だが
一部のツール(例えばGmailだけ)を実験的にAngularに置き換えることは可能だろ
でも、それさえ行われてないわけでそんなものを正式版と言われても魅力を感じないと言いたかった
Flutterをとょっと触った感じすごくReactぽい。なんというか今のトレンドはReactに皆寄せるんかな
Closure Library「社内で使ってたら使ってくれるんですか？」
Flutterのチュートリアルを翻訳し始めてみた
https://taiyaq.com/contents/Q2PmOvB1p2yMdH9xxe1JpKL6Jx 手軽に触れる。開発ツールとして悪くない。
vscodeに最初から対応しているのがいい。
>>954 React Nativeの寡占のケツ叩く材料にはいいかもしれんな
それしか価値がないが
覇権言語TypeScriptで作られたVSCodeを使ってDart書いてたら死にたくならない？
AltJS界で覇権
プログラミングエディタで覇権
クラウドプラットフォームでGoogleに圧勝して2番手
.NET Coreもまさかの成功
MSは一時期調子に乗ってMSを馬鹿にしてたWeb系連中を完全に黙らせたよな
結局、所詮Web系は極めて狭い技術領域における開発プロセスの過剰な最適化を競ってるだけで、大した技術はないんだよね
そのWeb系連中のケツ穴舐めて媚びへつらってアヘ顔晒してるM$さんが何だって？
実際、言語設計やシステム設計に関してはMSは群を抜いてると思う
対して、需要を先読みするセンスはGoogleとAppleの方が一枚上手って感じ
まぁ、今のAppleはブランド力だけで需要を強引に上書きしてる感あるが
TypeScriptは確かに覇権ではあるけど
自らにES201X + 型 である。という強い制約を課している。
だからいろいろできたらいいのになって思うけどできない制約が多い。
例えば関数のオーバーロードはできない(宣言はできるけど)。
https://docs.solab.jp/typescript/function/overload/ がっばって実装を工夫しないと読みづらそう。
>>961 今のApple上層部は技術に興味がない感がすごい。
rootパスワードを無視できるバグができたって完全にテストプロセスが旧態依然ってことだろ。
>>965 あのマクロが万能なんでもあり感満載でいいのではないか？
副作用も含めて良い感じ
関数の中に書いたりしたときにスコープ効いてくれると嬉しかったんだが
Cのプリプロセッサはマクロと呼ぶには貧弱で置換表現と呼ぶには強力過ぎるのがなぁ
>>963 普通に関数のオーバーロードできてるやん…
もしかして、オーバーロードが何か理解してない？？
>>969 よく読めよ宣言はできるって言ってるだろ。
エントリーポイントは一箇所に纏める必要があるのが問題だって言ってるの
>>969の理解している「普通の関数のオーバーロード」を説明してもらった方が面白いと思う
>>970 エントリポイントが1箇所にまとまってるとオーバーロードじゃないの？
>>971 ポリモフィズムのバリエーションで、ユーザーコードから、別シグニチャに同じメッセージタグで呼び出せるものだと思ってるが
実装が大変かどうかと、オーバーロードが実現できるかどうかを同じにしてることに違和感があっただけだよ
ID:mBYt1wWZが大変だと思ってる事実を否定するものではない
マクロはDOM操作かPHPに似ている
ただしweb系が戦国時代だとしたらcppは覇権江戸幕府
オーバーロードの宣言を一箇所にまとめないといけないというのは改造ocamlのG'Caml等もそうだったな
その方がコンパイラは楽なのもわかるけど、実用しようと思ったら別々の場所で宣言できないと
用を為さないというのもわかる
＞ポリモフィズムのバリエーションで、ユーザーコードから、別シグニチャに同じメッセージタグで呼び出せるものだと思ってるが
特段反論というわけでもないけど:
シグネチャというのはそもそもメッセージタグが同一でも型や引数の個数で別になる
つまりそれはシグネチャの定義に過ぎない
シグネチャが別になった結果同じ名前で別のもの(関数定義など)が参照されるのがオーバーロード。
TypeScriptは型情報についてはオーバーロードが行われるが、
実装の参照については(ECMAScriptとの互換性のため)オーバーロードが行われない、
みたいに理解している。
次スレからPart表記なくせば、もっと詰め込める
この形ならElmかNimがはまるな
次世代言語9[Go *** Rust Swift Kotlin TypeScript]
でも文字数ギリだから、次次スレからまた変えることになる
括弧をなくせば使えるが
次世代言語10 Go *** Rust Swift Kotlin TypeScript
>>976 そもそも言語をスレタイに入れなければ良いのでは？
別に引っかからなくていいよ。
誰がそこまでこのスレを重視してんの？
>>978 引っかかったところで大してその言語の話してねえようなスレなんだぜ。
Kotlinなんて十レスもない。
引っかかること自体詐欺的。
次世代言語と言えばsmalltalkだろ
もっとsmalltalkの話しようぜ！
申し訳ないがジョブズに自慢していいとこ取られて死んだ言語はNG
あえて言おう
パクられることなくSmalltalkに残った機能なぞカスであると
イメージベース然り、become:然り
なんでDart2なんか出しちゃったんだろな
ひょっとしてグーグルって俺よりバカなんじゃないか？
俺だったらGo使うわ
いやホント、俺がプロジェクトマスターやってあげたほうがいいんじゃないか？って。
心配になってくるよな、最近のグーグルは、困ったもんだよ
>>986 goはなんか違う気がする。
今のgoでGUIフレームワーク作ったらinterface{}だらけになる予感しかない。
GoにGUIは明らかに不得手。
俺画面周りはHTMLとCSSで書いてるわ。
gopherjs使うと思ったよりブラウザ側でも色々させられるし。
あれ面白いぞ。
どっちかというと比較対象はTypeScriptなんじゃないかな。null安全だったりasync awaitあったり共通点は多い。
でも、jsの仕様を引きづる言語仕様だから、そういう後方互換性を考慮しなくてもいいDartってことなんじゃないか。
google社内でも使われてるみたいだし。
flutterもreactユーザーにはしっくりきやすい。俺はTypeScript+React大好き派だから
かなりいい感じ。
チュートリアルもdartを知らんでも触れるようにできてて分かりやすい。
>>981 笑えたわww。
対照的に何度も出てくるみんなのアイドル某ボケ担当言語を外してるあたりも、
個人的怨嗟が垣間見える。
次世代言語9[Haskell Rust Kotlin TypeScript Dart]
http://2chb.net/r/tech/1520298555/ flutterってどんなアーキ使えばいいの？
reactと同じだからflux?
>>994 flux自体がReactの延長上の思考法なわけだから。
基本は極力Stateの管理をするコンポーネントを一箇所に集めろって話。
flutterもおんなじだろうね。
詳しくはReactの考え方でググってみ。
lud20250108212639ncaこのスレへの固定リンク： http://5chb.net/r/tech/1512137301/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「次世代言語Part8[Haskell Rust Kotlin TypeScript] YouTube動画>3本 ->画像>4枚 」を見た人も見ています：
・次世代言語9[Haskell Rust Kotlin TypeScript Dart]
・次世代言語議論スレ[Rust Kotlin Haskell]第6世代 [無断転載禁止]
・次世代言語議論スレ[Go Rust Scala Haskell]第5世代
・次世代言語議論スレ[Go Rust Kotlin Scala]第4世代 [無断転載禁止]
・【Nexusから】次世代Google端末を語るスレ Part15【Pixelへ】 [無断転載禁止]
・次世代言語14 Elixir Crystal Julia Rust Swift
・【Nexusから】次世代Google端末を語るスレ Part14【Pixelへ】
・【PS5】RDNA2X SIE次世代機予想スレ HWRT 高速SSD 91世代目 【PS5PRO】TFLOPSだけでは語れない
・【乃木坂46】山下美月＆与田祐希、超キュートな「次世代エース」コンビがヤンマガ登場！タンクトップ＆ショートパンツ姿で美肌披露
・【終戦】著名リーカー「次世代XBOXよりPS5の方が性能上」「次世代XBOXはメモリが少ない」【Scarlett】
・Xboxの開発者、Project Scorpioは「本格的な次世代機」になると発言 [無断転載禁止]
・【Scarlett】 Xbox次世代機はCSのパワー、スピード、パフォーマンスの新たな基準を打ち立てる製品 ★9
・【Scarlett】 Xbox次世代機はCSのパワー、スピード、パフォーマンスの新たな基準を打ち立てる製品 ★16
・【Scarlett】 Xbox次世代機はCSのパワー、スピード、パフォーマンスの新たな基準を打ち立てる製品 ★13
・【Scarlett】 Xbox次世代機はCSのパワー、スピード、パフォーマンスの新たな基準を打ち立てる製品 ★12
・【Scarlett】 Xbox次世代機はCSのパワー、スピード、パフォーマンスの新たな基準を打ち立てる製品 ★11
・【速報】次世代Xbox「Scarlett」はZen2、Navi、GDDR6、カスタムSSDで最高品質の次世代ゲーム機に★6
・【Type-C】USBの次世代仕様「USB4」が発表。Thunderbolt 3ベースで最大転送速度は40Gbpsに
・【次世代通信規格】LTE and Others 総合スレ 84
・【車】ホンダ、AIを持つ次世代スポーツEV「Sports EV Concept」東京モーターショー2017で世界初公開 [無断転載禁止]
・【正規スレ】【PS5】RDNA2X SIE次世代機卵zスレ HWRT 高速SSD アンチ出禁 83世代目 【PS5PRO】
・【速報】次世代Xbox「Scarlett」はZen2、Navi、GDDR6、カスタムSSDで最高品質の次世代ゲーム機に★4
・SKE本スレがウッキウキでスケジュールに「CDTVライブ！」を書いたのに、SKEから次世代選抜ゼロだったというエピソードが何回みても面白い
・【Scorpio】次世代ゲーム機テクノロジースレ 【TegraX3版Switch 】
・【初音ミク】グッドスマイルカンパニーが次世代型飛行フィギュア「ねんどろーん」を発表！あの「ねんどろいど」がついに大空へ！動画有り [無断転載禁止]
・【次世代スピーカー】透過スクリーンに動く歌詞を表示「Lyric Speaker」発売 [無断転載禁止]
・【PS4で出ない】The Elder Scrolls VI発売は次世代機と判明
・【乃木坂46の次世代エース】「美少女」5期生・井上和（17）の圧倒的な存在感と透明感！グラビア登場 キュートなセーラー服姿披露 [ジョーカーマン★]
・PS5独占「Astro's Playroom」驚異の次世代グラフィックを僅かロード6秒で実現
・【PS5】RDNA2X SIE次世代機予想スレ HWRT 高速SSD アンチ出禁 84世代目 【PS5PRO】
・【PS5】RDNA2X SIE次世代機卵zスレ HWRT 高速SSD アンチ出禁 80世代目 【PS5PRO】
・PS5独占「Astro's Playroom」驚異の次世代グラフィックを僅かロード10秒で実 Part2
・【Pro】【Switch】 次世代ゲーム機テクノロジースレ No.6【Scorpio】 [無断転載禁止]
・一人で行く次世代ワールドホビーフェア '18 winter in幕張メッセ
・次世代XBOX『Scarlett』、2020年に従来型コンソールとクラウドコンソールの2種類を発売か？
・次世代たばこ「三つ巴の戦い」 JT反撃なるか？【iQOS/ploom tech/glo】
・任天堂の次世代ゲーム機 Nintendo Smart、「すでに量産開始されている」とWSJが報道
・【非正規３１７万人 フリーター５２万人 ニート４０万人世代】就職氷河期世代の就労支援、人材派遣会社に国が委託へ ★６
・【米】わずか５秒で時速３１０ｋｍ到達 次世代交通システム「ハイパーループ」、真空チューブでの高速試運転に成功（動画あり） [無断転載禁止]
・【Switch】 次世代ゲーム機テクノロジースレ 【Scorpio】
・マイクロン広島新工場が完成、次世代DRAMとSSDを量産、韓国へのフッ化水素の輸出規制とは一切無関係
・【芸能】将来メチャ怖くなりそう！次世代ご意見番ランキング 有吉弘行、指原莉乃、ミッツ・マングローブ、加藤浩次 など [無断転載禁止]
・8/10(月)夜7時からのCDTVSPに出演する「AKB48グループ CDTVスペシャル次世代選抜」のメンバーを予想しよう！★1.2【夏ソングSPメドレー】
・ATLUS「CATHERINEはファミコン世代向けに作った。エロ目的で買ったガキには難しいと評判が悪かった」
・【非正規３１７万人 フリーター５２万人 ニート４０万人世代】就職氷河期世代の就労支援、人材派遣会社に国が委託へ ★１１
・Sony Mobile 次世代Xperia 総合228
・有機ELさえ置き去りにする次世代液晶 パナソニックがメガコントラスト液晶の詳細を発表
・Sony Mobile 次世代Xperia 総合188
・【車】トヨタ、新型車JPN TAXIを発売 日本の「おもてなしの心」を反映した様々な人に優しい次世代タクシー
・Sony Mobile 次世代Xperia 総合168
・Sony Mobile 次世代Xperia 総合181
・Sony Mobile 次世代Xperia 総合228
・Sony Mobile 次世代Xperia 総合148
・【非正規３１７万人 フリーター５２万人 ニート４０万人世代】就職氷河期世代の就労支援、人材派遣会社に国が委託へ ★7
・NEC PC、次世代ゲーム機「Project Engine」を発表
・【音楽】SEKAI NO OWARI、映画『進撃の巨人』主題歌「ANTI-HERO」MV解禁！これがナウい世代に好かれる邦楽！
・【非正規３１７万人 フリーター５２万人 ニート４０万人世代】 就職氷河期世代の就労支援、人材派遣会社に国が委託へ★３
・【PC】AMD、「Spectre」対策で次世代チップ「Zen 2」の設計を変更
・次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】
・【軍事】スウェーデンの次世代戦闘機「グリペンE」が初飛行に成功、スウェーデン空軍やブラジルが採用 サーブ社 [無断転載禁止]
・【PS5】情報解禁 SIE次世代機予想スレ 【携帯機&PSVR2】 逆襲の38世代目
・次世代XBOX、ロックハートの低価格版が7Tflopsから8Tflopsに底上げか！？
・クビレ担当牧野・爆乳担当羽賀・ケツ担当横山・意外性担当加賀・次世代エース北川←モーニング娘。 のグラビア班ってもうこの5人でよくね
・Sony Mobile 次世代Xperia 総合235
・ハロプロ次世代エースは誰か？北川莉央、山﨑愛生、伊勢鈴蘭、松永里愛、河西結心、豫風瑠乃、山﨑夢羽、米村姫良々
07:26:39 up 27 days, 17:50, 1 user, load average: 7.68, 8.55, 8.86
in 2.7279670238495 sec
@0.089956045150757@0b7 on 010821
|
![次世代言語Part8[Haskell Rust Kotlin TypeScript] YouTube動画>3本 ->画像>4枚](http://arison.jp/wordpress/wp-content/project_comedy_l.gif)
![次世代言語Part8[Haskell Rust Kotlin TypeScript] YouTube動画>3本 ->画像>4枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/WlyRTkz.jpg)
ブックマークへ