動的言語で大規模開発

■ このスレッドは過去ログ倉庫に格納されています
1uy
垢版 |
2012/07/24(火) 09:10:42.04
たててみた
2013/02/20(水) 23:44:16.57
>>285
あなたは手で書いてるの?
2013/02/20(水) 23:57:15.20
自動生成だけど？

自動生成ならいくらでもソース量が増えるから、
別にソース量が多いからって大規模じゃないよねっていうIrony。
2013/02/21(木) 00:01:32.70
ソースを生成するソースを書けば小規模になるんじゃね
2013/02/21(木) 01:41:04.93
今調べて初めて知ったのか。
2013/02/21(木) 21:25:30.17
まじでかホント初めて知ったわ。
OSもソースを生成するツールを生成するツールを生成するツールで作成すれば100行程度に縮められるなっ!
2013/02/21(木) 21:37:45.76
>>290
そのツールチェインの最後はお前だよお前しだい。
2013/04/03(水) 22:31:12.49
>>8
1万行で大規模ﾜﾗﾀｗ
2013/06/15(土) 23:51:26.86
あ
294デフォルトの名無しさん
垢版 |
2014/01/16(木) 15:14:04.15
9 ：デフォルトの名無しさん：2014/01/11(土) 12:45:26.07
PHPが多分広く使われてるんだろうけど
Web鯖へのPHP標的とみられるアタックの回数が今年に入ってからヤバい
あらゆる種類のPHPアタックされてる
あいにくPHP鯖じゃないしPHPも動かしてないから無関係だけど

ruby鯖でほんと良かったよ
2014/01/16(木) 15:58:57.11
〜１０万行小規模
１００万行中規模
１０００万行大規模
2014/01/16(木) 16:15:44.93
それは生産性の低いＣとかの目安だろう
2014/01/16(木) 16:22:11.85
じゃあこうだ
rubyなら
〜１万行小規模
１０万行中規模
１００万行大規模
298デフォルトの名無しさん
垢版 |
2014/01/16(木) 16:39:07.41
ペコーンｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
299デフォルトの名無しさん
垢版 |
2014/01/16(木) 18:22:08.59
ロバみたいな奴だな
300デフォルトの名無しさん
垢版 |
2014/01/17(金) 02:26:52.79
場粉路「300ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ」
301デフォルトの名無しさん
垢版 |
2014/02/05(水) 04:47:08.99
型安全性ない限り不可能ですわ
2014/02/05(水) 06:16:34.54
ああ、本物の動的型を知らないんだ。
型安全じゃない動的型しか使ったこと無いんだね。
2014/02/05(水) 09:43:19.39
実用性のあるやつあったっけ？
ネタみたいな言語はいらないよ
2014/02/05(水) 11:54:42.46
本物の動的型っていうのは
たとえばJavaやC++のことだよ。

型安全かつ動的。動的っていうのは
ポリモーフィズムのことを言う。
実際に使われるクラスが動的にしか決まらないから。

インターフェースは静的だけどね。
でも具象クラスが動的に決まるならば、
それは動的言語なんだよ。
2014/02/05(水) 12:09:06.82
などと意味不明なことを供述しており精神鑑定の結果を待って慎重に対応する予定です
2014/02/05(水) 12:54:50.99
>>304
なんでゴミってこんなつまんねーことしか言えないんだ
2014/02/05(水) 12:58:26.58
ほっほっほ、反論は無しｗ
308デフォルトの名無しさん
垢版 |
2014/02/05(水) 13:12:01.88
>>307
死ねゴミ
309デフォルトの名無しさん
垢版 |
2014/02/07(金) 06:53:01.21
死ねゴミ
310デフォルトの名無しさん
垢版 |
2014/02/07(金) 16:38:35.68
ぁーーーやっぱり型推論やる感じの静的言語になるのかなぁ
色々考えたけどやっぱし無理かも
結局コンパイル時に出来る限り多くのエラー検出してくれた方が、
実行後に「気にしなきゃいけない事」が減ってくれるから
その差が理論的にどうやっても静的言語と動的言語じゃ埋まらない
それでも短いコード書く場合は動的言語のほうが良いのは事実だけど
完全に動的になってる言語ってどうも、eval上でコード動かしてるのと似たような気分になる事があるし
それでも何とかなるとしたら物量か
311デフォルトの名無しさん
垢版 |
2014/02/07(金) 20:40:16.60
JSでとあるゲーム２，３年ぼちぼち作っててデータやView部抜きで１万行くらいをキープしてるけど
今までで一番長時間ハマったのは暗黙の型変換の挙動かな
確か正規表現で取り出した数字文字列を、==で数値と比較してる部分があって、その時点では問題なかったけど
後からそこ見て数値同士の比較かと思ってカッコつけて==を===を直してしまったんだよね

