動的言語で大規模開発

uy · 2012/07/24(火) 09:10:42.04

たててみた

**デフォルトの名無しさん** · 2014/02/08(土) 15:21:13.00

>>328
OSやコンパイラの基礎的な知識がここ5～10年ほどで全部置き換わったとでも？
何か新しいツールやライブラリなんかも利用期間が長ければ長いほど後方互換を
考えて思想的な部分を変えることが出来なくなってるよ？

基礎的な知識がない人、表面だけなぞってる人は全く変わって通用しなくなると
感じてんるんだろうけど、そんなことは無いんだけどね。

**デフォルトの名無しさん** · 2014/02/08(土) 15:24:34.62

つ電子書籍

すっかりぐだぐだのイメージが広まりつつあるがｗ

**デフォルトの名無しさん** · 2014/02/08(土) 15:26:17.39

ここ１５年くらい何も進歩してない
モバイルへのシフトが見えるくらい

**デフォルトの名無しさん** · 2014/02/08(土) 15:34:56.49

結局は、ノイマン型のコンピュータが登場して以来何も進歩してないんだよ

**デフォルトの名無しさん** · 2014/02/08(土) 15:55:37.52

話でかくなりすぎｗ

**デフォルトの名無しさん** · 2014/02/08(土) 16:36:22.62

プログラミング言語だけ見ても、PHPでもRubyでもC#でもJavaでもこの10年で大きく変わってる
ライブラリやミドルウェアはもっと変わってる
これだけラピッドリリースが当たり前の時代、オライリーは本棚に並べて自己満足するぐらいの価値しかない

**デフォルトの名無しさん** · 2014/02/08(土) 17:06:39.19

>>339

>>334 の下２行

**デフォルトの名無しさん** · 2014/02/08(土) 17:08:41.77

Ajax でブラウザとJSの地位が大幅に向上したというのは進歩かもしれない
それ以外は驚くほど何も変わってない

**デフォルトの名無しさん** · 2014/02/08(土) 21:58:29.94

JSに関してはかなり変わってきてると思う
00年代後半くらいに出た本はまだコーディングルールもままならなかったJSに対して
JSの安全で多言語との相異があまりない部分だけを使うという、かなり厳しい立場なものが多い
そしてそれ以降にでた本もそれを踏襲しているから同じ
ES3まではクラスベースの皮をすっぽり被ったプロトタイプベース言語だったからしかたがない
ゲッターすらも定義できないような未熟な言語だったのは確か

でもES5,ES6ときて例えばブロック文中の関数宣言の振る舞いの問題とか、
根底の不安定さがかなり解消されてきてる
そしてES6ではクラスシンタックスが入ったり、ミキシン等のサポートや、
プライベートっぽくもできるSymbolの導入、また何と言っても今までは
クラスベースの皮に隠れてたプロトタイプが表面にでたお陰でかなり変わってる
Promiseとか、関数型の方向性も強化されてきていて、
マルチパラダイム言語としてかなり磨きがかかって底上げされている
他にもモジュールやブロックスコープとか、書ききれない

コーディングルールの面でも、最近ではgoodpartsを書いたグーグル内、
例えばV8グループ内でもセミコロンフリーのソースがコミットされたりもしている
JSに関しては、何がいいのかは（ブラウザ間の差もあるし）その時その時で考えていくべき
JSも成熟してきて、JSerも成熟してきてるから、無闇矢鱈に縛る必要がなくなってきている

**デフォルトの名無しさん** · 2014/02/09(日) 00:23:11.54

>>333
Wikiにまとめられる情報を精査して紙媒体の本にするのが良いんだろうけど、
著作権的な問題で出来ないんだろうなと思う

**デフォルトの名無しさん** · 2014/02/09(日) 04:44:50.85

>>334
10年前の本でも読んでると良いよ

ゴミはゴミなんだからそれで良いな

**デフォルトの名無しさん** · 2014/02/09(日) 10:36:31.60

> 10年前の本でも読んでると良いよ

2004年の本ですか？そりゃ読むでしょうよｗ

**デフォルトの名無しさん** · 2014/02/09(日) 12:19:57.73

10年前のApacheの本とかBindとかSendmailとか

**デフォルトの名無しさん** · 2014/02/09(日) 21:59:17.96

JavaScriptは約５年の間にES3→ES6で仕様書は３倍になったし、
もっと言えばHTML5との絡みで世界が日に日に拡大してるから仕方ないね。
そのとき常識でも、半年経つと状況がガラッと変わった照りするからね。

