コレクションが最高にイケてる言語を作ろう [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
コレクションの良しあしは言語の生産性に直にかかわってくる。
例えば配列しかないCは最低の言語だ。
コレクションが最高にイケてる言語仕様をみんなで考えよう。 Smalltalkでさんざんいじられた結果なもんでさ C#のLinqとかはコレクションが使いやすくなる良構文だとおもう。 >>8
haskellのderivingというのがあるが参考になるだろうか コレクションに対してそれを表現するリテラルがあると使い勝手がかなり違う。
シリアライズ、デシリアライズなどの機能を有する言語は結構あるが、
あんな感じでそれをそのままリテラルとして書けるようにするというのはどうだろう。 コレクションという観点だと
動的型付けと静的型付けは
どちらに軍配があがるかな (配列の配列はしばしばジグザグ配列になって演算速度の低下につながるので)ダメです >>10
smalltalkがなんの関係があるの?
詳しく 既存言語で一番コレクションが使いやすい言語ってなによ?
C#はかなりいいと思うが。 C♯っていうか.NETな。
C♯がすごいんじゃない。.NETがすごいんだよ。 >>19
コレクションクラス(とそのサブクラス群)のネタ元はSmalltalkで培われたものって意味では? 配列でありリストであり連想配列でありキューでありスタックであるJavaScriptの配列が最強でイケイケだと思う javascriptはプログラム組んでてなんかもやっとするw 型の境界線がもやっとしてるよねjavascript
整数と実数の区別とか。 small talkってやったことないな。
噂は聞くが。
かじってみるかな。 >>26
オブジェクト指向言語としての初の試みであって実用性は無いからな >>29
Core CLRのソースに含まれててびっくりしたけどね 機能をどっさり削った go でも map だけは特別扱いだからな。
一理はある。 >>26
今週末、ちょうどこんな催しもあります
春のSmalltalk初心者向けのハッカソン | 第99回Smalltalk勉強会
https://smalltalk.connpass.com/event/55260/
もし東京近郊にお住まいでご都合が合えば参加されてみてはいかがでしょう
Smalltalkは独学で試行錯誤するのも(旅先でわざと道を外れて迷ってみる程度の愉しみとしては)悪くないのですが
効率的に何かの学びを得ようとするには、思いの外時間を無駄にすることにもなりお薦めできません
実際に使っていてよく知っている人に疑問をどんどんぶつけて解消してしまうのが一番です カオスすぎんだろsmall talk w
じっくり勉強すれば理に適ってるのか? >>35
> カオスすぎ
>>32のコレクションのクラス階層についてでしたら、ほとんどは抽象クラスや特殊用途のクラスなので
とりあえずこちらの図の黒枠のだけを押さえておけばよいかと
http://imgur.com/a/liiNB
OrderedCollectionは要素が追加可能なだけのArrayです
Dictionaryは他言語ではHashとかMapとか呼ぶことがあります
Setは重複を許さない集合
Bagがちょっと特殊ですが要素の数も覚えてくれるSetで他言語ではMultisetと呼ぶものもあります >>36
> 要素の数も覚えてくれるSet
Bagについてはたとえば文字列(仮に 'SMALLTALK')を構成する文字とそれぞれの出現数を多い順に知りたいとき
文字列(やはりコレクション)をBagに変換する(asBag)などして、こんなふうに書くことができます
'SMALLTALK' asBag sortedCounts
"=> {3->$L . 2->$A . 1->$K . 1->$M . 1->$S . 1->$T} " OrderedCollectionって順序付きコレクションってことだよね?
ツリーならsequenceableというのは若干違和感あるが…
先頭から順にたどれるから間違ってはいないのかな… >>38
OrderedCollectionはツリーではなく最近の言語にはよくある動的配列の一種です
内部にちょっと大きめの配列を持っていてそれを使って要素の追加や削除、挿入などの機能を模しています
固定長配列からさほど劇的には速度を落とさず使えるのがウリです small talk て速度重視言語なの?
長い歴史の中で必要に迫られたんだろうか? >>40
Smalltalkは言語のルールや変更不可能な動作中核(VM)部分をできるだけ小さく保って、
GUIやIDEを含む処理系(元々はダイナブック向けの暫定仮想OS)のほとんどを自身で記述するのが方針でした
▼Smalltalkの底を流れる設計思想
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#
そのため、当初から速度は潜在的な課題のひとつでしたが1970年代はAltoやDoradoという10年後のPCのスペックを想定した
「タイムマシン」を金をかけて作ってそこでSmalltalkを動かすことで、柔軟性を損なう最適化を避けるようにしていたようです
▼The Future Doesn't Have to Be Incremental
https://github.com/matthiasn/talk-transcripts/blob/master/Kay_Alan/NonIncrementalFuture.md
https://pbs-h2.twimg.com/media/C6cMkr4U4AAEDoJ.jpg
1980年代にはそういうことはできなくなったので、VMの高速化技術が試行錯誤されました
その成果が90年代のJavaのHotSpotや00年代のJSのV8に転用されています
そんなわけで、すごい高速なコアに頼ってそこそこの速度で動いているというのが現状です コレクション使ってて使いづらいと思うことも最近は減ってきたよな
昔より言語が進歩してるんだろか >>43
でもねぇ、世の中にはコレクション操作が使いづらい
退化した最悪な言語が存在する
http://d.hatena.ne.jp/edvakf/20090405/1238885788
元々は手続き型として設計された簡潔な言語だったけど、
オブジェクト指向やら関数型やらを行き当たりばったりに増築し続けたおかげで、
コレクション操作に関する「一貫性」という設計哲学が破綻してしまった例だね [Ruby]
a.sort().reverse().map{|x| x.to_s}.join('-')
[JavaScript]
a.sort().reverse().map(function(x) { return x.toString() }).join(“-“)
[Python]
'-'.join(map(lambda x: str(x), reversed(sorted(a)))) [Ruby]
a.sort().reverse().map(&:to_s).join('-')
map{|x| x.to_s}
map(&:to_s) [Pharo Smalltalk]
(a sort reverse collect: [:x | x asString]) joinUsing: '-'
(a sort reverse collect: #asString) joinUsing: '-' パイソン駄目言語なのか〜
一応人気あるらしいが…
ルビィは俺も好き。 C#も文字列結合joinはあんま美しくないかな。
String.Join("-",list)
やっぱRuby最強かな C#だとString.IsNullOrEmpty(str)とかもあんまり美しくないかな。
便利だし慣れたらそれほど気にならないけど。 >>51
メソッドチェーンで書きたいじゃんやっぱ。
とはいえ、nullにIsNullOrEmptyなんてメソッド持たせるのは無理だろうから
現状の形でしょうがないとは思う。 nullはもっと進化してほしいよね。
現状、nullチェック面倒すぎ。
とくにjava? 世の中にはnull結合演算子なんてものもあるのか。 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
0SKW4 ■ このスレッドは過去ログ倉庫に格納されています