でもそれからは気をつけて、代入時に型と値の範囲を一気に確定させておく書き方を心がけるようにした
あくまで例えばだけど、文字列から少数を取り出すのなら、
m = +(str.match(/\d+\.\d+/)||[0])[0]
のような勢いで

こうやって一発で行数を減らしておくと全体の見通しがよくなって更に嵌りそうなことが減る
単行演算子とか用いると実装速度も微妙に上がるしね、asm.jsライクな記述すると

それで確かにその時は==となって欲しいケースが稀だったことや
その場所が予想外にViewに当たる場所だったこともあってかなり特定が大変だったけど、
逆に数値演算ばかりの結構複雑だと思うメインロジックでは難しい問題起こらなかったんだよね

評価関数の出来って動かしてみないと良くなったかどうかわからないってこともあるし、
エラーではなくアルゴリズム的に正しいかどうかの判断は動かしてなんぼで不満なかった
「大規模」ではなくて、「多いコード」だから動的が向いてないっていうのは違うんだろうね

例えばES6でclassシンタックスが入って大規模がよくなるっていうけど
ひたすら配列の操作をやるのだと関数型チックなので困らないし
まあ「大規模」っていうのは色んな要素が入ってると思うけど、そこをまず具体的に洗い出していったほうがいいかもね
その上でそれぞれに対して動的型でどうしていったらより良くなるか考えよう
2014/02/07(金) 22:01:54.81
==と===の違いは面倒だから使うなって、
オライリーから出ている薄い本の何処にでも書かれてるだろ
2014/02/07(金) 22:03:36.88
テストコードやCIしながら書くもんじゃないのか
2014/02/07(金) 22:04:48.68
静的言語ならバグが含まれないってのが、そもそもの幻想
2014/02/07(金) 22:13:41.93
静的言語でバグを作り出さないなら、JUnitなんて出てくるわけがない
いちいち変数定義するなら、それ無しでテストコードまで書いた方が効率良い
という発想。（テスト自体はSmalltalkからJavaへ輸入されてた気がする）
2014/02/08(土) 01:39:35.92
ウェブで言うと、昔は専用サーバは高価でシェルを使えるのは希だったから、スクリプト言語の方が動かしやすかったんだよ
プログラム自体も単純なものが多かったから、タイプセーフじゃなくても問題なかった
317デフォルトの名無しさん
垢版 |
2014/02/08(土) 06:00:40.97
>>312
それは今回の件とは関係ない
例え最初から===にしてたとしても、前述したように稀かつゲームを進めないと出てこない問題だったから気付けなかった
むしろこういうケースがあるから==の方を使ったほうが殆どの場合でいいと思ってる
まあ、言いたいことはそういうことじゃない

今回テストは作りたて関数やバグが出たら使い捨てくらいの軽い気持ちで作るという感じだったが
よほど労力（とテストにかかる時間）をかけていたとしても発見できたかは微妙だった
今回のケースは自分はもっとメタ的に解決すべきだったと思う

例えば演算子オーバーロードができればそういったハマりやすいポイントでワーニングが出せる
それだけじゃなくて統計をとって最適化にもきっと活かせる
（例えば結果がSMIのようなJITエンジンがより最適化してくれる範囲内かどうか等）

他にもProxyとかメタ的やハックでの「動かしながらの」分析によるテストが
特に緩い動的言語での大きな開発でかなり有効なんじゃないかと自分は思ってきてる

ある程度はデバッガの役割だろうが、例えば条件付きブレークポイントみたいに
汎用的に細かいことがしたければ結局コードを書くことになるので、しかたない
でもそういったことが十分できるのならば自分は開発になんら不満、不安を感じない

また今回は流れでテストするのにデータのObservingが役に立ってる
各処理関数に全く関わる必要もないしテストも全く省けてる
目でのチェックと同時に比較的低負荷でできるのがかなり効率がいい