例えば今はアニメーションはライブラリの手を借りないと困難だって認識だろうけど、
確か今年の６月くらいににAnimationsAPIが勧告されるからね。
まあフラグONにすればもう一部は使えるんだけど、そもそも存在を知る人も少なそう。

もうちょい先の話だとServiceWorkerとかね。
スクリプト言語はAPIあってのものだから大変だね。

**デフォルトの名無しさん** · 2014/02/10(月) 09:34:39.88

情報が古いと分かってる本読んでも得るもの何もないからな
信頼できない本読んで間違って覚えてそれで良いと勘違いしてる状況のほうが厄介な問題起こりそう

ゴミ

**デフォルトの名無しさん** · 2014/02/10(月) 14:01:59.53

過去の仕様が根こそぎ変化するわけじゃないんだから、
古くなってる部分だけ調べりゃ良いだろ

**デフォルトの名無しさん** · 2014/02/10(月) 14:43:51.08

古いものの方が
肥大した無駄機能もなく
本質的な部分に絞りこまれていることが多い

ただし破壊的変更を繰り返してフラフラしている駄ツールには当てはまらないかもしれない

**デフォルトの名無しさん** · 2014/02/10(月) 14:48:45.54

古い本を読んでる最中に古い情報（間違った情報）と新しい情報（正しい情報）の区別をどうやってつけるんだか
ゴミかよ

**デフォルトの名無しさん** · 2014/02/10(月) 14:49:39.61

ゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2014/02/10(月) 16:10:40.42

問題が生じてから調べりゃ良いだろ

**デフォルトの名無しさん** · 2014/02/10(月) 16:35:30.36

損害被ってから調べるわけか

新しい本がないならまだしも
新しい本があるにもかかわらず古いほう読んで間違った知識身に付けたがるゴミってペチパー以上に理解できない存在だな
死ねゴミ

**デフォルトの名無しさん** · 2014/02/10(月) 17:21:58.51

学んだことが数年で間違った知識と化すのならばその技術・ツールそのものが害なのだ

**デフォルトの名無しさん** · 2014/02/10(月) 18:40:07.47

IT分野に来ないほうが良いな

**デフォルトの名無しさん** · 2014/02/10(月) 18:45:28.28

RubyやRailsが顕著だけど、それ以外のプロダクトも互換性は早く捨ててイノベーションする動きになってる

**デフォルトの名無しさん** · 2014/02/10(月) 21:34:55.60

互換性と情報の古くなりやすさは違う気がする
JavaScriptなんて顕著な例だし
むしろ古い情報が中途半端に有効なことが問題を大きくしてる

まあ、本っていうのはやっぱ向いてる分野が限られてると思う。

**デフォルトの名無しさん** · 2014/02/10(月) 23:11:20.52

言語機能もライブラリも互換性ぶったぎってるから、本の通りに書いても全く動かない
依存関係があるから、部分的に古いライブラリ使おうと思っても一筋縄じゃ行かない
そんなの自力で解決出来る知識あるなら、そもそも本なんか不要

**デフォルトの名無しさん** · 2014/02/11(火) 01:14:27.60

誰が
何のために
変えているのか？

**デフォルトの名無しさん** · 2014/02/11(火) 07:53:46.12

コンパイルエラーなんかでて、動かないならまだ良いけど
「動くけど動作が違います＾＾；」

っていうのが最もヤバい
ruby1.8→1.9のヤバさは想像を絶する
Ostruct、クラス変数、シャドウイング使いまくってた人たちってどうなったの

**デフォルトの名無しさん** · 2014/02/11(火) 07:57:41.43

中途半端に途中まで正しく動くなんてまさに無能な働き者
仕事をしないならしないで良いのに、
ちょっとした期待をさせるからそれに頼ってみるとやはり失敗するという
船乗りとか、登山家が、余計な足手まといは連れて行かないのと同じ
プロだけで行くなら良いのに素人が一緒に来るとプロまで道連れになるんだ

人間レベルで
「動くけど動作が違います＾＾；」
は、困る

**デフォルトの名無しさん** · 2014/02/11(火) 09:06:04.31

育成しろ
おまえの役目だぞ

**デフォルトの名無しさん** · 2014/02/11(火) 10:10:44.65

>>325,349
死ねゴミｗ

