X

次世代言語Part8[Haskell Rust Kotlin TypeScript]

■ このスレッドは過去ログ倉庫に格納されています
0044デフォルトの名無しさん
垢版 |
2017/12/02(土) 13:37:18.57ID:72s6oBNC
結局このスレの住民も、ジョブスの作った快適な牢獄で永久に囚われる方がお好みってか
ほんとディストピアになったな
0045デフォルトの名無しさん
垢版 |
2017/12/02(土) 13:40:52.41ID:72s6oBNC
>>41
HaskellはともかくGoやRust、Typescriptは研究機関の成果物じゃなくて単なる企業の広告塔だろうが……
0046デフォルトの名無しさん
垢版 |
2017/12/02(土) 13:44:29.43ID:Jtrxh33g
成果物ではなくて広告塔でもなくて自社製品を作るためにできた副産物だろ。
0047デフォルトの名無しさん
垢版 |
2017/12/02(土) 13:54:09.27ID:TzW9B0ui
Rustが研究しているのはジョブズではなく静的型付け
牢獄になるとすれば静的型付けが牢獄になるんだよ
0048デフォルトの名無しさん
垢版 |
2017/12/02(土) 13:55:36.52ID:pAxOhb0h
>>44
>結局このスレの住民も、ジョブスの作った快適な牢獄で永久に囚われる方がお好みってか
>ほんとディストピアになったな

あ、ガイジというよりはキチガイのひとだったか
0049デフォルトの名無しさん
垢版 |
2017/12/02(土) 13:58:37.03ID:pAxOhb0h
>>47
>牢獄になるとすれば静的型付けが牢獄になるんだよ

一部のLISPer除いてRustの型システムでは型が付かない正当なコードが書きたいのに書けない！なんてやつ殆どいないだろ
0050デフォルトの名無しさん
垢版 |
2017/12/02(土) 14:36:48.87ID:TzW9B0ui
静的型付けはQBみたいな奴だ
牢獄と契約は似たようなものと思うか全然違うと思うかは人それぞれ
0051デフォルトの名無しさん
垢版 |
2017/12/02(土) 15:29:44.21ID:JadDCVYU
じゃあどんな言語が好きですか？なぜその言語が
良いと考えるのですか？と聞くとダンマリ。
0053デフォルトの名無しさん
垢版 |
2017/12/02(土) 16:02:09.41ID:ugnQ3p4B
>>38
ソース読めれば、ブラックボックス化は
防げるんじゃないの？

あなたが上げてるライセンスで、
ソースを読んではダメってモノは
ない気がするんだけど。
0055デフォルトの名無しさん
垢版 |
2017/12/02(土) 16:25:11.46ID:Dl6HEW0V
厳密に言えば配布されているソースと配布されているバイナリが違う可能性は存在するけどな
わかりやすい罠でも仕込まれてない限り検証不可能だろ、GPLであっても
0056デフォルトの名無しさん
垢版 |
2017/12/02(土) 17:35:29.54ID:/D9bpJpS
ライセンスは個人ならMIT、企業ならApacheが主流
緩いライセンスの上で企業が主導するというのが、昨今のオープンソース界隈
オープンソース同士の競争や発展が当たり前になって、落ち着くべきところに落ち着いた

GPLの衰退、寛容なオープンソースライセンスの興隆
https://japan.zdnet.com/article/35058087/
http://redmonk.com/sogrady/2014/11/14/open-source-licenses/

http://redmonk.com/sogrady/2017/01/13/the-state-of-open-source-licensing/
http://redmonk.com/sogrady/2017/09/22/cloud-native-license-choices/
0057デフォルトの名無しさん
垢版 |
2017/12/02(土) 17:48:55.03ID:wMBa/T9i
>>53
GPLでない限り、どこかの瞬間にソースをクローズドにできてしまう
その違いくらい分かっとけ