自分はES6,7などこれからのJSにはそういう部分に結構期待してる
318デフォルトの名無しさん
垢版 |
2014/02/08(土) 08:08:08.34
>>312
オライリーって反面教師の本だろ。。。
死ねゴミ
2014/02/08(土) 11:30:21.22
オライリーのどの辺が反面教師なの?
あなたは国内出版社の方？
320デフォルトの名無しさん
垢版 |
2014/02/08(土) 13:01:18.60
基本的にオライリーはゴミな上に一回本出した後で
売れ残りすぎてるから２版３版って更新されんのが遅すぎて
載ってる情報が古すぎるケースが多すぎ
あれ読んでる奴はゴミ
2014/02/08(土) 13:07:19.15
オライリーは言語によって出来が違いすぎる
2014/02/08(土) 13:07:59.08
英語版はやっぱり出来がいいよね。
2014/02/08(土) 13:19:36.72
本毎に差がありすぎるんだよな
あと翻訳者
日本人が書いてゴミなRuby本もあったな
324デフォルトの名無しさん
垢版 |
2014/02/08(土) 13:28:19.75
書店にいって適当に本の後ろの発行日を見たらいいよ
オライリーは５年とか１０年ものとか平気でおかれてる
売れてないからそうなってる
初心者チックな本でも、せいぜい１〜２年以内に出た新しい本買ったほうが絶対良い
あとはネットで調べりゃいいだけ
2014/02/08(土) 13:33:40.49
オライリーは新しくないとダメなものは向かない
新しい情報はネットで集めた方がいい
適当な他の本買うぐらいならオライリーのがマシなことが多いな

それよか、ピアソンどうなるんだ？
326デフォルトの名無しさん
垢版 |
2014/02/08(土) 13:40:16.96
オライリーはゴミｗ
2014/02/08(土) 13:42:03.17
1年2年で入れ替わるくらい変化が激しい物ならそれこそ本なんて遅すぎて
いらないってなるだろうに。
328デフォルトの名無しさん
垢版 |
2014/02/08(土) 13:56:41.14
ITってそういう分野
ハードウェア絡むような場所だけだよ
５〜１０年昔の知識が通用するなんて
2014/02/08(土) 14:00:39.74
もうオライリーみたいな重厚長大な本の時代じゃないね
昔はラクダ本とかボロボロになるまで読んだけどね
2014/02/08(土) 14:21:34.64
ゴミｗ
2014/02/08(土) 14:23:39.19
ネットの情報は断片的に拾い読みする分には良いが
まとまった情報って本で無いとねえ。

って言うのは古いかw
2014/02/08(土) 14:31:47.88
リファレンスとかは完全に　ネット　＞　本　になった
2014/02/08(土) 14:57:45.25
では、ハズレの本を出さない出版社を発表しちゃってください。
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とか
347デフォルトの名無しさん
垢版 |
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
古い本を読んでる最中に古い情報（間違った情報）と新しい情報（正しい情報）の区別をどうやってつけるんだか
ゴミかよ
352デフォルトの名無しさん
垢版 |
2014/02/10(月) 14:49:39.61
ゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
2014/02/10(月) 16:10:40.42
問題が生じてから調べりゃ良いだろ
354デフォルトの名無しさん
垢版 |
2014/02/10(月) 16:35:30.36
損害被ってから調べるわけか

新しい本がないならまだしも
新しい本があるにもかかわらず古いほう読んで間違った知識身に付けたがるゴミってペチパー以上に理解できない存在だな
死ねゴミ
2014/02/10(月) 17:21:58.51
学んだことが数年で間違った知識と化すのならばその技術・ツールそのものが害なのだ
356デフォルトの名無しさん
垢版 |
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
誰が
何のために
変えているのか？
361デフォルトの名無しさん
垢版 |
2014/02/11(火) 07:53:46.12
コンパイルエラーなんかでて、動かないならまだ良いけど
「動くけど動作が違います＾＾；」

っていうのが最もヤバい
ruby1.8→1.9のヤバさは想像を絶する
Ostruct、クラス変数、シャドウイング使いまくってた人たちってどうなったの
362デフォルトの名無しさん
垢版 |
2014/02/11(火) 07:57:41.43
中途半端に途中まで正しく動くなんてまさに無能な働き者
仕事をしないならしないで良いのに、
ちょっとした期待をさせるからそれに頼ってみるとやはり失敗するという
船乗りとか、登山家が、余計な足手まといは連れて行かないのと同じ
プロだけで行くなら良いのに素人が一緒に来るとプロまで道連れになるんだ