**デフォルトの名無しさん** · 2014/09/19(金) 11:11:48.63

サーバサイドではNode.jsからJavaやGoへの切り替えが進み
クライアントサイドではTypeScriptを導入した連中が喜びの声を上げている、
もちろんSwiftもある

JavaScriptもPythonも型アノーテーション導入を検討しているし、Rubyもこれだ

https://twitter.com/miyohide/status/512768555385769986
> Matz「最近の言語（ScalaやGoやDartなど）はみんな静的な型を持っていて、
> ちょっとそれは悔しいので、Rubyでも導入を考えたい。」

情勢から見て、もはや静的型の勝利、動的型はやはり駄目だったよということで決着がついただろう。

とりわけ動的型の経験しかなかったウェブ屋やTDD厨がちょっと頭おかしかった。
動的型はゼロ年代の一時的な熱狂だったということで終わるのではないか。
冷静に考えてとにかくメリットがねーもん。まるっきり。

Real World Academia: Unit testing isn't enough. You need static typing too.
http://evanfarrer.blogspot.jp/2012/06/unit-testing-isnt-enough-you-need.html
> 「ユニットテストだけでは不十分だ。静的型も必要だ」

ってことすな。

**デフォルトの名無しさん** · 2014/09/19(金) 13:53:26.63

この業界は一時的な熱狂が多すぎるよね

**デフォルトの名無しさん** · 2014/09/19(金) 16:44:39.68

>>365
>サーバサイドではNode.jsからJavaやGoへの切り替えが進み

一行目からもう信憑性ゼロじゃないかw

**デフォルトの名無しさん** · 2014/09/20(土) 09:47:56.33

型チェックというのも、テストの全てではないが
テストの一部なんだよ。

それが原因のバグもあるわけなんだから。

たとえそれが一瞬で修正できることだとしても
その為に別の作業中にバグ見つけて
割り込みで修正するとか思考の流れを途切れさせることはよくある話。

**デフォルトの名無しさん** · 2014/09/30(火) 07:23:04.54

>>366
幸か不幸か、ソフトウェアというのは一時的な熱狂だけで「動くもの」を作れてしまう分野だからだろうね

**デフォルトの名無しさん** · 2014/10/11(土) 23:13:05.47

Rubyで開発やってるけど、
unitテストの設計と項目作成だけで
3人で三週間かかって、マジで倒れそうだわ

来週からテストだけど、かなり辞めたい気分

**デフォルトの名無しさん** · 2014/10/12(日) 07:22:26.20

>>370
大変なとこだけやって辞めてくれるとか有り難いな。
まあ、設計がちゃんとできていればの話だけど。

**デフォルトの名無しさん** · 2014/10/12(日) 07:29:16.53

大変な所＝メンテナンスだから、
今後ずっと大変な状態が続くよ、

Rubyをやめるのが一番の早道だな。

**デフォルトの名無しさん** · 2014/10/12(日) 07:36:17.74

テストすらロクにしない>>372はどんな言語で書いてもバグだらけw

**デフォルトの名無しさん** · 2014/10/12(日) 09:08:57.89

>>372
メンテが大変なのは自動テストがない場合だろ。
なぜ他の言語だとメンテが楽なの?

**デフォルトの名無しさん** · 2014/10/12(日) 10:05:01.80

>>371
UNITテストやるのもかなり大変だろ

テストの途中でメソッドが増えたり減ったりしてそのたびにテスト項目修正して
ログから障害の原因が分からない場合はログを修正して
RUNITのアサートも修正して、テスト項目も修正し無いと行けないし、、

考えただけでだるいわ

**デフォルトの名無しさん** · 2014/10/12(日) 13:06:01.13

>>375
それは仕様変更だろ。
TDDなら、メソッドの変更の前にテストの変更が来るし。

**デフォルトの名無しさん** · 2014/10/12(日) 17:09:28.84

>>375
ルビーの勉強がんばってください、入門者さんw

**デフォルトの名無しさん** · 2014/10/16(木) 00:02:19.53

動物言語に見えた

**デフォルトの名無しさん** · 2014/10/16(木) 07:57:26.33

面倒なのは全部ほかにまわせば確かに楽になるかもな

**デフォルトの名無しさん** · 2014/10/18(土) 12:19:07.94

巷に出回る仕事術の基本

**デフォルトの名無しさん** · 2014/11/24(月) 00:10:36.26

動的言語ってリファレンスが読みにくくね？
みんなどうしてんの？

**デフォルトの名無しさん** · 2014/11/24(月) 00:12:03.59

暗記

**デフォルトの名無しさん** · 2014/11/24(月) 00:16:50.33

そんなん言語によるだろ

**デフォルトの名無しさん** · 2014/11/24(月) 09:52:02.93

>>381
具体的にどの言語のリファレンスが読みにくいと?

**デフォルトの名無しさん** · 2014/11/24(月) 10:02:48.56

pythonしか知らんが、pythonはかなりドキュメント類がしっかりしてると思うけどな。

ただまあ、マイナー言語、ライブラリは動的静的カンケーなく、結局ソースを読むことにはなると思う。

**デフォルトの名無しさん** · 2014/11/24(月) 10:33:25.11

定番アプリのソースで似たようなことしてるものを探して真似る
うっかりソースを読んで入り込むとあとで変更された時にヤラれる

**デフォルトの名無しさん** · 2014/11/24(月) 15:01:36.25

PHPとPythonのドキュメントはしっかりしてるけど
RubyとSmalltalkのはゴミだったな

**デフォルトの名無しさん** · 2014/11/24(月) 17:34:32.45

smalltalkはブラウザ開いて
オブジェクトと対話しながらプログラミングしていくスタイルだから
アレで良いのだ

と、多くのスモールトーカー様は思ってる

**デフォルトの名無しさん** · 2014/11/24(月) 18:25:46.58

動的言語ではないがJavaのAPIドキュメントがしっかりしすぎてる。

**デフォルトの名無しさん** · 2014/11/24(月) 18:41:49.16

Smalltalkのドキュメントって何のことだろう？

**デフォルトの名無しさん** · 2014/11/24(月) 19:12:45.95

pythonのopencvとかnumpyのリファレンス見てみたんだけど
なんの型を入れるとなんの型が帰ってくるのか明確に書いてないからサンプル見ないと分かんない

**デフォルトの名無しさん** · 2014/11/24(月) 19:35:00.93

その辺はネーミングセンスでカバーするという思想だろうけど
Ｃライブラリのラッパーとかだと全く通用しなくなるな

**デフォルトの名無しさん** · 2014/11/24(月) 20:12:08.30

>>391
ipythonで?して書いてなかったらソース読んでる。

**デフォルトの名無しさん** · 2014/11/24(月) 20:25:30.45

vimでKを押してdocumentがなかったら
\dを押して定義元のソースコードにジャンプしてる

**デフォルトの名無しさん** · 2014/11/25(火) 00:06:15.89

下みたいコードのエラーを実行前に検出できるlint系ツールが存在する
Pythonを動的言語で括って良いものだろうか

def foo(x):
    def f(g):
        return g() + x
    return f

def bar():
    foo(1)(lambda: 'abc')

**デフォルトの名無しさん** · 2014/11/25(火) 05:48:58.67

最近追ってなかったけど
pythonは型アノテーション導入の話題もあるのな。

**デフォルトの名無しさん** · 2014/11/25(火) 20:38:28.15

やっぱ大規模開発には静的型があった方が
良いんだろうな

**デフォルトの名無しさん** · 2014/11/25(火) 23:51:15.09

>>397
typoですら動かすまで見つけれないのは地味にストレスだからな。

**デフォルトの名無しさん** · 2014/11/26(水) 04:22:00.60

>>398
何十年前の常識だよそれ
今時typoすら実行前に発見できない処理系のほうが珍しい

**デフォルトの名無しさん** · 2014/11/26(水) 05:14:33.37

>>399
動的言語は、typoを実行前に発見できないほうが多いよ。
発見できないパターンはこれ

obj.f00 (fooの間違い)

オブジェクトのメソッドのメソッド名を間違えた時
ほぼ全ての動的言語は、実行するまでtypoを発見できない。

なぜなら後で動的にメソッドを追加するかもしれないから
実行するまでわからない。

**デフォルトの名無しさん** · 2014/11/26(水) 05:24:10.98

動的言語だとtypoがわかると言っても
ローカル変数程度なんだよね。

そんな近くにある目で見てもすぐわかるようなものより
ファイルをまたいだりしている遠くにあるコードの
typoを知りたいんだが。

**デフォルトの名無しさん** · 2014/11/26(水) 08:52:45.01

>>400

＞なぜなら後で動的にメソッドを追加するかもしれないから
＞実行するまでわからない。

そういうケースにワーニングを出してくれるだけで十分ありがたい

**デフォルトの名無しさん** · 2014/11/26(水) 10:27:57.07

>>400
その理屈はなんかおかしいぞ。

後で動的にメソッドが追加されるかもしれないから
typoかどうか実行時まで＊処理系側では＊判断できない
というだけの話。

書いている人間様はそれがtypoかどうかは容易に判断できる（気づきさえすれば）。
だから、パーズ・コンパイル時に単に未定義だと文字通りワーニングを出せばいい話で、
実際そういう機能を持つ処理系やIDEは1980年代のSmalltalkから普通にある。

typoでたまたま他の既存のメソッド名とかぶってしまった場合に、
型でtypoかどうか判断可能という主張ならまだわかる。
その場合でも、型まで一致していたら静的型言語でもお手上げだ。

**デフォルトの名無しさん** · 2014/11/26(水) 10:37:02.67

typoっつーか、メソッド名を補完してたら
ウッカリ同じprefixの別のメソッド呼んじゃってた事はあるよ

でも、その間違ったメソッドが引数の型や数、戻り値の型まで一致してたことは一度も無かった

**デフォルトの名無しさん** · 2014/11/26(水) 12:07:39.14

>>404
補完なら、ふつう型が一致してなかったらそもそも候補に出てこないし、
まして「呼んじゃって」（つまりコンパイルが通って実行される）なんてことは
ウッカリだろうが何だろうが基本ないことだと思うけど？

**デフォルトの名無しさん** · 2014/11/26(水) 12:29:05.12

>>405
動的言語は型が一致しないメソッドも候補に出てくるIDEばっかじゃんSmalltalkも含めて
それにコンパイルも通るよ静的型じゃ無いんだから

**デフォルトの名無しさん** · 2014/11/26(水) 12:35:38.39

>>406
>>405は静的型言語の話をしているんだが？
それとも>>404は動的型言語の話なのか？
ならなんで「引数の型や数、戻り値の型まで一致」とか出てくるんだ？

**デフォルトの名無しさん** · 2014/11/26(水) 12:59:25.21

>>407
＞ならなんで「引数の型や数、戻り値の型まで一致」とか出てくるんだ？

動的言語でも値に型はあるから

**デフォルトの名無しさん** · 2014/11/26(水) 17:49:47.93

rubyのto_sとか？

**デフォルトの名無しさん** · 2014/11/26(水) 20:45:29.26

>>408
へー、どの動的型付言語が言語仕様で「型」という概念が定義されているんだい？

**デフォルトの名無しさん** · 2014/11/26(水) 20:48:18.16

動的型付言語を使っていて型が違うのにとか型で補完できればとか言ってる人は動的型付言語の初心者。
動的型付言語を単に型宣言しない静的型付言語として使っているだけ。

**デフォルトの名無しさん** · 2014/11/26(水) 22:06:07.76

初心者

**デフォルトの名無しさん** · 2014/11/26(水) 22:45:02.52

>>411
まあ初心者なら Soft typing という用語を知らなくても
しかたないだろうな

**デフォルトの名無しさん** · 2014/11/26(水) 22:49:59.27

>>410
a = 1
a = "a"
a = true

一行目のaの値は数値型で二行目で文字型に変り三行目でBoolean型に
なるってことで型が無いように見えて値にはちゃんと型があると言いたいんでしょ?

**デフォルトの名無しさん** · 2014/11/26(水) 22:52:09.61

柔軟だがバグの元にはなりそうだ

**デフォルトの名無しさん** · 2014/11/26(水) 23:01:03.31

重要なのは値に型があることではなくて変数に型があること。
変数に型があるからこそ、その変数の型のメソッドは何かがわかる。

**デフォルトの名無しさん** · 2014/11/26(水) 23:03:26.44

変数はコードに書く。コードに書くということは
静的にわかる。（変数に型がある場合）

値に型があっても、実行時にならないとわからない。
変数に入る値はいろんな型がありえるから
値に型があるだけじゃ、typoを発見することは出来ない。

いい加減「値に型がある」を反論の材料にするのはやめてくれ。
反論になってないから

**デフォルトの名無しさん** · 2014/11/26(水) 23:10:00.48

変数posがあってこれが座標を表わしてるものだとしたら
list型で(x y)だったり構造体でxとyのフィールドを持ってたりy*w+xの整数だったり
色んな表現が出来るから柔軟という利点があってプロトタイプに向いてるってことじゃないの

**デフォルトの名無しさん** · 2014/11/27(木) 00:00:17.23

>>411
動的型言語の玄人になると、値の型と無関係な（CallするとRuntime Errorになる）メソッドが
大量に候補に出てくるような補完や、typoすら発見できないようなチェッカーに
慣らされてるから疑問にすら思わなくなるってこと？

**デフォルトの名無しさん** · 2014/11/27(木) 00:39:38.24

>>418
一人で把握できる範囲でプロトタイプのようなある程度使い捨てを前提に作れる
ならそれほど問題はないが、スレタイにあるように大規模開発≒複数人開発だと
静的言語に比べて動的言語だとtypoみたいな簡単なミスでも見つけづらいよねと
いうような話だと思う。ちょろっとしたものを作るだけなら変数は全てオブジェクト
ですっていうように抽象化されている方が楽だけど、大規模開発だとそれじゃ
ダメだよねっていう話。

**デフォルトの名無しさん** · 2014/11/27(木) 00:43:32.22

>>419
大量ったってさらに数文字足せばかなり絞り込めるし
typoだって前にも書いてあるとおり
未定義のワーニングで十分に思うんだが
いったい何が不満なんだ？

**デフォルトの名無しさん** · 2014/11/27(木) 07:05:04.04

そりゃ未定義がワーニングだからだろ。
ワークニング出たよ。
さて、そのワーニングは無視していいのかよくないのか？

typoしてワーニングが出た。あぁ、いつものワーニングかでスルー
結局ワーニングがあてにならないものになってるだろ。

**デフォルトの名無しさん** · 2014/11/27(木) 07:17:33.51

>>422
いや、普段使いがSmalltalkなもんで、そんなことはない。
未定義のワーニングはtypoだった場合の候補も挙げてくれるから
実際にtypoだったらそこから選ぶだけだし。^^;

**デフォルトの名無しさん** · 2014/11/27(木) 07:36:00.70

SmalltalkのIDEの補完は精度が低過ぎて使えないゴミだから
プログラマは補完に頼らず自分でタイプするから
>>404みたいな問題もないんだよね

**デフォルトの名無しさん** · 2014/11/27(木) 08:44:42.11

>>424
そうだね。なんかこんなようなメソッド名（Smalltalkではセレクタと呼ぶ）だったなぁ…と
うろ覚えで適当に入れとくとコンパイラがあとでいちいち教えてくれるから、はいはいって直してく感じ。

補完が便利だなぁと感じるのは長いメソッド名の場合かな。
適当にだとしてもタイプするのが単純に面倒なのでその労力を省くことができるので。

**デフォルトの名無しさん** · 2014/11/27(木) 09:51:34.08

Python「低レベルな争いだな…」

**デフォルトの名無しさん** · 2014/11/27(木) 10:14:33.17

>>426
ごめん。
PythonにはSmalltalkのそれを凌駕する最強のIDEがそろっているのかもしれないが、
その前にまず言語として隔靴掻痒感が否めなくて使っているとめまいがするのでパス。

**デフォルトの名無しさん** · 2014/11/27(木) 17:17:05.92

Smalltark 厨 vs Pythonee

**デフォルトの名無しさん** · 2014/11/27(木) 19:38:58.94

>>428
Unknown variable: Smalltark please correct, or cancel:
define new class
declare global
------------------------------------------------------
Smalltalk
SmalltalkImageTest
SmalltalkEditor
SmalltalkImage
SmallLandColorTheme
SmallInteger
SmallIntegerTest
SMAccount
SMCategory
SMPackageInstallationTask
------------------------------------------------------
cancel

**デフォルトの名無しさん** · 2014/11/27(木) 20:07:16.47

Python「ただのテキストエディタで出来そう…」

**デフォルトの名無しさん** · 2014/11/27(木) 20:39:01.35

そんなにイデの力が欲しいか

**デフォルトの名無しさん** · 2014/11/28(金) 00:34:41.35

>>378
ｺﾞﾛﾆｬｰﾝ♪

**デフォルトの名無しさん** · 2014/11/28(金) 09:07:58.51

>>419
動的型に慣れたら、大量に候補が出るような命名はしないし（凝集度）
typoすら発見できないようなチェッカーなんて使わずにマトモなチェッカーを使う。
あたりまえだろ？