[過去ログ] 次世代言語12 Go Rust Swift Kotlin TypeScript (1002レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
508: 2018/07/31(火)07:25 ID:HSKVxhV4(1) AAS
ん?ユニクロをもっと安っぽくしたようなデザインにしたいってこと?
509(2): 2018/07/31(火)07:33 ID:UxY/lhlr(1) AAS
Twitterリンク:kskexx
githubの分析だそうだけども
.netどこに行ってしまったん
510: 2018/07/31(火)07:35 ID:NvL3iNMe(1) AAS
>>509
お前記事読んでないやろw
511: 2018/07/31(火)07:59 ID:ZEe/Gn0n(1) AAS
>>507
Unity
512: 2018/07/31(火)08:15 ID:JoTrRiyA(1) AAS
GUIライブラリに何を使うかによる
SDLってAndroidでもつかえたっけか?
513(1): 2018/07/31(火)12:04 ID:wLuD0qiK(1) AAS
In our survey of 16,000+ npm users in January 2018, 46% of them reported using TypeScript.
Twitterリンク:seldo
514: 2018/07/31(火)12:16 ID:MCiT+aJj(1) AAS
>>509
.NetのC#以外は死んでるようなものだし
C#も半端な位置で留まってるから話題にならんのだろ
他バッサリ切ってC#に注力すればいいのにな
515: 2018/07/31(火)12:35 ID:Y+ETzapn(1) AAS
F#使いも生きてるぞ
516(2): 2018/07/31(火)13:56 ID:zoworXJJ(1/8) AAS
>>504
たしかに、そのとおりです
たとえば数学でいう直積(direct product あるいは cartesian product)の
プログラミング言語上の表現を、一般的には「タプル」と呼んでいる
もちろん ML や Haskell に代表される厳格な型システムを前提に設計された
言語の代数的データ型を持ち出すまでもなく、直積と直和の概念は
計算における数学上の概念の中で基本中の基本です
それにもかかわらず Python では、単なる不変(immutable)な配列に対して
公式文書でこともあろうか「タプル」と命名し、驚くなかれ「1要素のタプル」
といふ数学の概念を超越したリテラル構文を定義しちゃいました
世界的に普及している/していた言語は数多くありますが、こんな命名や
リテラル定義が存在するのは、後にも先にも Python だけ、唯一無二の存在です
まさに Python の設計哲学とは;
スクリプト言語にとって数学なんてクソ
といふことなんでしょうね
517(2): 2018/07/31(火)14:34 ID:U3QRqLaV(1) AAS
直積集合がタプルじゃなくて直積集合の要素がタプルな
んでもってn個の集合の直積を考える場合普通n=1は除外しない
518(1): 2018/07/31(火)15:00 ID:zoworXJJ(2/8) AAS
>>478
あのぅメソッドチェーンとは異なり、内包表記というのは
決して万能な道具ではないんですけど、ご存知ですか?
内包表記というのは、高階関数 map/filter とジェネレータという
三つの要素を簡潔に表現できる構文糖でしかありませんから、
内包表記では表現できない課題も数多く存在します
ですからたとえば Haskell では内包表記を提供する一方で、
ポイントフリーといふ関数を繋ぐ流れるようなスタイルでも書けます
つまり「メソッドチェーン vs. 内包表記」という対決の図式は成り立ちません
これでもまだ「リスト内包がわからんってわめき散らすの無知晒してるだけ」と
騒ぎたいなら、以下のお題(>>430-431)を内包表記だけで書いてみてください
'-'.join(map(lambda x: str(x), reversed(sorted(a))))
>>478氏が無知でなければ、内包表記でサラッとエレガントなコードを書けますよね?
ちなみに以下のような三重にカッコが入れ子になった醜いコードは勘弁してくださいね
'-'.join(str(x) for x in reveresed(sorted(a)))
519: 2018/07/31(火)15:33 ID:zoworXJJ(3/8) AAS
>>517
>n個の集合の直積を考える場合普通n=1は除外しない
ええ、それが Python 村の中では「普通」で常識なんですよね
でも Python 村から一歩外に出れば:
n個の集合の直積を考える、ここで n>=2
が「普通」なんですけど、ご存知でしたか?
たとえば手元の教科書(*1)だと、直積は以下のように定義されています
・2つの集合の直積 A × B = { <x, y> | x <- A, y <- B }
・3つの集合の直積 A × B × C = { <x, y, z> | x <- A, y <- B, z <- C }
・4つの集合の直積も同様に定義される
この本では n=1 は定義されていないし、個人としても定義のしようがないと考えます
で、ML/Haskell/Erlang/Prolog といったタプルというデータ構造が存在する言語でも、
「普通」n=1の直積を除外しており、これが世間の常識です
ちなみに「Python村の常識、世間の非常識」といふ格言、聞いたことありませぬか?
ところで、もちろん内包表記はご存知ですよね?
知らないと>>478氏に「無知晒してる」と嗤われちゃいますよ
*1:論理と計算のしくみ
外部リンク:www.amazon.co.jp
520(1): 2018/07/31(火)16:01 ID:6M1+k6px(2/2) AAS
n=1もあるしn=0もある
n=0は直積の単位元いわゆるunit
直和の単位元はbottom
521(1): 2018/07/31(火)16:12 ID:zoworXJJ(4/8) AAS
>>520
>n=1もあるしn=0もある
>n=0は直積の単位元いわゆるunit
たしかに Python 村の中では、n=0 も除外しないのが「普通」ですね
で、静的型付け言語の ML/Haskell では単位型(unit)として定義され
タプル型とは明確に区別されていますし、動的型付け言語では
nil という特別なアトムで表現することが多く、これが世間の常識です
ちなみに「Python村の常識、世間の非常識」といふ格言、聞いたことありませぬか?
ところで、もちろん内包表記はご存知ですよね?
知らないと>>478氏に「無知晒してる」と嗤われちゃいますよ
522(1): 2018/07/31(火)17:08 ID:LX5aJa12(1) AAS
>>516
なんだか随分と力んでいるみたいだけれど
> それにもかかわらず Python では、単なる不変(immutable)な配列に対して
> 公式文書でこともあろうか「タプル」と命名し、驚くなかれ「1要素のタプル」
> といふ数学の概念を超越したリテラル構文を定義しちゃいました
> 世界的に普及している/していた言語は数多くありますが、こんな命名や
> リテラル定義が存在するのは、後にも先にも Python だけ、唯一無二の存在です
いや、そういうことを言い出せば同じ引数の値で呼び出しても返す値が同じになるとは限らないCなどの「関数」“function”は数学における関数の概念とは全く違う破廉恥極まりない命名だとなるよ
そもそも手続き型プログラミング言語やオブジェクト指向プログラミング言語での「変数」“variable”と呼ばれているものもも数学の変数とは全く異なる
(例えば、それらの言語で書かれたプログラムの検証を考えるとその問題があからさまになる)
つまりプログラミング言語での用語は数学の用語を借りて使ってはいるが数学でのその用語の表していた概念を尊重しているとは限らないということだ
そういう例、つまり数学用語を数学での概念を尊重しない形でプログラミング言語の世界で借用してしまっている例は探せばいくらでもあるだろう
523(1): 2018/07/31(火)17:40 ID:vAluDZRs(1) AAS
そもそも = が代入って時点で数学と違うんだから
いちいち「厳密な定義がー」いう方がどうかしてる。
524: 2018/07/31(火)17:55 ID:zfxDeDFf(1/4) AAS
普通にWikipediaでタプルをしらべたら一要素のタプルの事をシングルというと
書いてあるのだがwww
525(1): 2018/07/31(火)18:08 ID:zoworXJJ(5/8) AAS
>>522
数学の定義や数式を計算機上で実行するには、
必然的に「解釈」という(あるいは「評価」とも呼ばれる)プロセスを伴いますから、
数学の概念とプログラミング言語との間に乖離(かいり)が存在するのは一般論ですし、
その為に計算機工学という分野で研究成果が積み重ねられてきました
もちろんこうした乖離は一般論ですから、例を探せばいくらでも挙げられるでしょう
たとえば「n個の直積を考える」場合に数学では n=1 や n=0 を除外しないモデルを
構築することは可能ですが(>>517,521)、計算機工学の研究成果を元に設計された
言語だと「n個の集合の直積を考える、ここで n>=2」が暗黙のうちに認知されています
(なぜなら n=1 または n=2 の直積は、一般的には形式的に定義できない為)
ところが、こうした計算機工学の成果である n>=2 を無視し、
そんなのどうでもいいとばかりに「単なる不変な配列をタプルと命名する(>>516)」といふ
深淵の淵へ自ら飛び込んだ稀有な例が Python といふ次世代言語なんですよ
もしも「他のあらゆる言語では計算機工学の常識に沿って設計しているのに、
ある特定の言語ではそれを無視している」という具体例があれば、ご教示願います
たとえば「Python におけるタプルの命名」は、他の言語には見られない唯一無二の例です
526(1): 2018/07/31(火)18:21 ID:zfxDeDFf(2/4) AAS
A = { x | x <- A}
A × B = { <x, y> | x <- A, y <- B }
普通に定義できるがwww
527: 2018/07/31(火)18:36 ID:zoworXJJ(6/8) AAS
>>478
>それはそれとしてPythonはもっと関数を横に繋げられるようにしてくれ
>Elixirのパイプ演算子みたいな感じでさあ
いや、新たにパイプ演算子みたいな構文を追加しなくても、
オブジェクト指向言語の Python であれば、メソッドチェーンで実現できるよ
だって、Python を除く今時のオブジェクト指向言語では実現できていますから
その具体例が >>430 のリンク先のブログ主様が書いた簡潔なライブラリです
問題は、「なぜこれをやろうとしないのか?」という点です
もちろんライブラリの後方互換性は失われますが、
python2 から python3 で致命的な「後方互換性の断絶」を断行したのが
Python ですから、一貫性のあるAPIを提供するライブラリへの刷新もできたはず
さらに根本原因にさかのぼれば、「なぜ最初から一貫性のあるAPIを設計しなかったのか」
といふ疑念に突き当たります
だって、Python を除く今時のオブジェクト指向言語では設計できていますから
最後に背景原因を考察すると、Python 作者のGuido氏が:
API の設計において一貫性などはクソ
と考えていたのか、それとも:
オブジェクト指向が流行っていたから行き当たりばったりに設計した、
今は後悔している
と考えているのか興味深い
528: 2018/07/31(火)18:45 ID:zoworXJJ(7/8) AAS
>>526
>A = { x | x <- A}
えぇとぉ、{ x | x <- A} というのは単に集合 A を内包的に定義してるだけですから、
それは「1個の集合Aから構成される直積」ではなく単に「単純集合A」を定義してるだけです
あぁそうか、フェイトニスタには内包表記うんぬん以前に、数学の教養が欠けているのですね
ついうっかりしておりまして、大変失礼をば致しますた
529: 2018/07/31(火)19:00 ID:zoworXJJ(8/8) AAS
うっかりミスを訂正:
>>525
X:>(なぜなら n=1 または n=2 の直積は、一般的には形式的に定義できない為)
O:>(なぜなら n=1 または n=0 の直積は、一般的には形式的に定義できない為)
530: 2018/07/31(火)19:04 ID:zfxDeDFf(3/4) AAS
定義するのに集合と同じ定義では同じでは駄目というルールはないから間違っては無いwww
ちなみにn=0の直積は1元集合として定義できるとWikipediaにかいてあるwww
531: 2018/07/31(火)19:12 ID:x816LWzK(1) AAS
ウィキペに書いてあるとか言っちゃう人って・・・
532: 2018/07/31(火)19:36 ID:zfxDeDFf(4/4) AAS
正式な定義だと、直積の要素はペアの中にペアがある構造じゃないと駄目www
A × B × C = { <x, y, z> | x <- A, y <- B, z <- C }
↑の定義があってるのは日本のWikipediaだっけでしたwwww
これを使うにはn-fold Cartesian productという直積を拡張した奴じゃないとだめでした残念www
とくにn=1の時はそのままA=Aとちゃんとした本に書いてあるwwww
533: 2018/07/31(火)19:38 ID:xC1/ia91(1) AAS
今までの流れをまとめるとpythonはクソ。
TypeScriptが最強。という理解でよいでふか?
534: 2018/07/31(火)20:41 ID:CfkG900T(1/6) AAS
rustが最強
が正しい
535: 2018/07/31(火)21:51 ID:vpErkqT1(1/2) AAS
メソッドチェーンでもリスト内包でも異常なまでのテンポラリ変数嫌悪を感じるのだが、
無理にそんな書き方するくらいならテンポラリ変数使えや。
536: 2018/07/31(火)22:05 ID:CfkG900T(2/6) AAS
メソッドチェーンは無理なく書けるでしょ
変数はバグの餌だから忌諱するのは当然
537: 2018/07/31(火)22:09 ID:4i5flEMB(1) AAS
変数があって嬉しいのはデバッガでステップイン実行するときだけだな
そろそろステップの概念を卒業した新発想のデバッガが必要な時期にきてると思う
上下前次1-新書関写板覧索設栞歴
あと 465 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ
ぬこの手 ぬこTOP 0.021s