>>56
そういうものは単にソースが公開されているだけで、企業にとって都合の悪いコードは入らない
開発姿勢の問題
0059デフォルトの名無しさん
垢版 |
2017/12/02(土) 17:54:42.99ID:8J+E3A3v
クローズドにされた派生物は元のオープンソースにその企業なりの変更を加えたものだろ。
他の人はクローズドにされる前のオープンな方を使い続ければいいだけ。
0060デフォルトの名無しさん
垢版 |
2017/12/02(土) 18:00:12.16ID:wMBa/T9i
>>59
元コードのライセンス自体を変えられたらアウト。MITやAPLなら不自由なライセンスに変更することが可能
GPLならそういうことは不可能
0061デフォルトの名無しさん
垢版 |
2017/12/02(土) 18:05:29.89ID:9Vn/PEwl
今時、GPL真理教のご登場とは、驚きだな。
そういう人は、次世代言語がgccに組み込まれるまで、待ってたらいいと思うよ。
0062デフォルトの名無しさん
垢版 |
2017/12/02(土) 18:22:10.64ID:8J+E3A3v
新しく配布するライセンスを変更することはできても、一旦ライセンスされたものを過去に遡って
変更するなんてことはそのライセンス自体にそのような規定がない限り無理。
新しく配布するライセンスを変えるって話なら(その権利がある者なら)元がGPLだろうが可能なのは同じ。
0063デフォルトの名無しさん
垢版 |
2017/12/02(土) 19:42:01.02ID:H6Gj4fb5
GPLも違反の場合の措置は国の法律に従うとかそんな規約だった気がするから、
国によっては過去に遡って棄却とかあるんじゃねーの？
0064デフォルトの名無しさん
垢版 |
2017/12/02(土) 20:00:19.24ID:JVkL85Me
言語屋の端くれって何者なんだ。
工学博士の端くれぐらいまではギリギリ言ってみようかとも思えるけど、言語屋って凄いな。
0065デフォルトの名無しさん
垢版 |
2017/12/02(土) 21:01:20.98ID:JadDCVYU
こんなところで喚くしか能のないゴミ屑が
ライセンスうんぬんで不利益被るほどの立場なわけないだろ
大人しくプェチピィで下痢糞プリプリしてろよ
0067デフォルトの名無しさん
垢版 |
2017/12/02(土) 21:16:27.51ID:vrpISaZz
OOを批判するのはいいけど消去法で関数型とか思うのは大間違い
消去法するくらいなら対案を何も出さない方が正しい
0069デフォルトの名無しさん
垢版 |
2017/12/02(土) 23:58:45.47ID:IJ6GXagf
redux（react）触ったやつがelmに流れてるんだろうな。

js+redux+immutable.jsの組み合わせだったらelmってことかね
0070デフォルトの名無しさん
垢版 |
2017/12/03(日) 02:09:05.69ID:Ct3m3qtO
「じゃあお前はどんな言語なら満足なんだ」ってしつこく聞かれてるから言うが
次世代言語かって言われたら微妙だからあんま挙げる気はなかったんだが、理想はVala
Cにトランスパイルされるから速度は良好、コンパイラのライセンスはLGPL、構文は比較的モダン

ただ今時の他言語と比較するともう一声ほしい
0072デフォルトの名無しさん
垢版 |
2017/12/03(日) 09:08:16.53ID:J28DlChh
GNU狂儲じゃない人にとってはValaなんてC#の劣化コピー未満だし、
C#は現世代言語だから次世代には不適格だろう
0073デフォルトの名無しさん
垢版 |
2017/12/03(日) 12:08:02.85ID:7jfP6ZRC
その性能を見せてくれたら変わるかもしれんけどな
.NETのメモリを食い尽くす糞戦略GCが無いというならまあ……

Cにトランスパイルされて性能良好という点ではnimと丸かぶりな上
基本的にnimのほうが融通がききそうな気はするけど
GObject互換が有利に働くケース(例えばcairo呼ぶとか)ではValaの方がいいんだろう、たぶん、知らんけど
0074デフォルトの名無しさん
垢版 |
2017/12/03(日) 15:33:23.03ID:Es8BrMdC
まあだからValaが次世代言語とは一言も言ってない
例えばNimのコンパイラが(L)GPLになってくれてれば全力で推すよ。でも現実はMITだ
0075デフォルトの名無しさん
垢版 |
2017/12/03(日) 16:03:56.50ID:Cfl2NYpj
>>60
Linuxなど極一部の例外を除いて、今時のまともなOSSは基本的に全て企業様が開発しており、
寛容にも乞食に対して提供してくださっているものである
GPL信者が主張する、企業が成果物をGPL化するメリットとして、
「コミュニティからの協力を受けられる」というのがあるが、(乞食共の協力がどれだけ役に立つかは別として)これには落とし穴がある
GPLで公開してるものに対して乞食がプルリクを出し、これが本家にマージされた時点で、本家のソースがGPLに感染するということだ
これは企業にとって到底受け入れられるものではない
GPLは企業のオープンソースへの参加の障害になるんだよ
0076デフォルトの名無しさん
垢版 |
2017/12/03(日) 16:11:23.39ID:Cfl2NYpj
>>75
補足
本家のソースがGPLに感染するというのは、開発元の企業自身が、ソースの使用にあたりGPLに従わなければならなくなるという意味な
成果物をドブに捨てるようなもんだ
0077デフォルトの名無しさん
垢版 |
2017/12/03(日) 16:16:53.98ID:ySR1wv1e
そういうものはデュアルライセンスで公開するんじゃないか普通。知らんけど。
0078デフォルトの名無しさん
垢版 |
2017/12/03(日) 16:17:53.46ID:LB13FI05
逆に考えれば自分がただで作ったものが企業の金もうけに使われるのを防いでるわけだろ。
そういういみでGPLは必要。
0079デフォルトの名無しさん
垢版 |
2017/12/03(日) 16:32:50.74ID:Cfl2NYpj
>>78
そう。つまりこういうことだ。
ユーザーからのコミットを受け入れるというポジティブな理由でオープンソースを採用するならGPLは不適切。
オラクルのように、有償契約への誘導を前提としてオープンソース版を撒き餌にするなら、
成果物の盗用を防ぐ意味でGPLが適切。
本来OSS信者が批判すべきなのはどちらだろう？
一度落ち着いて考えてみよう。
0080デフォルトの名無しさん
垢版 |
2017/12/03(日) 16:46:21.13ID:Es8BrMdC
だから「自由ソフトウェア」と「オープンソースソフトウェア」は違う概念って話だよな
そもそも企業が主導してる開発は、企業の恣意が入るわけで、自由ではない
今は乞食に恵むことが点数になるからそうしてるだけ
乞食に甘んじるならそれでいいかもしれんがな

一念発起して自分の畑を開墾することになったときに、GPLがないと企業に土地を盗まれたり、いつのまにか乞食に占拠されたりするんだよ
だからGPLの言語は重要なんだよ
0081デフォルトの名無しさん
垢版 |
2017/12/03(日) 16:47:34.26ID:Cfl2NYpj
もっというと、
・プロジェクトにコミットした個人乞食にとって、そのプロジェクトの最新の成果物を継続的に利用できる利益を守るのがGPL
・開発元の企業にとっての利益を守るのが「寛容なライセンス」
ということだ。そして、下記の理由から、後者を優先したほうがOSS全体にとっての利益が大きい。
・一般に、個人より企業の方がOSS遥かに多くの貢献をしているから、企業の参入を促したほうがOSSは拡充する
・当たり前だが、利用者にとっては寛容なライセンスの方が利用しやすい
0082デフォルトの名無しさん
垢版 |
2017/12/03(日) 16:50:27.91ID:MdLc4Lg3
>>78
別にGPLは金もうけに使うことを防ぐためにあるわけじゃないよ。
実際、金もうけだろうがなんだろうが単純使用については制約を設けることを禁止してるわけだし。
0083デフォルトの名無しさん
垢版 |
2017/12/03(日) 16:52:07.39ID:dv78RNI3
個人で出来る開発なんて限られてるから企業が参入してくれたほうがいいし、企業は慈善団体じゃないんだから利益考えるのは当然だろ
企業がーステマがーって気持ち悪すぎる
0084デフォルトの名無しさん
垢版 |
2017/12/03(日) 16:54:31.97ID:dv78RNI3
これだからワッチョイつけろと言ったのに
0086デフォルトの名無しさん
垢版 |
2017/12/03(日) 17:00:11.80ID:Q+UzJ2jP
わざわざ次世代言語スレに来て、
「俺ルールにより、全ての言語は次世代ではない！！」

ってマ？
0087デフォルトの名無しさん
垢版 |
2017/12/03(日) 18:06:19.80ID:vwbP6I+a
GPLは自分が作ったものだけじゃなく使ったものにも影響を及ぼすからなあ
LGPLが一番マトモなんじゃないかと思ってるんだが
0088デフォルトの名無しさん
垢版 |
2017/12/03(日) 18:39:22.73ID:sBoz0VTg
>>81
OSSが拡大しても自由ソフトウェアは拡大しない

まあ言語スレでやるべき話題ではそろそろなくなってきてるのはすまん
0092デフォルトの名無しさん
垢版 |
2017/12/03(日) 19:07:55.59ID:fDoYnNZt
>>19
まあ、大企業がサポートしてるからこそ信頼性が増すんだけどね。
弱小勢力の作ってる言語なんざいつやる気が無くなってサポート停止するかわからんのに
使ってられないよ。
0093デフォルトの名無しさん
垢版 |
2017/12/03(日) 20:15:24.10ID:GYPu5Uwk
サポートを永久に続けさせたいとは思ってないんじゃないかな
ただ、無料版だけサポート停止して有料版に移行させる手口を防ぐだけでいい
0094デフォルトの名無しさん
垢版 |
2017/12/03(日) 20:40:28.46ID:T5z0rd35
このガイジの言葉を全否定するが、別に言語の処理系のライセンスがGPLだろうと非GPLだろうと
その言語で書かれたプログラムのライセンスには何も影響しない
Javaの処理系がクローズドソースだった時にJavaコードがオープンソースにできなかったかってことを考えればすぐ分かる

言語の仕様がオープンなら、もしこのガイジの懸念どおり処理系をオープン→クローズドソースにされたところで
本当にその言語が有用だったらクローンの処理系が出てくるだけのこと。open-jdkやらmonoが良い例だ

要するにこのガイジ、ライセンスのことを何も分かってない知ったか
0095デフォルトの名無しさん
垢版 |
2017/12/03(日) 20:46:25.36ID:T5z0rd35
ガイジを殴るだけのレスだと何なので
Haxeみたいな「書いた端からあらゆる言語にトランスパイルして使う言語」ってやっぱりコンセプトとして駄目なのかね？
最近のいわゆる次世代言語って、おおむねネイティブ（もしくはJavaマシンコード）にコンパイルする系ばっかのはず
例外はTypescriptとHackくらいか？
0096デフォルトの名無しさん
垢版 |
2017/12/03(日) 20:55:26.88ID:GYPu5Uwk
93,94をまとめると
GPLなコードを再利用しつつ有料版に移行させるのは無理
コードを捨ててクローンするならOK
0097デフォルトの名無しさん
垢版 |
2017/12/03(日) 21:05:47.23ID:RLNGue2S
>>94
Javaに関しては、openjdkを勝手にフォークして改変したものを出回らせたら特許侵害でオラクルに訴えられるよ
特許の利用はあくまで公式にリリースされたopenjdkに対して認められてるもので、
弄ったらJavaとは認められなくなり即訴訟
0098デフォルトの名無しさん
垢版 |
2017/12/03(日) 21:19:08.36ID:T5z0rd35
>>97
すまん、open-jdkっていうのは不正確だったな。IcedTeaって言った方が正確だった
まあ厳密にはIcedTeaも当時のSunの協力あってのことで、勝手フォークでやった訳ではなかったんだが……
0099デフォルトの名無しさん
垢版 |
2017/12/03(日) 21:19:33.27ID:7jfP6ZRC
>>95
中間言語のせいで遅くなってる直接アセンブリ(機械語より広い意味で)にできるなら効率的なのにグギギギギ
というのを気にしなければトランスパイラでもいいんじゃね
Typescript→Javascriptぐらいなら気にならんだろ
Scalaとか思いっきりJVMに足を引っ張られてた例と思う

ちょっと話は違うけど可変長配列を値返しできる言語を主にC系のことしか考えてないバックエンドで実装すると
mallocして返すかForthみたいにデータスタックをもう一つ用意するかぐらいしか方法がない、みたいな
0100デフォルトの名無しさん
垢版 |
2017/12/03(日) 21:29:59.69ID:7jfP6ZRC
書いてからもっといい例を思いついた
トランスパイル先に選ばれそうな言語(CとかJVMとかJavascriptとか)って
どれも末尾呼び出し最適化が保証されてないから関数型言語なら避けたいはず
0101デフォルトの名無しさん
垢版 |
2017/12/03(日) 21:51:34.72ID:XVQ9VXzY
末尾再起最適化なんかトランスパイルの段階でできるだろ
自分でやってみりゃわかるけど、別の言語への変換って細かい仕様のすり合わせが難しくて
どう頑張っても変換結果は綺麗なコードにはならんよ
0102デフォルトの名無しさん
垢版 |
2017/12/03(日) 22:16:35.41ID:7jfP6ZRC
>>101
自身への末尾「再帰」は変換できるが、末尾「呼び出し」一般はかなり難しい
特にモジュールをまたぐとまず無理
0105デフォルトの名無しさん
垢版 |
2017/12/03(日) 23:20:51.54ID:8Yd/vHN3
トランスパイルする時点で全部gotoにしちゃえばいいんじゃねえの？
ヒープは馬鹿でかい配列切り出して貸してやりゃ良いじゃん。
一番現実的だと思うけど。

と言うか間違えられてかわいそうだな。
0106デフォルトの名無しさん
垢版 |
2017/12/03(日) 23:24:33.80ID:8Yd/vHN3
トランスパイラだから、トランスパイル先の言語の作法を守らにゃならん、なんてトランスパイラは
どっちつかずのゲテモノになるなんてのが歴史的にある程度わかってきたんだから、諦めて超高級マクロアセンブラとして使うべきだと思うが、
やっぱそのトランスパイル先の美しさって必要なのかねぇ。
0109デフォルトの名無しさん
垢版 |
2017/12/03(日) 23:52:53.39ID:7jfP6ZRC
>>105
ありがとうありがとう

で、goto式だと呼び出し先も含めてひとつの関数にまとめないといけないので
他の関数をtail callしているのがつながって爆発的にコードサイズが膨れ上がる
JVMだと64kbの壁があるとかないとか ttps://togetter.com/li/280057
またモジュールを超えるとアクセス制御にかかったりもする
0110デフォルトの名無しさん
垢版 |
2017/12/03(日) 23:52:56.38ID:H7G92E6b
>>100
javascripというかecmascriptは末尾再帰の最適化は仕様になってる。
0112デフォルトの名無しさん
垢版 |
2017/12/04(月) 04:42:05.46ID:76LtUM8J
Cにはlongjumpがある。
これを使えば親の関数へどこへでも飛んでいける。
末尾再帰もオプションで設定できる。
0113デフォルトの名無しさん
垢版 |
2017/12/04(月) 08:25:09.89ID:USho8dw3
>>109
JVMだとgotoが相互に飛んでない奴らで一つの関数にまとめるしかないな。
ただ、一つの関数が64kbまで、ってそこそこ余裕あると思うよ。
関数に関数をおさめようとするから爆発的に長くなるというか、実質、関数の後ろにおまけ付いたコードが量産される事になるんだと思う。
呼び出してる側まで全部展開してしまうと割と短くなる。

昔、ホントにそういうトランスパイラ作ったけど、割としっかり動いた。
動的なメモリ確保をほとんどさせられなかったからそうなっただけだけど。

>>112
ホントに高級アセンブラだよなぁ。
0115デフォルトの名無しさん
垢版 |
2017/12/04(月) 09:02:24.71ID:dvJUWhXs
jsへのトランスパイラは現状、
jsが、webにおける機械語的な立ち位置
だからというのはわかる。

でもcへのトランスパイラってどんな意味があんの？手抜きとしか思えない。
0116デフォルトの名無しさん
垢版 |
2017/12/04(月) 09:38:18.50ID:76LtUM8J
手抜き出来ることはメリットだろ。
実装と仕様は分けて考えるべきだからな。
0117デフォルトの名無しさん
垢版 |
2017/12/04(月) 10:10:11.02ID:1pGzw3aP
手抜きっつーか、Cに変換しておけば、おおむねどんなlibcでも石でも対応するコンパイラがあるってことでは

GoみたくあらゆるものをGo内で完結させるための車輪の再発明だとか
Rustみたく欲しい環境のtripleがあるかとかtierがいくつだとか
そういう言語機能と直接的には関係ない部分のサポートに関する労力をまるっと切れるのがでかい

一時期のaltJavaやaltJSの乱立を見てると、その分言語の質が上がるかって言われたら怪しいけどな

あとllvmの台頭で、ある程度その辺を再利用できる環境が整ったから、直接機械語吐いた方がよくなりつつあるのもあるか
0118デフォルトの名無しさん
垢版 |
2017/12/04(月) 10:54:56.82ID:dvJUWhXs
>>117
自分で言ってんじゃん。
llvmだったら中間コードまでのトランスパイラ作れば最適化とバイナリはくまでやってくれるしそこまでやりゃ良いのに。

あとgoの車輪の再発明はありだと思う。
画像変換したくてimagemagicのlibに依存する羽目になるとか勘弁。
0120デフォルトの名無しさん
垢版 |
2017/12/04(月) 11:02:26.62ID:USho8dw3
>>115
最適化とかそういう所にそれほど苦労しなくなるかな
手抜きといえば手抜きなんだけど

gccをバックエンドにするなら変な石対応が簡単だし
vc++でも食えるように書けばWindowsでも余計なもの要らないし
intelのコンパイラでゴリゴリに最適化かけたりとか、
静的ビルドでワンバイナリ作りたいからCの方のコンパイルオプションでリンクしよう、とか
既存の処理系に乗っかるのはメリット多いと思う
0121デフォルトの名無しさん
垢版 |
2017/12/04(月) 11:39:21.16ID:1pGzw3aP
>>118
llvmが台頭してきたから相対的にCトランスパイルの魅力なくなってきたよなって話で、
昔はCトランスパイラで既存のコンパイル環境に乗っかるのがよく行われてたって歴史的な話な

gccが中間言語仕様を意図的に隠してた弊害とも言える
0123デフォルトの名無しさん
垢版 |
2017/12/04(月) 23:23:47.01ID:IjdODrQV
実質的にはトランスパイルだろうが何だろうが、とりあえずは関係ないが
今時ライブラリ構築を0からするというのは自分一人が使う自分専用言語だと考えても
汎用言語としてはあり得なくて、何か既存の言語のソレにフリーライドせざるを得ないわけで
となれば何に乗っかるかという部分から考えるし
それが決まってから具体的な実装方を考えるし、なんだったら自動的に決まってくるわけで

余談だが、良くある乗っかり先としては、CとJavaと.NetとJSがあるが・・・
ただ、例えばネイディブコードが良いと考えてC言語系のライブラリに乗っかるとして
C言語のABIはかなり古臭いわけで、あと、ヘッダファイルの存在がかなりエグイわけで
(windows.hをそのまま読み込める自作コンパイラとか書ける気がしない)
その言語で何かCのライブラリを使いたいときCヘッダファイルを適切に移植したのち
使いやすくするためにラッパークラスまで書くとしたら
これはもう多少気に入らない部分があってもC++を使ったほうが楽だし
ヘッダを移植するツールで自動生成する方針でも古臭いCのAPIを直接叩くのなら
何のための新言語か分からないし、だからといってラッパー書くのはバカらしいし
大概のCライブラリにはC++のヘッダも付いてることを考えるとそのままC++使ったｂﾙうがマシ
もしC言語のヘッダを直接読めるように言語を設計するとなるとマクロなども考えると
C言語と文法的に互換性が有るように言語を作らなければならないということで
これまたあまり作る意味が無い、というか多分C++
0124デフォルトの名無しさん
垢版 |
2017/12/04(月) 23:36:03.78ID:IjdODrQV
なんで、素晴らしい言語仕様を考えることは出来るかもしれないし
頑張ってコンパイラを作ることも可能かもしれないが
結局ライブラリをどうするのかという部分が一番の問題で
0から構築するのはあり得ないから何かに乗っかるわけだが
当然乗っかり先の制約を受ける
特にネイティブコード系は一番普及しているABIがC言語のソレであり
気に入らないのでひたすらラップしまくる日々か
諦めて次世代言語の機能を生かせずアンセーフとか言っちゃって直接叩くか
0127デフォルトの名無しさん
垢版 |
2017/12/05(火) 11:01:11.59ID:NtWJrTYb
Wiｎ鯖で運用されない = Win鯖で使えない
だからな
リーナスが死んだら終わりな言語とかよく使えるな
0133デフォルトの名無しさん
垢版 |
2017/12/05(火) 21:42:34.05ID:uUkZwDzW
>>128
今のリーナスは、リリース担当兼広報。

実際のリリーススケジュールとか開発機能とかは
スポンサーの企業が決めている。
0135デフォルトの名無しさん
垢版 |
2017/12/05(火) 21:56:16.41ID:wKllXbtS
リーリスリリースリーリリスリリリリリーリスリー
リーリナリリーナリーリリナリリリリリーリナリー
0137デフォルトの名無しさん
垢版 |
2017/12/06(水) 00:55:40.02ID:5Fm3uunR
ブログ記事は信用しない
マウント取るためだけの批判の連鎖がよくあるんだと、フロントエンド界隈で学んだ
0139デフォルトの名無しさん
垢版 |
2017/12/06(水) 01:47:25.25ID:6LacDPiL
OCamlをやるとプログラム中でオブジェクト指向を使った抽象化が必要な場所はほとんど無いことに気付くよ
0140デフォルトの名無しさん
垢版 |
2017/12/06(水) 02:00:40.62ID:9Cl2Q0EY
オブジェクト指向って抽象化なのか？
プログラミングで扱うのは本質的には「操作」だが、それは人間にとって抽象度が高く理解しづらい(と考えられていた)から、
仮想的なモノに見立てることで具象化したのがオブジェクト指向だろ
0141デフォルトの名無しさん
垢版 |
2017/12/06(水) 02:19:19.87ID:EoxkbCFV
メモリとかハードウェアまわりを触るのが具象で
オブジェクトのような仮想的なものを扱うのが抽象だと思っていた
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況