人間レベルで
「動くけど動作が違います＾＾；」
は、困る
2014/02/11(火) 09:06:04.31
育成しろ
おまえの役目だぞ
364デフォルトの名無しさん
垢版 |
2014/02/11(火) 10:10:44.65
>>325,349
死ねゴミｗ
365デフォルトの名無しさん
垢版 |
2014/09/19(金) 11:11:48.63ID:uUn/9tg4
サーバサイドでは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.63ID:Xfkvubm0
この業界は一時的な熱狂が多すぎるよね
2014/09/19(金) 16:44:39.68ID:3WQN+no2
>>365
>サーバサイドではNode.jsからJavaやGoへの切り替えが進み

一行目からもう信憑性ゼロじゃないかw
2014/09/20(土) 09:47:56.33ID:b8OT/FfJ
型チェックというのも、テストの全てではないが
テストの一部なんだよ。

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

たとえそれが一瞬で修正できることだとしても
その為に別の作業中にバグ見つけて
割り込みで修正するとか思考の流れを途切れさせることはよくある話。
369デフォルトの名無しさん
垢版 |
2014/09/30(火) 07:23:04.54ID:2CeH2hLD
>>366
幸か不幸か、ソフトウェアというのは一時的な熱狂だけで「動くもの」を作れてしまう分野だからだろうね
2014/10/11(土) 23:13:05.47ID:bgxomZ9f
Rubyで開発やってるけど、
unitテストの設計と項目作成だけで
3人で三週間かかって、マジで倒れそうだわ

来週からテストだけど、かなり辞めたい気分
2014/10/12(日) 07:22:26.20ID:5ixfa8wz
>>370
大変なとこだけやって辞めてくれるとか有り難いな。
まあ、設計がちゃんとできていればの話だけど。
2014/10/12(日) 07:29:16.53ID:jjrAIsW+
大変な所＝メンテナンスだから、
今後ずっと大変な状態が続くよ、

Rubyをやめるのが一番の早道だな。
2014/10/12(日) 07:36:17.74ID:gqs4tO4e
テストすらロクにしない>>372はどんな言語で書いてもバグだらけw
2014/10/12(日) 09:08:57.89ID:5ixfa8wz
>>372
メンテが大変なのは自動テストがない場合だろ。
なぜ他の言語だとメンテが楽なの?
2014/10/12(日) 10:05:01.80ID:DxGoFyW9
>>371
UNITテストやるのもかなり大変だろ

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

考えただけでだるいわ
2014/10/12(日) 13:06:01.13ID:5ixfa8wz
>>375
それは仕様変更だろ。
TDDなら、メソッドの変更の前にテストの変更が来るし。
2014/10/12(日) 17:09:28.84ID:gqs4tO4e
>>375
ルビーの勉強がんばってください、入門者さんw
378デフォルトの名無しさん
垢版 |
2014/10/16(木) 00:02:19.53ID:Ju1r+RJJ
動物言語に見えた
2014/10/16(木) 07:57:26.33ID:Sk/7zxTc
面倒なのは全部ほかにまわせば確かに楽になるかもな
2014/10/18(土) 12:19:07.94ID:xyIEV5M1
巷に出回る仕事術の基本
381デフォルトの名無しさん
垢版 |
2014/11/24(月) 00:10:36.26ID:NFvfX/bb
動的言語ってリファレンスが読みにくくね？
みんなどうしてんの？
2014/11/24(月) 00:12:03.59ID:LP7Sk3Ho
暗記
2014/11/24(月) 00:16:50.33ID:PX1MFVrm
そんなん言語によるだろ
2014/11/24(月) 09:52:02.93ID:bceL07z7
>>381
具体的にどの言語のリファレンスが読みにくいと?
2014/11/24(月) 10:02:48.56ID:XLIBB3hZ
pythonしか知らんが、pythonはかなりドキュメント類がしっかりしてると思うけどな。

ただまあ、マイナー言語、ライブラリは動的静的カンケーなく、結局ソースを読むことにはなると思う。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも