1002コメント429KB

【JavaScript】ｽｸﾘﾌﾟﾄﾊﾞﾄﾙﾛﾜｲﾔﾙ54【php,py,pl,rb】 [無断転載禁止]©5ch.io

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2016/03/26(土) 10:24:19.80ID:pAOtj1vo

前スレ
【JavaScript】ｽｸﾘﾌﾟﾄﾊﾞﾄﾙﾛﾜｲﾔﾙ53【php,py,pl,rb】
http://echo.2ch.net/test/read.cgi/tech/1452141123/

【JavaScript】ｽｸﾘﾌﾟﾄﾊﾞﾄﾙﾛﾜｲﾔﾙ52【php,py,pl,rb】 [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1443578172/

問 Pythonで書くと誰でも同じような綺麗なコードになるか？
答なるわけないだろｗっていう考えが優勢

0002デフォルトの名無しさん

2016/03/26(土) 10:52:30.40ID:DMtjpEEP

本スレはここか

0003デフォルトの名無しさん

2016/03/26(土) 17:01:04.66ID:7Tf75UAJ

みんなの考える理想のスクリプト言語ってどんな感じ？
具体的にどういう機能がついたらいい？

0004デフォルトの名無しさん

2016/03/26(土) 18:29:20.25ID:TBBNVm1d

bashサイコー
ユニケージサイコー

0005デフォルトの名無しさん

2016/03/26(土) 19:04:01.19ID:H3Pgu2Oj

>>3
スクリプト言語に限らず、
全体の設計を反映させられる言語が欲しい。

例えばだね。このディレクトリ以下では
こっちのディレクトリのモジュールを直接 or 間接的にもロードできない。
という定義を書くことが出来る言語

lintでやれっていうのならそれでもいいけど、
それならばlintまで言語仕様に含めた言語

あとコンパイル時の動的書き換えという機能が備わっている言語
これにより実行時の動的書き換え（メタプログラミング）が減らせる。

0006デフォルトの名無しさん

2016/03/26(土) 21:14:27.02ID:LHzeZeLx

Lispと言ってみるテスト

0007デフォルトの名無しさん

2016/03/26(土) 23:32:11.09

>>3
普段はスクリプト言語なんだけど、
いざとなったら
マルチコア用C言語出力、VHDL出力、OpenCL出力
が出来てちょうはやい！みたいな

0008デフォルトの名無しさん

2016/03/27(日) 00:45:43.61ID:c+cANHSw

スクリプト言語以外の話はスレ違い

0009デフォルトの名無しさん

2016/03/27(日) 03:43:32.23ID:HhHg2DAX

やっとたった

0010デフォルトの名無しさん

2016/03/27(日) 12:20:59.67ID:Ewj9aPbh

>>5
Eiffelとか

0011デフォルトの名無しさん

2016/03/27(日) 15:46:01.25ID:gmYABHvb

Lua

0012デフォルトの名無しさん

2016/03/27(日) 17:37:50.66ID:MssBzCAo

サーバーからクライアントサイド、構成管理、セキュリティ、機械学習まで全部やってくれる
理想に近いのは、pythonかnode.js

0013デフォルトの名無しさん

2016/03/27(日) 20:28:58.17ID:+zvcgvl1

JavaScriptも最近共有メモリやSIMDなど、高速化に励んでるね

0014デフォルトの名無しさん

2016/03/28(月) 01:55:58.85

サーバサイドJSでマルチスレッド対応とか出来るんすかね

0015デフォルトの名無しさん

2016/03/28(月) 04:39:32.93ID:+hSVfs2f

独自でない標準の仕組みで出来るようになるのはこれから

0016デフォルトの名無しさん

2016/03/28(月) 11:24:45.51ID:3urpuCwS

マルチスレッドに対応したjxcoreという実装はあるみたいだけど、
node.jsのメリットってシングルスレッドなこととしか書かれてない

0017デフォルトの名無しさん

2016/03/28(月) 16:53:50.60ID:CG2l5UCc

>>16
メリットって書いてある所多いけれど、結果的にそれがデメリットにもなってる
ので、正直現実的には、そのメリットはメリットではない。

0018デフォルトの名無しさん

2016/03/28(月) 17:09:41.12ID:3urpuCwS

それって、どんな？

0019デフォルトの名無しさん

2016/03/28(月) 17:56:21.92ID:3hfk1W8A

>>17
実際デメリットになることは少ないよ
CPUが手一杯になる前にディスク等のIOが手一杯になることの方が殆どだから
それにNodeはシングルスレッドと言われるけど、実際はJS実行以外のIO処理部分はマルチスレッドで動いてる
そういう意味でもシングルスレッドで十分効率的だし、
もし重い暗号化や超莫大なアクセスなどによりCPUが手一杯になるような状況であれば、
それはNode以外のアプローチでも問題になるので、はっきりしたデメリットにはなり得ない。

0020デフォルトの名無しさん

2016/03/29(火) 10:58:37.95ID:Sc8o5eSf

>>19
時代は変わり、クワッドコア以上のメニコアCPUが当たり前になってきた
そういう中でCPUを使い切れないnode.jsのようなモデルでは「もったいない」という
意識が大きくなってきたのかもね
(この辺はRuby、PythonもGILがあるので似たような感じ)

0021デフォルトの名無しさん

2016/03/29(火) 11:00:00.66ID:g+fnLs+c

>>20
Java Servletのほうが起動で負けてもその後の処理の速さじゃ上だからなぁ。

0022デフォルトの名無しさん

2016/03/29(火) 13:49:56.87

node clusterとかあるのね

0023デフォルトの名無しさん

2016/03/29(火) 14:15:27.83ID:kZZssD4f

当然あるよ。マルチプロセスは昔からある。
問題になっているのはマルチスレッドの方で、
CPUベビーな演算をメモリを共有して多コアに分割したいという要求があるんじゃないかな。
それを実現するのがSharedArrayBufferで注目されてる。

0024デフォルトの名無しさん

2016/03/29(火) 18:00:59.56ID:m3uyviS2

"CPUベビー" 約 17 件（0.41 秒）

0025デフォルトの名無しさん

2016/03/29(火) 20:10:33.46ID:+jHesj4P

共有メモリとか遅すぎて笑えるんだよなぁ

0026デフォルトの名無しさん

2016/03/29(火) 22:56:54.99ID:uVxmQLgM

こういったスクリプト言語って、手続き型、関数型、オブジェクト志向みたいな
似たような概念を導入してるのばっかりな気がするんだけど
PrologやAlloyみたいな論理プログラミング系？概念を取り入れてるのとかないの？

0027デフォルトの名無しさん

2016/03/29(火) 23:59:40.44ID:ng9Foixk

業務ならルールエンジン使うでないの
形式手法とかならagdaなりZなり、それ専用のDSLがあった気するし

0028デフォルトの名無しさん

2016/03/30(水) 00:05:50.94ID:XIsq/GLZ

魔法少女たちが争うほど、キュウべえはソウルジェムを効率よく回収する
…。希望を与える側になりたいな

0029デフォルトの名無しさん

2016/03/30(水) 07:25:53.62ID:mic2/sJ9

計算モデルが全然違うようなものは静的解析なしだと実装が難しいんじゃないかな
処理系を実装するとき実装言語の実行モデルの制約を強く受けるから

0030デフォルトの名無しさん

2016/04/11(月) 22:56:39.80ID:NZ6O+Cpn

androidにswift採用されないかな

0031デフォルトの名無しさん

2016/04/11(月) 23:35:46.59ID:ACs+zaq9

Dartの方がずっと可能性が高い。
もっと高いのがWASM（つまりJS系とC系言語）。

0032デフォルトの名無しさん

2016/04/12(火) 06:26:38.73ID:kvjLZB7s

androidのAPIがswiftで提供されると面白いのに
OSSで使われる言語の勢力図が一気に変わるだろうし

0033デフォルトの名無しさん

2016/04/12(火) 06:31:22.04ID:kvjLZB7s

perlやPHPといった西部の開拓時代から
パンとサーカスに変わってしまったような気がする

0034デフォルトの名無しさん

2016/04/12(火) 15:20:01.25ID:ydgl7B5V

いや普通にGoの方が可能性高いでしょw
Dartってグーグル自身が見捨ててるじゃん

0035デフォルトの名無しさん

2016/04/12(火) 15:21:04.33ID:ydgl7B5V

>>33
そうだね、今はもうRubyとPythonの一騎打ち

0036デフォルトの名無しさん

2016/04/12(火) 15:31:25.97ID:lcRE+/VX

>>35
javascriptもあるんですけれど

0037デフォルトの名無しさん

2016/04/12(火) 20:21:25.22ID:+SzhD+eZ

Railsは枯れてることぐらいしか選ぶ理由がないわ

0038デフォルトの名無しさん

2016/04/12(火) 20:31:29.19ID:+SzhD+eZ

37番目の原子 = Rb（ルビジウム）

0039デフォルトの名無しさん

2016/04/12(火) 21:53:57.32ID:h5oBzMsU

>>34
Dartは無難すぎて目新しさもないし、流行らないが、
Javaの代わりとして業務で使うにはそれなりに優秀
Swiftだと歓声も多いだろうが不満の声も多いだろう
Dartなら仕方ないね、って感じになる

0040デフォルトの名無しさん

2016/04/13(水) 07:20:21.77ID:14EQ4o/q

DartなんかJavaと変わらん
わざわざコストかけて移行するほどの見返りがない

0041デフォルトの名無しさん

2016/04/13(水) 12:24:40.08ID:fabVc2ae

いや、iOSとandroidとサーバーサイドを同じ言語で書けることに意味があるだろjk

0042デフォルトの名無しさん

2016/04/13(水) 12:33:44.62ID:fabVc2ae

>>40
googleからすれば、oracleとのjavaのライセンス問題は大きいだろ
swiftが採用されるとscalaのコミュニティは死に体

0043デフォルトの名無しさん

2016/04/13(水) 12:47:12.71ID:0qDhR9cN

>>42
そんな事情はアプリ開発者には関係ないことだよね
事実としてDartは言語にTypeScriptやGoに負けたのであり、敗因の一つとして言語として魅力がなかったことがあるのは間違いない
いくら独善的なGoogleでもそれを無視するほど愚かだとは思えない

0044デフォルトの名無しさん

2016/04/13(水) 13:14:47.97ID:OPbsDvyC

> 敗因の一つとして言語として魅力がなかったことが

いや、言語の魅力とかどうでもいいんだよ。
優れた言語なんていくらでもあるし、○○という理由で優れてると言われれば
たいていそのとおりだって答える。

だけど、優れているけど、普及しないって答える。
なぜならば普及させるための力が不足しているから。

普及させる力っていうのは、多数の人間を巻き込む力だよ。
だから残念ながら個人が作ったようなレベルのものは
どんなに優れていても普及しない。

0045デフォルトの名無しさん

2016/04/13(水) 13:16:46.35ID:NQcPr1XX

タイミングの問題が大きいかな

0046デフォルトの名無しさん

2016/04/13(水) 21:12:22.21ID:7l1cW0em

>>40
違うでしょ。
Javaと左程変わらないからこそ移行先になり得る
Oracle問題もあることだしね

0047デフォルトの名無しさん

2016/04/13(水) 22:14:58.28ID:vsl30WgJ

>>46
だれも移らないよｗｗ
普及していない言語なんかで作るアホはいません。

0048デフォルトの名無しさん

2016/04/13(水) 22:25:28.69ID:7l1cW0em

>>47
もしAndroidがJava辞めたらっていう仮定の話で
Googleが何を選択するかという話なんだが
使う人は関係ないよ？
頭悪いの？

0049デフォルトの名無しさん

2016/04/13(水) 22:35:48.47ID:vsl30WgJ

>>48
頭悪いのはお前だよｗｗ
Java辞めたらなんて仮定の話は妄想でしか無いよｗｗｗ

典型的なクソネラーの詭弁と妄想垂れ流しの事例。

0050デフォルトの名無しさん

2016/04/13(水) 23:48:31.65ID:372sz71r

GoogleがJavaをやめたら、Goになるかな？

Goはそこそこ簡単で、Dockerも、Goで作られているし

0051デフォルトの名無しさん

2016/04/14(木) 00:42:57.93ID:1ngsth//

>>47
ObjectiveCもどメジャーになったじゃん。
あんなクソ言語俺は嫌いだけど。

0052デフォルトの名無しさん

2016/04/14(木) 05:47:30.78ID:1z1kQanE

>>49
数日前からswiftに移ろうかってニュース流れてるじゃん

0053デフォルトの名無しさん

2016/04/14(木) 06:06:38.29ID:1z1kQanE

facebook, uberはアプリをガッツリと書き直す必要があるから呼ばれたんだろう

0054デフォルトの名無しさん

2016/04/14(木) 07:25:21.55ID:Y2fJzZfu

とりまお前らスクリプト以外の話は↓に移動しろwww
そろそろブチ切れんぞwww

プログラミング言語バトルロワイヤル [無断転載禁止]©2ch.net･
http://echo.2ch.net/test/read.cgi/tech/1458953287/

0055デフォルトの名無しさん

2016/04/14(木) 08:56:29.77ID:TYUBRtt0

今日西日本は夏日みたいだね
ランチ時に手首チェックだね(*^o^*)

0056デフォルトの名無しさん

2016/04/14(木) 15:19:51.73ID:2FUdwcnv

切れてな～い(*^o^*)
みんな(*^o^*)
付けてな～い(*^o^*)

0057デフォルトの名無しさん

2016/04/16(土) 05:12:53.32ID:ipPZM4Ex

最近の記事は、やたらとrustが推されてるな
es6, ts,swift, golang, rust
あたりが第2ラウンドかしら

0058デフォルトの名無しさん

2016/04/16(土) 05:15:18.30ID:fIpUb4Vn

いやいや、そいつらと同じレベルにes6,tsはあがってないからｗ

0059デフォルトの名無しさん

2016/04/16(土) 05:21:25.88ID:ipPZM4Ex

システムとモバイル市場の取り合いだから候補だ

0060デフォルトの名無しさん

2016/04/16(土) 08:48:37.96ID:IQlNYOKE

c++からrustはまだいいか、他言語からrustは学習の壁が大きそう

0061デフォルトの名無しさん

2016/04/16(土) 09:36:18.27ID:fIpUb4Vn

>>59
ないない。純粋に好きかどうかの話だから
でない限りは Rust なんかそもそも出てこないｗ

0062デフォルトの名無しさん

2016/04/16(土) 19:15:51.75ID:ipPZM4Ex

>>61
そんな金にならないことを大の大人がするわけない
これは企業、団体によるOSSと呼ばれる土壌での主導権争いだよ
rustはmozilaが主導権を握っていて、韓国辺りでハードの実績もあった気がする

0063デフォルトの名無しさん

2016/04/16(土) 19:27:44.38ID:ipPZM4Ex

ウェブブラウザーレイアウトエンジンのServoと開発言語Rustか
Windows Kernel-Mode Driversって何に使うものなの？

0064デフォルトの名無しさん

2016/04/17(日) 13:14:29.45ID:oaifAOu8

>>63
何に使うてOS動作させんのに使うんだよ…

0065デフォルトの名無しさん

2016/04/18(月) 03:06:48.99ID:Gog4dBTR

Kernel-Modeって？

0066デフォルトの名無しさん

2016/04/18(月) 03:09:12.98ID:Gog4dBTR

なんかもう、javaからお金の匂いがしないんだ

0067デフォルトの名無しさん

2016/04/18(月) 03:33:01.30ID:zxdOCIHu

JavaはエンタープライズとかAndroid開発とか
トップクラスに金になる言語だと思うが……

0068デフォルトの名無しさん

2016/04/18(月) 08:47:59.59ID:y2e5lqrd

これからはJava vs Swift vs C#の熱き戦いが始まる

0069デフォルトの名無しさん

2016/04/18(月) 08:56:16.43ID:Dq5QFZ4E

>>68
始まらない。

まず、C#は論外だからだ。そして、Swiftは現状では全く普及しない。Obj-Cの全機能を単独で
網羅するまではね。それとサーバサイドが出来るわけじゃないからこの点も弱い。

Javaはその点優れてはいるが、唯一の問題点はOracleが保有してるって事。これがなければ、
圧勝。これがあるから、未来が不透明になってる。

0070デフォルトの名無しさん

2016/04/18(月) 08:57:11.64ID:Dq5QFZ4E

よって、現状では、熱き戦いは

JavaScript vs Pythonの戦いへとフェーズは移ってる。すでにphpやRuby、Perlは戦いの場からは
退いてる。

0071デフォルトの名無しさん

2016/04/18(月) 17:15:06.56ID:aBdawqFY

JavaScriptは今も昔もひたすら内輪でお祭りやってる感じで、
あまり他所のことは気にしてないと思うけどな。

0072デフォルトの名無しさん

2016/04/18(月) 20:24:53.29ID:vbsMxb6P

jsとpythonは喧嘩するほどパイ食い合ってないんじゃないかな。
RoRしか出来なかった偽技術者コピペ職人が死に絶えていくだけ。

0073デフォルトの名無しさん

2016/04/18(月) 20:57:37.39ID:p4RjCfAV

つかオッパイソン強すぎね？
ここ最近の無双ぶりは目に余るわ(´・ω・｀)

0074デフォルトの名無しさん

2016/04/18(月) 21:07:55.41ID:WqZxjq6c

オッパイソンって何？

0075デフォルトの名無しさん

2016/04/18(月) 23:08:41.45ID:lpJbhBIN

>>69
> まず、C#は論外だからだ。

iOSアプリを作るときに多く使われてる言語なんだが
なんで論外なんだ？

0076デフォルトの名無しさん

2016/04/18(月) 23:13:06.55ID:lpJbhBIN

クロスプラットフォームでアプリを開発するならば、
C#かJavaScriptの時代だよね。

http://news.mynavi.jp/series/xamarin/001/

近年の代表的なクロスプラットフォーム開発環境としては以下のものが挙げられます
(このほかにもさまざまなものがあります)。()内は開発言語です。

Xamarin (C#)
Cordova (HTML5/JavaScript)
React Native (JavaScript)
Unity (C#/JavaScript)
Cocos2d-x (C++)
RAD Studio (Delphi/C++)

0077デフォルトの名無しさん

2016/04/19(火) 08:28:36.18ID:FK9rMfbT

>>75←何いってんのこの馬鹿ｗ

0078デフォルトの名無しさん

2016/04/19(火) 11:17:17.47ID:8mIsIhVE

>>76
なんで、アプリとゲームのようなものを作る道具を同系列にまとめているんだろう

0079デフォルトの名無しさん

2016/04/19(火) 11:45:20.91ID:/d/wYc3X

まあ新しいもの好きが飛びつきそうなもののまとめとしては良いんじゃね

0080デフォルトの名無しさん

2016/04/19(火) 12:54:46.78

VBとC#、データベースを裏で管理するバックエンド用とか書かせたら最強に楽やで

0081デフォルトの名無しさん

2016/04/19(火) 13:03:04.96ID:8mIsIhVE

なんか、ものすごく上っ面な記事。Native Script入れろよ

0082デフォルトの名無しさん

2016/04/19(火) 15:23:04.67ID:zigSZk+A

>>78
Unityはもうゲームの枠を超えてるよ

0083デフォルトの名無しさん

2016/04/20(水) 00:03:27.56ID:DSTa2L5e

>>82
ゲームの枠を超えてるといっても、ゲームの枠以外で需要ありませんよ。
ましてや、ビジネスツールの世界じゃ全くもって不要。

0084デフォルトの名無しさん

2016/04/20(水) 00:28:27.68ID:INFX1qqF

>>83
知ってる会社で滅茶苦茶活用してるよ。
大手メーカーでだけど。造船業。
3Dcadのデータ確認するときの画面なんか使ってるよう。

0085デフォルトの名無しさん

2016/04/20(水) 07:06:22.38ID:olTR645v

CADはゲームに近いからなー

0086デフォルトの名無しさん

2016/04/20(水) 08:12:46.26ID:QzAvY/up

>>84
3DCADのどこが一般用となんだよ。ゲームと変わらん。

　

0087デフォルトの名無しさん

2016/04/20(水) 08:30:06.24ID:M3votfED

誰も一般用途だなんて言ってないけどな

0088デフォルトの名無しさん

2016/04/20(水) 10:21:41.09ID:1zVoxsrg

ゲーム開発してるけど、CADなんて近くもないわ

0089デフォルトの名無しさん

2016/04/20(水) 11:20:10.79ID:QzAvY/up

>>87
極論であるCADなどというごく特定の分野あげて、ゲーム以外にもなんて寝言ほざかれてもなｗｗ
そういうの詭弁っていうんだよ。覚えておけ。

0090デフォルトの名無しさん

2016/04/20(水) 11:28:32.66ID:O/Z089wj

会社の社内向けツールをUnityで作れないかなと考えたことがあったけど
会社の売り上げ的にライセンスが有料になるからやめた。

0091デフォルトの名無しさん

2016/04/20(水) 12:26:38.07ID:h2QcRVy8

その昔、ActionScriptで業務アプリが流行ったことがあってな…

0092デフォルトの名無しさん

2016/04/20(水) 15:52:10.15ID:pG+JJGrN

そりゃ、CADは特殊かもしれんが、確認用だよ。
製造現場用の画面。
このロットからネジ穴増えてるから、みたいなのを、ロットのバーコード撮ったら確認できるやつ。
三面図嫌いな世代に大好評だから、今後これ増えると思うわ。
個人的にはメモリ増設したいから、ってマニュアルぐるぐる回す時代が終わればいいなーって思ってる。

0093デフォルトの名無しさん

2016/04/20(水) 16:04:57.21ID:UfNx2Znx

普通CAD使うようなとこはCADソフト以外では
フリーの3DCGソフト使うのかと思ってた

0094デフォルトの名無しさん

2016/04/20(水) 19:31:44.77ID:1zVoxsrg

ゲーム会社でデザイン、モデリング、骨とかリグ作成、アニメーション、背景作成、テクスチャ作成、エフェクトやスクリプト、
VC++プログラミング、サーバーツールとかなんでもやってる。
200人くらいで作ってるけど、完全になんでも屋さんになってしまった。

009587

2016/04/20(水) 19:51:20.37ID:mGDJjSjC

>>89
俺がそれについて発言したわけではないけれど、
個人的にはこの程度詭弁だとは思わないよ
逆にお前さんの物の考え方や心が狭いなと素直に感じる

0096デフォルトの名無しさん

2016/04/21(木) 08:53:46.39ID:VFAF76A3

流れを切って悪い、、、が、ここはスクリプトスレだから完全にスレチだ

続きをやりたいなら↓ならOKだ！移動してくれ！
プログラミング言語バトルロワイヤル [無断転載禁止]©2ch.net･
http://echo.2ch.net/test/read.cgi/tech/1458953287/

0097デフォルトの名無しさん

2016/04/21(木) 16:22:35.03ID:qoF3fiWI

>>96
そういうスレを作ったからこういう変な奴らが涌いて出てきたんだよ。
ちなみにそのスレ、立てた奴は荒らし。わざわざここの次スレとして立てたわけ
だが、わざとスクリプト云々の下りを勝手に削除してる。

わざわざC#やjavaまで含めてそういうスレを立てたわけじゃない。

0098デフォルトの名無しさん

2016/04/22(金) 19:50:13.82ID:8NEdbrWR

スクリプト言語以外の話をする奴が多い状況で
内容に相応しいスレ（>>96）が立ったにも関わらず
何十分も後でこのスレを立てた>>1の方が荒らしだけどな

0099デフォルトの名無しさん

2016/04/23(土) 03:53:41.79ID:vKy9DOm2

ちょっと違うな
スクリプトスレだからこそ、スクリプトと、スクリプト以外という視点で
より深く語ることが出来る
今はスクリプト以外のターンだっただけで
このスレの意義が薄れたわけではない

0100デフォルトの名無しさん

2016/04/23(土) 12:23:53.97ID:kLHwicxw

>>98
いやほんっとそうなんだよ

0101デフォルトの名無しさん

2016/04/23(土) 12:37:23.76ID:bA1NlRjn

もうスクリプトって言葉の定義がわからない時代だからな
コンパイル言語もREPLできるし、スクリプト言語もJITコンパイルしてるし

0102デフォルトの名無しさん

2016/04/23(土) 15:44:32.79ID:EMoEOS7Z

自分は環境に捕らわれずどこでも馴染んで動く言語だと思っている。
つまりIOや環境に依存する仕様が標準に含まれておらず軽量な言語。

環境に依存したり低レベルでコアな部分を固い言語で書いて、
その他の柔軟に書きたい所をスクリプト言語に任せるというのが基本だと思う。

0103デフォルトの名無しさん

2016/04/23(土) 16:43:55.06ID:Wqyg3UTZ

うん、取り敢えず幾ら御託を並べてもスレタイは変わらないから
スレタイに沿わない話題は>>96な

0104デフォルトの名無しさん

2016/04/23(土) 18:15:11.36ID:V3oAolwO

新たに話を始めるのであれば違うスレでやるべきだけど、
元の話からの流れであれば同じスレでやるべきだよ
なにせ過疎ってるからね
別に現、その話題が止まっても違う話題が始まるわけでもないしね

過疎って無ければ、適切なスレに移ったほうが
より良い形で話が盛り上がるということも期待できるが、
過疎スレから過疎スレに移っても１つも良い結果は期待できない

0105デフォルトの名無しさん

2016/04/23(土) 20:35:52.26ID:Wqyg3UTZ

不毛な言い争いが起きるだけだから新しく建てた適切なスレに移動するのが一番の解決策だと俺は思うのだがね

0106デフォルトの名無しさん

2016/04/23(土) 20:53:28.12ID:w3viiANQ

これから新しい話を始めるのなら意味はある
でも既に発展した結果でこれ以上発展性の無い話題、レスにして精々１０か２０かの搾りかすを
あえて新しいスレに移動させることはない
例え言い争いが起きるとしてもわざわざ移ったりする意義もないと思う
言い争いと言っても些細なもんだし、この程度よく起きるし
ここまで過疎ってる現状じゃ、言い争いさえも一種の華だと思うからね
ルールだなんだの言ってもここまで過疎って制定時の想定と違けりゃ効力ももたない

0107デフォルトの名無しさん

2016/04/24(日) 04:20:42.79

スレ分離厨が蔓延ると過疎化するよな

0108デフォルトの名無しさん

2016/04/24(日) 11:48:41.45ID:jZAhFEZb

でも些細なものどころか、ずっと言い争い起きて不毛なレスが続くから新スレ建てたわけでしょ。
現に今もそうで、ならやっぱりスレタイに沿わない話題は移動するのが正解だと私も思います。

0109デフォルトの名無しさん

2016/04/24(日) 12:04:18.44ID:gM2IoXjQ

スクリプトの定義は知らないが、スクリプトに何の意味があるのかを考えると
ObjC++を争いに巻き込まないってことだよな
スクリプトが軍隊だとするとObjC++は軍需産業のようなもの

0110デフォルトの名無しさん

2016/04/25(月) 03:53:49.72ID:LMKLsb3i

>>108
言い争いが起きるからと唯一の話を潰しては本末転倒、
というかこの程度言い争いの内に入らない

0111デフォルトの名無しさん

2016/04/25(月) 10:30:05.67ID:oBslPZZj

別の場所でやれって言われてるだけ（しかも、その場所はちゃんとある）なのに
話が潰されると解釈するのか...
荒らしの精神構造は常人の理解を超えてるな

0112デフォルトの名無しさん

2016/04/25(月) 11:11:32.76ID:cM0AI0GO

良い精神構造って聞いたことないからな
いくら努力しても平凡な構造か悪い構造にしかならない

数学なら努力すれば100点満点を取れるが国語では取れないって話に似ている

0113デフォルトの名無しさん

2016/04/25(月) 15:15:01.92ID:pT1TeBQi

>>110
誰もスレタイに沿った話は潰してないと思うんだけど？
>>112
そうなんだ？初耳
私学生の頃、勉強しなくても国語だけは高得点取れてたからテストで国語はボーナスステージだったなあ

0114デフォルトの名無しさん

2016/04/26(火) 19:16:26.56ID:exhz7OXu

>>>111
常連ぶってる新参が居るけど、チンコだかakira developだか、perl忍者だかuyだと天使だとかの
糞コテがいた頃から、このスレでは昔からc++やhaskell,scalaの話題は出てきてたよ

0115デフォルトの名無しさん

2016/04/26(火) 19:18:15.34ID:exhz7OXu

>>105
此処って宗教戦争するスレなんだけど

0116デフォルトの名無しさん

2016/04/26(火) 19:37:48.56ID:h5Y7vUfm

>>115
>>105が言ってる不毛な言い争いってのは、言語間の宗教論争の事じゃないだろ

0117デフォルトの名無しさん

2016/04/26(火) 19:45:12.60ID:PAn5oHiy

少子高齢化になれば引退年齢も引き上がるように
スレチ判定の閾値は大幅に引き下げなければなるまい

0118uy ◆e6.oHu1j.o

2016/04/26(火) 20:45:27.76ID:4KSOxSiL

　　　　　　　　 |/＼　　　　　　　　　}､
　　　　　　　　 |///＼　_........＿　　/∧
　　　　　　　 {,＞‐―＝＝=:､:::｀///∧
　　　　　　　／:::::::::::::::::::::::::::::::::::::＜//∧
　　　　　　　　/:::::::::::,:::::::::::::::::::::::::::::ヽ:::ヽ//!ヽ
　　　　　　 ' :,:::::::::|::::::::/:::::::::::::::::::::|:::::::∨|:::::.
　　　　　　　 {__|:::::::::|:::::/:::::: |::::::::|:::: |::::::::::ﾏ}::::::.
　　　　　　 '::::Tヽ､}::::|{::::::::|::::::::|:::: |:::::::::::|':::::::|　　毎日監視してるぞ
　　　　　　　 |::::::|笊斥　｀ー'ー- 'ｰ-|:::: |::::|::::::::|
　　　　　　　 |::::::}弋ｿ　　　　孑芹ヽ |:::: |::::|:::::::;
　　　　　　　 |:イ{　　　, 　　弋ソ ' /::::::|:::｣::::::;
　　　　　　人　　　　　　 /_,..イﾉ:::::::::{
　　　　　　　　　 |::::... 　､　　　　　ィ:¨´:|::::::::::|
　　　　　　　　　 |::::::::＞-　-‐=≦ {-､::::::|::::::::::|
　　　　　　　　　 |::/´　　|∨´ 　イ / ｀ヽ､::::::::|
　　　　　　　　　 |∧　　 l,ィ､= '´ ／　　　_ヽ:::|
　　　　　　　 // 〉　 /ﾉ{_〉／　　／//}:::|

http://i.imgur.com/zP73aZN.jpg
http://i.imgur.com/evZWfxr.jpg
http://i.imgur.com/OJZ6niX.jpg

0119デフォルトの名無しさん

2016/04/26(火) 23:48:11.16ID:lvEC26Db

>>114
ほーん、そんな昔にscala の話題がねえ？？

0120デフォルトの名無しさん

2016/04/30(土) 10:59:07.82ID:mBnyvVIH

どこかの会社が不正アクセスを受けニュースになる

その会社名とphpでぐぐると

不正アクセスを受けたサイトと拡張子のphpが出てくる

どこもこんな感じ

エイベックス３５万件情報流出か…不正アクセス

ぐぐると

avexnet.jp/column.php

0121デフォルトの名無しさん

2016/05/01(日) 07:17:40.73ID:tKi6j9CT

匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？

Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ

The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
q

0122デフォルトの名無しさん

2016/05/01(日) 07:23:55.78ID:7qCLV65c

このバカあっちこっちにコピペしてるな
自分でやれ

0123デフォルトの名無しさん

2016/05/02(月) 04:26:33.84ID:x1k0SuF1

PCチップ自体にバックドアが仕掛けられてるので
いくら経路を匿名化しても意味が無いのにね

0124デフォルトの名無しさん

2016/05/02(月) 23:59:22.39ID:l4IMFFBv

説明しようとしたら意味不明と言われ、隠そうとすれば全てお見通しだと言われる法則

0125デフォルトの名無しさん

2016/05/03(火) 12:01:32.47ID:YtCRz7OH

説明しようとしたら全てお見通しだと言われ、隠そうとすれば意味不明と言われる法則

0126デフォルトの名無しさん

2016/05/04(水) 10:54:33.94ID:RMdId/Ea

torってrustで書き直されるの？hacker newsに何かポストされてたんだけど

0127デフォルトの名無しさん

2016/05/07(土) 01:15:14.89ID:hzMSDoFD

つうか国レベルで匿名のインターネットを支持してるところは無いのかな

海外のサイトへ出張して犯罪予告等した奴はそっちの国の法律で逮捕されれば良いとして
国内サイトの書き込みくらいは自由になってる国があっても良いと思うんだけど

0128デフォルトの名無しさん

2016/05/07(土) 04:30:16.08ID:spVNXjUP

それは型の話かな
例えばC言語にはstring型がない
string型を定義できる言語は無いのかなという類の話かな

0129デフォルトの名無しさん

2016/05/07(土) 09:55:07.45ID:spVNXjUP

C言語にprivateはないがvoidポインタがある
情報隠蔽したいなら型情報を捨てる
スクリプト言語に似ている

0130デフォルトの名無しさん

2016/05/07(土) 13:57:11.33ID:9sVhBsvt

>>129
C言語の問題はそのvoidポインタを
実際に使うときに、とある型にキャストした時、
不正な型にキャストした場合、どういう挙動をするかわからないことやで？
大抵はアプリが落ちる。アプリ側で対処ができない。
（OSに不正な操作をしたと補足される）

0131デフォルトの名無しさん

2016/05/07(土) 15:23:13.35ID:Orn8oH5O

その場で落ちてくれたらいいけど、中身を書き換えようとする場合は大抵そのまま動き続けてしまうのが問題
しばらく後で全く関係のない場所で落ちて再現もできないという地獄のデバッグが待っている

0132デフォルトの名無しさん

2016/05/07(土) 15:44:11.36ID:spVNXjUP

アプリは完成したがデバッグが終わらない地獄と、仕様書が完成しない地獄
本当の地獄はどっちだ

0133デフォルトの名無しさん

2016/05/08(日) 02:53:38.80ID:Ed3pQgZP

今週から来週火曜くらいまでの都内での仕事ないかな？
PHP、html、css、MySQLのやつで

0134デフォルトの名無しさん

2016/05/08(日) 03:16:24.19ID:f7kO+OHl

>>133
こんな所で仕事探しですか？ｗｗｗ
悪いけれど、君、別の職に転職したほうがいいですよ。

0135デフォルトの名無しさん

2016/05/08(日) 03:48:10.15ID:Ed3pQgZP

>>134
いや自営なんだけど来週火曜まで時間あるから何かないかなと思って笑
@sohoは糞みたいなのしかないしランサーズは振り込みまで時間かかるし単価低めだから

0136デフォルトの名無しさん

2016/05/09(月) 04:20:01.62ID:O0aPuFTH

>>135が>>134の回答になっていない。
俺だったら>>135には更に>>134を贈るよ。

0137デフォルトの名無しさん

2016/05/09(月) 18:13:28.52ID:p86o9cYn

フリーランス = 金をたかるニート、無職

0138uy ◆qyQFqJlM.A

2016/05/18(水) 10:14:37.83ID:wLT3W3zr

そこまでプログラミングだけをし続ける理由とは

経済の本でも読めよ

0139uy ◆d/Q/zTMI4I

2016/05/18(水) 10:16:48.25ID:tltkMhqB

ｒ＞ｇ説明できる奴とかこのスレにいんの？

0140uy ◆e6.oHu1j.o

2016/05/18(水) 10:18:05.59ID:tltkMhqB

ちなみにプログラマはｇだから
俺はｒになりたい

0141デフォルトの名無しさん

2016/05/18(水) 12:29:14.77ID:rFetSORz

1. Java
2. C
3. C++
4. C#
5. Python
6. PHP
7. JavaScript
8. Ruby
9. Perl
TIOBE Programming Community Index（2016年5月現在）
ttp://codezine.jp/static/images/article/9424/9424_001_s.gif

0142デフォルトの名無しさん

2016/05/20(金) 15:01:12.96ID:wopR+qmh

1. Java
2. C
3. C++
4. C#
5. Python
6. PHP
7. JavaScript
8. Ruby
9. Perl
TIOBE Programming Community Index（2016年5月現在）
ttp://codezine.jp/static/images/article/9424/9424_001_s.gif

やっぱJAVAは圧倒的だな
いつの時代も使われ続ける正に王者言語

0143デフォルトの名無しさん

2016/05/20(金) 17:18:07.22ID:LibjMvA5

Javaが王者で尚且つSwiftがPerlより下というデータ
これが本当でも嘘でもどっちに転んでも面白い

0144デフォルトの名無しさん

2016/05/21(土) 00:54:38.69ID:HfICoxOz

単に業務システムのパイが大きいからといって、
Railsで書けるものをJavaで書くとかアホ

0145デフォルトの名無しさん

2016/05/21(土) 01:12:20.55ID:zFXtMIoH

javaの案件って公共系・業務系が多くて楽しく無さそうなんだよなぁ。

0146デフォルトの名無しさん

2016/05/21(土) 01:36:25.79ID:NEdgpV5s

>>144
そういう意味では、ネットワーク屋やら機械屋やら、鯖屋にクリティカルなシステムでのノウハウ持ってるのはJavaのシステム持ってるところのインフラ屋かそういうインフラ専門の外注さんで、
安定性が高いからとそこと相談としたら、もちろんJavaとOracleなら経験あるから提案出来ますよと言われるだろうし、
予算も渋くなってる上に安定性必須であれば、挑戦的な事もできまいて。

アホではなく、大規模システムの宿命。

0147デフォルトの名無しさん

2016/05/21(土) 08:04:07.63ID:ZKE9PCIn

>>145
業務系の仕事がつまらんのはSIer的な仕事のやり方のせい
業務は複雑なモデル、多彩な要件、幅広いインフラ、豊富な予算と
本来は画一的で単純なWebの世界なんかよりよっぽど面白いはずなんだけどな

0148デフォルトの名無しさん

2016/05/21(土) 09:55:04.75ID:Mz4EC8ZB

単に土方だからつまらなく感じるだけだよ
客とも接するエンジニアな俺は超エキサイティングしてるよ
つまりだ、上流もこなせるスーパーなエンジニアに昇格しろってこと

0149デフォルトの名無しさん

2016/05/21(土) 09:58:12.96ID:Mz4EC8ZB

建築の世界と一緒よな
一級な建築士や設計側はそこまで行くまでに超絶大変な努力と競争があるけども、
頑張ってそこの高みに昇ったらやっぱり仕事は超絶大変だけど、でもスペシャルなやりがいあるんだよね
ただ言われた通り設計書通りに建てるだけの土方や大工作業はつまらなかろうてな

0150デフォルトの名無しさん

2016/05/21(土) 10:01:43.53ID:Mz4EC8ZB

いまさ、医療系の大規模案件に携わってるだけどさ
医師や看護師、管理栄養士や薬剤師さんたちと接し話す機械も多いわけよ
逆にためになる話も聞けたりするしやっぱ楽しいよ、コミュニケーションは人間最大の娯楽でもあるしさ基本だからさ
そんで、やっぱ看護師とか管理栄養士さんは女性の花形職なだけあって超絶可愛い子多いわけさねムフフwww
女医さんでも皮膚科とかやっベーくれえレベル高い人多いしさムフw

0151デフォルトの名無しさん

2016/05/21(土) 10:08:02.70ID:KCP4eHIs

「コミュニケーションは娯楽」って「趣味は読書」と大体同じ意味かな

0152デフォルトの名無しさん

2016/05/22(日) 11:05:51.45ID:nAbx5yIi

phpてオワコン？
サーバーサイドのスクリプト言語を今から勉強するならpythonかruby？

0153デフォルトの名無しさん

2016/05/22(日) 17:46:59.90ID:4mJaXPXt

>>152
JavaScript(Node.js)

0154デフォルトの名無しさん

2016/05/22(日) 17:51:55.41ID:AXHEbi5z

phpかjavascriptかjava

0155デフォルトの名無しさん

2016/05/23(月) 00:45:52.23ID:gRYaeUIq

>>152
まずはJAVA、次にRubyかPython
結局デファクトスタンダードを避けて通ると遠回りになるだけ>>142

0156デフォルトの名無しさん

2016/05/23(月) 00:47:34.31ID:2wwYSKoz

デファクトスタンダード >>142

1. Java
2. C
3. C++
4. C#
5. Python
6. PHP

7. JavaScript
8. Ruby
9. Perl

0157デフォルトの名無しさん

2016/05/26(木) 04:07:45.29ID:ckoChVZB

>>155
それにオワコンって言ったって、いきなり終了するわけじゃなく、
言語系は息が長いからね。ITの世界じゃ。ITだからといって勘違い
してる人多いけれど。

0158デフォルトの名無しさん

2016/05/26(木) 20:04:39.52ID:Z1TdUIbU

沈んでいく船に乗らないほうが良いよ
先進的なプログラミングやってないと頭がおかしくなって死ぬ

0159デフォルトの名無しさん

2016/05/26(木) 21:44:00.77ID:KC4eoHCe

そういう意味ではクリエイティブコーディングは色々と良いよな
Processingを触っててそう思った
あと最近オッパイソンの勉強しててiPhoneでパイソニスタ3.0弄って遊んでる
オッパイソンも実はクリエイティブコーディングに適してたりするんよな

0160デフォルトの名無しさん

2016/05/26(木) 22:37:13.23ID:WD90lv2d

クリエイティブコーディングを否定する気はないが、
同じような唐突なレスを延々繰り返すお前にはクリエイティビティの欠片も感じられない

0161デフォルトの名無しさん

2016/05/27(金) 10:33:54.14ID:tz1kvqlr

船が沈むとか破壊的な言葉を自分だけが使うためにクリエイティブと言ってるんよ
自分は好きなだけ攻撃するけど他人には攻撃させないチート技だよ

0162デフォルトの名無しさん

2016/05/27(金) 19:47:53.95ID:cARv9Q4b

しっかしプログラミングが芸術表現のツールとして浸透し始めてるな

0163デフォルトの名無しさん

2016/05/27(金) 20:51:31.89ID:7o0+MXnc

>>158
死ぬのはお前だけだよ

0164デフォルトの名無しさん

2016/05/27(金) 20:51:58.36ID:7o0+MXnc

>>161
チート技？ただ自分に酔ってるだけのキチガイだろ。

0165デフォルトの名無しさん

2016/05/27(金) 23:01:14.52ID:Drz4UeTd

芸術家がプログラミングアートをやるのは表現の幅を拡げることになるだろうが、
プログラマがやってもそれは何も生み出さない袋小路でしかないだろ。

0166デフォルトの名無しさん

2016/05/27(金) 23:11:52.60ID:AtAaCgiB

ま、別にそれらは排他的なもんじゃないからな。
どっちもやっていい。

0167デフォルトの名無しさん

2016/05/28(土) 10:22:27.05ID:3VcdBotu

芸術ってのは１万時間の法則に当てはまるようなものであって
本１，２冊読んだら出来るようなＷｅｂデザインは当てはまらないと思うわ

0168デフォルトの名無しさん

2016/06/01(水) 18:35:02.57ID:kQlSk790

クリエイティブコーディングも勿論1万時間の法則に当てはまる

0169デフォルトの名無しさん

2016/06/01(水) 22:32:18.23ID:m3KkndXk

個のスレなんでこんな勢い無くなったん？
またPythonとRubyのどうでもよいことで喧嘩して見せてよ

逆になんで昔は勢いあったんだろうね、ふっしぎー

0170デフォルトの名無しさん

2016/06/01(水) 22:49:45.95ID:XVpspPb0

JavaScriptの一人勝ち時代になったからなｗ

0171デフォルトの名無しさん

2016/06/01(水) 23:12:38.57ID:llIYTUCe

言語間の差が無くなってきたから、何かを語るにしろ一番広く使われてるJSを使えば済むようになってしまったから。

0172デフォルトの名無しさん

2016/06/02(木) 00:04:26.85ID:VnZHQmYV

JSはライブラリが貧弱すぎるのがなぁ

0173デフォルトの名無しさん

2016/06/02(木) 00:16:25.46ID:X+hQPb++

PerlはCPANの存在がでかかったなぁ。
何かやりたいことがあったときにCPAN行けばたいてい見つかるという。

0174デフォルトの名無しさん

2016/06/02(木) 11:00:08.06ID:SjNFLCPa

>>170
逆にjsさん下火になって存在感が空気な気がするんだがw
つかもうPythonの強さが抜きん出てるよ、まさか日本でこんな短期間に新刊ラッシュ来るとかもうね

昨今流行りの機械学習とかセキュリティ系が大きいんかね

0175デフォルトの名無しさん

2016/06/02(木) 12:33:24.75ID:1F6qEVer

今はC++を簡単にJSに移植できるから
C++の言語仕様を変えなくても実行環境を変えるだけで安全なら
言語仕様には意味がなくなった

0176デフォルトの名無しさん

2016/06/02(木) 13:18:55.74ID:BtmdPReZ

>>174
JSは実用言語だからね。もう息を吸うくらいに普通に使う言語になってる。
でも言語ってのは普通縁の下の力持ちでいいの。
確かにスクリプト言語としてこういうスレでワイワイすることに弱いのは残念だけどね。
まあ子供(Python)と大人(JS)の違いみたいなもんだよ。

0177デフォルトの名無しさん

2016/06/02(木) 22:10:56.75ID:khWGy11Q

>>169
>またPythonとRubyのどうでもよいことで喧嘩して見せてよ

関数型言語に関するトピックに限定すれば、
Lispをベースに開発されたRubyと、手続き型言語をベースに
関数型風のライブラリを強化しただけのPythonとでは、
最初から勝負にすらならなかったのが三年前に明らかになったからね

・LLにおける関数型プログラミング
　http://echo.2ch.net/test/read.cgi/tech/1345123070/
・Lisp から Ruby への設計ステップ | プログラマーズ雑記帳
　http://yohshiy.blog.fc2.com/blog-entry-250.html

同じくLispをベースにしたJavaScriptもあるけど、
Webブラウザ上におけるJSの絶対的優位性に当時も今も変わりは無いし、
上手い具合に棲み分けができている
結局、個人あるいは組織の選択でスクリプトを言語使い分ける時代に
なったのではないかと思われる

0178デフォルトの名無しさん

2016/06/02(木) 23:05:40.74ID:EkiyB7w0

関数型言語も何か一過性のブームで終わってしまったよな

0179デフォルトの名無しさん

2016/06/03(金) 00:41:20.94ID:ZgLr+wQe

どうなんだろう。一過性ねぇ。
むしろ、これからメニーコアの時代に効率的だという話だったと思うけど？

0180デフォルトの名無しさん

2016/06/03(金) 01:02:58.01ID:4VbjelCP

メニーコアってもう死後じゃないの？
最初の頃に、これからコアがたくさん増えるんだって
一部のアナリスト（笑）が言ってたけどそうはならなかった。

0181デフォルトの名無しさん

2016/06/03(金) 01:51:58.03ID:u2s7AyU8

>>180
え？コアは確実に増えてるけど？
i7 とか使ってないの？

0182デフォルトの名無しさん

2016/06/03(金) 01:55:39.99ID:qC3of5q8

まあそれに関してはなんとも言えんな。
一応家庭用CPUコアも今年2桁の時代に突入したし、
モバイルでも非対称性コア両方使えるモデルが増えてきた。
そろそろっちゃそろそろかもしれない。

0183デフォルトの名無しさん

2016/06/03(金) 02:20:41.67ID:4VbjelCP

>>181
数年前から使ってるけど
ずっと増えてないよｗ

0184デフォルトの名無しさん

2016/06/03(金) 06:53:31.32ID:u2s7AyU8

>>183
じゃあ、i7 も増えてるの知ってるっしょ
ましてサーバの世界は…

0185デフォルトの名無しさん

2016/06/03(金) 08:43:19.65ID:vF3FMBkK

うーん。例えばXeonみたいなののマルチコアってのは、
それこそサーバとしてマルチプロセスが難しいことしないで使い合うことが主だし、
Phiもコプロセッサとして専用に使われることが主で、
１つまたは数個のプログラムのあらゆる汎用的な処理が数十のコアで、
自動的に適切に負荷分散されるという状況は色んな意味でまだだと思うのよね。
家庭用CPUコアが20、30になってからが本番かな。

0186デフォルトの名無しさん

2016/06/03(金) 09:30:37.34ID:4VbjelCP

>>184
増えてるって言っても
全然メニーのレベルじゃないじゃんｗ

0187デフォルトの名無しさん

2016/06/03(金) 10:42:41.35ID:YDucuFJ8

多数のGPUの性能をまとめ上げて
機械学習に使うためにGoogleはPythonを使った

0188デフォルトの名無しさん

2016/06/03(金) 12:17:07.05ID:SfjRKH7V

Pythonって良く文法スッキリしてて簡潔に描けて初学者に易しいとか学びやすいとか言われるけどさ
俺にとっては凄く分かりづらくて二度三度挫折してるんだけどw
最初はProcessingから入って結局またProcessingに戻っていまRubyとJAVA勉強してるわ
どうして俺はこんなにもPythonがダメなのか、入門系の本一冊終わらせても全くコード描けないんだよね

0189デフォルトの名無しさん

2016/06/03(金) 13:09:09.94ID:D6MzcBW9

>>188
Ruby多少でも書ける奴が入門系の本一冊終わらせてもPythonで書けないって
いくらなんでもホラやろ？
お前さん言ってるだけでProcessingしかできんのとちゃうか？

0190デフォルトの名無しさん

2016/06/03(金) 13:14:01.28ID:D6MzcBW9

すまんな、RubyとJavaはまだできないんか
Processing使いなら、JavaScriptお勧めするで

0191デフォルトの名無しさん

2016/06/03(金) 13:14:16.08ID:M9HYxoxd

>>188
俺も Python には妙な気持ち悪さを感じる。クラス設計とか
ライブラリ設計が何か変なんだよ。188 が全くコードが書けない
ってのはその辺も関係してるんじゃないかな

0192デフォルトの名無しさん

2016/06/03(金) 14:03:32.02ID:Hg3pyaIr

pythonって挫折するほどか？

0193デフォルトの名無しさん

2016/06/03(金) 15:03:57.06ID:84DnCFa9

JavaScriptで以前書いたものを、必要に迫られて、
全くの初心者が意外とあっさりとPythonで書きなおすことができたけど、
何らかのスクリプト言語を書いたことがあれば、Pythonは優しい部類に入る印象だな。
ただ、正規表現を使った文字列置換なんかの処理方法はJavaScriptと比べて書き方に癖があると思った。
まぁ、慣れの問題なのかもしれないけど。

0194デフォルトの名無しさん

2016/06/03(金) 18:33:09.06ID:ILPCC37T

おかしいのはみんなPerlのせいだよ……
「サーバーサイド言語」として設計されてるからおかしい……

0195デフォルトの名無しさん

2016/06/03(金) 19:34:37.27ID:/b77BlBb

Pythonのライブラリはスクリプトには珍しく直交性指向なのでJavaやってると馴染みやすい

0196デフォルトの名無しさん

2016/06/03(金) 22:17:49.86ID:lTBCVPxn

>>189
Rubyはまだ触り程度なんだ
本当に何故かPythonは頭に入ってこない

0197デフォルトの名無しさん

2016/06/04(土) 09:04:33.86ID:e6sAKa4x

Perlアンチは普通に正論を言うがPythonアンチは言葉が通じないんだよな
ガス抜きすらさせないからモンスターになる

0198デフォルトの名無しさん

2016/06/04(土) 09:17:02.75ID:BB4QGX3V

Pythonは自然言語の感覚より論理的な一貫性を重んじる言語だからね
アンチはそれができないわけだから話が通じないのは当然といえる

0199デフォルトの名無しさん

2016/06/04(土) 10:37:24.76ID:e6sAKa4x

まあ論理的というよりポリティカルコレクトネスという方が近い

0200デフォルトの名無しさん

2016/06/04(土) 13:33:06.64ID:8iP9+l2z

Pythonコミュニティの永久凍土問題は根深いね

0201デフォルトの名無しさん

2016/06/04(土) 13:34:26.73ID:1BuR5uBf

Python内包表記だけはキメラ感があると思う
あそこはどこから目をつけるか身構えるので自然に流して読めない

0202デフォルトの名無しさん

2016/06/04(土) 13:46:13.22ID:BB4QGX3V

美しいだの楽しいだのくだらないことに気を散らされずに中身に集中したいからPythonを好むわけで、
盲信してるわけじゃなくて言語のここがイケてないとかいう話には単に興味がないんだよ
言語を変えようとするより自分の考えを変えるべき、なぜならその方が確実で手っ取り早いから
これがPython使いの思考回路

0203デフォルトの名無しさん

2016/06/04(土) 14:06:37.44ID:+FHAhRuI

ジェネレータの文法は、どうしてこうなったという感じだな。

0204デフォルトの名無しさん

2016/06/04(土) 14:38:20.88ID:8iP9+l2z

>>202
楽しいがくだらない？
そんな悲しいプログラミングはしたくないな

0205デフォルトの名無しさん

2016/06/05(日) 17:40:23.75ID:bBqsqHAQ

普通の人→書いたものが動いたら楽しい
言語そのものに楽しさは求めてないってことでしょう

0206デフォルトの名無しさん

2016/06/05(日) 19:58:41.16ID:ENKFTBjK

言語そのものに楽しさを感じる人なんて居ない。
例：「英語が楽しい」
→英語でコミュニケーションの幅が広がるのにワクワクする
→英語という新しいことを覚えることに期待感を感じる

0207デフォルトの名無しさん

2016/06/05(日) 20:08:22.82ID:rqrEGD9X

一方Rubyは
例：「Rubyが楽しい」
→自分の考えをRubyで書き下すことに快感を感じる
→自分が書いたコードを眺めることで自尊心が高められる

0208デフォルトの名無しさん

2016/06/05(日) 20:11:21.34ID:PAgdOZpu

言語そのものに楽しさを感じる人なんて居ない。
例：「COBOLが楽しい」
→COBOLでプログラミングの幅が広がる（？）のにワクワクする（？）
→COBOLという新しい（？）ことを覚えることに期待感を感じる（？）

0209デフォルトの名無しさん

2016/06/05(日) 22:39:31.65ID:qQwurt0w

>>205
書いたものが正常に動かなくても楽しさを感じる人はデバッグの才能がある

0210デフォルトの名無しさん

2016/06/06(月) 06:48:17.77ID:0E5uzmOu

>>177
じゃあLispでいいじゃん

0211デフォルトの名無しさん

2016/06/07(火) 00:08:51.24ID:AF8c7GVP

>>177
> Lispをベースに開発されたRubyと

それ酒の席でのジョークだってよｗ

0212デフォルトの名無しさん

2016/06/07(火) 00:10:51.11ID:AF8c7GVP

しかも、本人が言ったわけじゃないしｗ

まつもとゆきひろのハッカーズライフ：
http://www.itmedia.co.jp/enterprise/articles/0801/29/news010_2.html
　以前、某イベントの二次会で「実はRubyって『MatzLisp*』というLispの方言だったんだよ！」と
語られたようです。何とも傑作なネタですが、Lispの強さを痛感したわたしが「自分が満足するために」
作り出したRubyは、文法こそ違うものの、その本質としてLisp文化を継承しているのかもしれません。

0213デフォルトの名無しさん

2016/06/07(火) 00:15:02.79ID:Gat57in+

>>212
> JavaはLispで培われてきた技術を広く知らしめるのに貢献しました
この「技術」って具体的に何？教えてエロい人

0214デフォルトの名無しさん

2016/06/07(火) 01:03:46.31ID:SyeB6ZIU

ＧＣじゃないの

0215デフォルトの名無しさん

2016/06/07(火) 01:29:22.73ID:Gat57in+

>>214
サンクス。あれってLisp発だとは知らんかった。

0216デフォルトの名無しさん

2016/06/07(火) 22:53:43.81ID:t1Wr8SOh

LISPはFORTRANの次に古い言語だけど、そこから生まれたたものはいろいろあるよね。

0217デフォルトの名無しさん

2016/06/12(日) 22:50:20.13ID:h2Zr7DaC

>>211,212
>しかも、本人が言ったわけじゃないしｗ

>>177で紹介したブログ記事の原文(英語)を読んだのかな？

・Re: Ruby's lisp features. -- From: Yukihiro Matsumoto <matz ruby-lang.org>
　http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/179642

Rubyの公式メーリングリスト(ruby-talk)へMatz本人が投稿した記事だから
話題性があり、わざわざブログ主様が日本語へ翻訳してくれた訳だが…

これまでMatzはRubyがどのように誕生したのかについて、
「自分が満足するために(>>212)」のように曖昧な表現でしか語ってこなかった
おそらく現実にはRuby誕生に明確な開発方針は存在せず、後からMatzが振り返って
過去の自分の試行錯誤をかっこよくまとめたものだと想像するけどね

>>211,212(ID: AF8c7GVP)が日本語が不自由な出自なのか、それとも
英語が読めない低学歴なのかは知らんけど、2chの底辺レベルがよくわかる

0218デフォルトの名無しさん

2016/06/12(日) 23:53:46.97ID:h2Zr7DaC

>>216
GC(>>214)の他に思いつくのは、対話型プログラミング環境とクロージャだね

対話型プログラミング環境については、以下の文献が歴史的論文になる
・対話的環境でのプログラミング -- LISPでの環境
　E.Sandwall著黒川利明訳、bit別冊（コピーしか手元にないため号数等は不明）
　ACM Computing Surveys, Vol.10, No.1, pp35-72, Copyright 1978 ACM
以下、序文を引用しとく

　LISPシステムは10年以上ものあいだ、高度に対話的なプログラミングのために
　用いられてきた。そのあいだにプログラム/データ同一性のようなLISP言語の
　特性は、対話的プログラミングのある一形式を発展させた。その特徴は、
　プログラマ向けの強力な対話支援システム、標準的でないプログラム構造、
　そして標準的でないプログラム開発手法にある。本論文は、LISPには
　門外漢といえるような読者のためにLISP式の対話プログラミングとは
　どのようなものかを要約したものである。LISP形式のプログラミング・
　スタイルの開発に本質的な役割を果たしたLISPシステムの性質と、
　現在もなお解決されていない問題について述べる。

　

0219デフォルトの名無しさん

2016/06/13(月) 22:01:14.03ID:MNz7ERM2

unix系のスクリプトでは「文字列とevalで十分」という文化が最も古くて
GC (を必要とするデータ構造) とクロージャは新しい

0220デフォルトの名無しさん

2016/06/18(土) 15:15:46.62ID:XE3kav/o

スラドにこんな記事あった

RubyがPythonのようなポジションを得られなかったのはなぜか
http://developers.srad.jp/story/16/06/17/0827240/

最近日本でもPython本急に増えた印象あるよね。
やばいのかなRuby。

0221デフォルトの名無しさん

2016/06/18(土) 16:11:23.75ID:PRpJO7Zd

Rubyというか、オブジェクト指向の継承地獄やコールバック地獄がやばい

0222デフォルトの名無しさん

2016/06/18(土) 20:39:19.89ID:FWD8oLz6

Rubyは作ってるヤツが言語オタクだからか、頑張り方がトンチンカンなんだよな
速度が遅いと言われたら、処理系を弄って速くしようと頑張ってみたりさ
でも頑張ったところで「スクリプト言語にしては」速くなったってだけだから、本当に速度が必要なケースでは論外

一方、PythonはnumpyでBLASとリンクして速くしようとか、CythonでCにコンパイルして速くしようとか、
TensorflowやTheanoみたいにGPUを使って速くしようとか、
ガチで速度が必要なニーズを満たすプロダクトが多い

0223デフォルトの名無しさん

2016/06/18(土) 21:26:15.99ID:zoBBTSWo

今はそうでもないだろ
今のRubyの最適化は完全にRailsを高速化することがターゲットになっていて
Railsのみに特化した様々なチューニングが行われている
明確な目的に対して現実的なアプローチで成果を出しているという点でPythonと本質的な違いは無くなった

0224デフォルトの名無しさん

2016/06/18(土) 21:39:10.28ID:fQZoZn4T

いやマジでほんっとパイソン本のリリースラッシュが続いてるからな
恐らく日本で流行ったのは名称によるところも大きいかなと
「オッパイソン」
これな、日本人はとかくオッパイ星人だからね

後はもう手軽に始められるってところ、Jupyter notebookとか対話的環境が神がかってる

0225デフォルトの名無しさん

2016/06/18(土) 23:46:13.77ID:bAWm0vYv

Rasbperry Piも流行りだしたからな。
Rasberry Rubyだったらもうちょっと延命できたかもな。

0226デフォルトの名無しさん

2016/06/19(日) 01:52:50.75ID:nfFKArFK

Rubyがんばれ！

0227デフォルトの名無しさん

2016/06/19(日) 06:44:50.67ID:f+vlUbou

pythonはredhat系linuxのデフォルトが3系になってからでも十分だな。

0228デフォルトの名無しさん

2016/06/19(日) 09:30:41.89ID:bljjS0X+

railsってバージョンアップするたびにクソ遅くなってるよね

0229デフォルトの名無しさん

2016/06/19(日) 09:57:17.82ID:qvkTbkKV

>>226
応援なんかいいからRailsに次ぐキラープロダクトをお前が作ってやれよ
Railsも落ち目だし、このままだと確実に消えちゃうぞ?
世界的に有名なプロダクトなんて欧米発のRailsやChefくらいしかなく、
結局日本のRubyコミュニティって何一つRubyの普及に貢献できてないじゃん

0230デフォルトの名無しさん

2016/06/19(日) 09:59:46.40ID:D+cvxmoX

はてな界隈での他言語のパクり機能をrubyで作ってみたwwwが関の山だったな

0231デフォルトの名無しさん

2016/06/19(日) 12:27:20.65ID:umry5YEW

LispとRubyの目的はメタプログラミングだぜ
文字列ではなくリストやオブジェクトの操作でプログラムを書きかえる
だがメタプログラミングに興味がなければ明確な目的もなくなる

0232デフォルトの名無しさん

2016/06/19(日) 13:14:07.79ID:oY7TlxuV

Rubyには、黒魔術(メタプログラミング・実装)系の良本が多い

メタプログラミング Ruby 第2版、2015
Effective Ruby、2015
Rubyのしくみ、2014

日本・黒魔術などの神秘性が、Pythonの蛇よりも、欧米人の興味をそそるんだろな

0233デフォルトの名無しさん

2016/06/19(日) 13:26:41.51ID:8VsXi83t

>>232
＞日本・黒魔術などの神秘性が、Pythonの蛇よりも、欧米人の興味をそそるんだろな

欧米じゃpythonに完敗してんじゃん
現実見れてなさすぎ

0234デフォルトの名無しさん

2016/06/19(日) 13:29:57.26ID:ovkKK8Lj

>>233
別に完敗でもいいんじゃね？
一定のシェアがあればライブラリなどはとりあえず揃うし、そもそもなんで勝つとか負けるとかに
こだわるのかが分からん

バトロワスレだからとしても、シェアだけで決まるならJavaScriptかPHPで決まりなんだし

0235デフォルトの名無しさん

2016/06/19(日) 21:24:01.78ID:+fTU57fA

>>229
>結局日本のRubyコミュニティって何一つRubyの普及に貢献できてないじゃん

えーと、Ruby処理系の開発そのものに日本のRubyコミュニティが
大きく貢献していることも知らないの？大笑いだな

逆にRuby以外、たとえばPythonでアプリでもフレームワークでも何でもいい、
日本発で世界的に有名なプロダクトって一つでもあるの？ないだろ

少なくとも日本のPyhtonコミュニティはPython処理系の開発に何一つ貢献していない
結局、ジャグゥアーとかメルツェデスとかを礼拝する団塊世代の舶来主義者の集まりが
Pythonコミュニティの実態なんだよ

0236デフォルトの名無しさん

2016/06/19(日) 21:27:11.98ID:bmdpRLuq

つまり日本人が関わりすぎてrubyが廃れてしまったわけですね分かります

0237デフォルトの名無しさん

2016/06/19(日) 21:30:07.55ID:+fTU57fA

>>231
>LispとRubyの目的はメタプログラミングだぜ

いや、LispとRubyのどちらにおいてもメタプログラミングやリフレクションといった
黒魔術的な技法は、言語の一側面にしかすぎないよ
そういった他人が知らないテクニックを使いこなせる俺様に陶酔したい
中二病のプログラマは「メタプログラミングに興味がなければ明確な目的もなくなる」
んだろうね

少なくともLISPプログラミング技法の正統派な教科書であるSICP本では、
メタプログラミングはおろかLISPの代名詞でもあるマクロも使われていない

0238デフォルトの名無しさん

2016/06/19(日) 22:07:50.03ID:QHhML3+q

このように、気持ち悪い信者のせいで衰退しました

0239デフォルトの名無しさん

2016/06/19(日) 23:23:37.14ID:umry5YEW

黒魔術とかいうレッテルを貼ったり貼られたりする駆け引き自体が、一種の魔術だよね

0240デフォルトの名無しさん

2016/06/19(日) 23:36:43.98ID:bljjS0X+

Rubyはまだ1.8の頃に処理系開発を日本主導じゃなく
Rails陣営に丸ごと譲渡してたら
まだワンチャンあった

なんか「RubyはRailsの為の物じゃない」とか日本の処理系開発者たちが
勘違いしてるうちに旬を逃したね

0241デフォルトの名無しさん

2016/06/20(月) 00:00:30.72ID:OWUJ8xtd

よしPythonに乗り換えるわ

0242デフォルトの名無しさん

2016/06/20(月) 06:37:29.11ID:jwXOgnGt

Rubyの互換処理系って海外製のがいくつもあるし、
本家より高性能で何より開発期間が圧倒的に短いよね

0243デフォルトの名無しさん

2016/06/20(月) 08:49:57.65ID:rCm70/fO

つまりこれからは日本もPythonってことか

0244デフォルトの名無しさん

2016/06/20(月) 22:18:53.61ID:D+30QEOy

>>243
つまりこれからは日本もZopeってことですね
たいへんわかりやすいです

--
48 ：デフォルトの名無しさん：2011/11/13(日) 08:30:25.68
>>44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
さかんに宣伝され、雑誌でもZope特集が組まれていた
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい

djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）

だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている

0245デフォルトの名無しさん

2016/06/21(火) 00:11:15.23ID:76ag0eiY

そのコピペ、コミュニティの活動なんてゼロ同然のSmalltalkの信者が書いてるっぽいのが面白い（唐突なSeasideアゲ）

0246デフォルトの名無しさん

2016/06/21(火) 10:57:08.66ID:5xLWxkdZ

>>245
Smalltalkの信者から言わせてもらうと（たとえそいつがコミュニティ活動ゼロのワナビーだとしても）
Seaside を SeaSide とか書くレベルのやつを同じ信者呼ばわりされるのははた迷惑なんだが。

0247デフォルトの名無しさん

2016/06/21(火) 16:03:24.72ID:6+qIiSaV

クリエイティブコーディング面白いな

0248デフォルトの名無しさん

2016/06/21(火) 21:01:29.23ID:SsdweHgv

Smalltalkってゴミなんでしょ？

0249デフォルトの名無しさん

2016/06/21(火) 23:49:58.16ID:0Gy1My9X

かなりの歴史のある言語なのに、全然使われていないわけだから、もうダメだよ
これが去年や一昨年に出た言語ってんなら、未知数な部分もあるけど
Smalltalkがいつできたかは面倒だから調べないけど、結論を出すのに十分な時間は経っている
いまさら一発逆転とか有りえない

0250デフォルトの名無しさん

2016/06/21(火) 23:55:55.05ID:0Gy1My9X

あぁ、シェアが低い(というか無い)ことそのものを論じているわけじゃなくて
全然使われていない、ということは、どういうことか、という論点
特に、元祖オブジェクト指向言語のような存在で、名前はちらほら上がるのに全く使われていないというね

0251デフォルトの名無しさん

2016/06/22(水) 07:09:19.69ID:AVzTjw3o

クラスベースOOの話をしてるとSmalltalkerが「本来のOOは～」と偉そうに説教してくる現象に名前を付けよう

0252デフォルトの名無しさん

2016/06/22(水) 07:20:09.21ID:Nlt5xIVl

Smalltalkには年代ごとに仕様が異なっていて、メッセージングという
コンセプトを共有することを除いてほぼ別言語なので歴史をひもとく際は要注意。
Smalltalk-71は仕様のみで実装のなかった言語で、PLANNERなどの影響を受けている。
Smalltalk-72はトークンのストリームをメッセージに見立てた言語でクラスは関数、メソッドはマクロ風に記述した。
Smalltalk-76はクラス・メソッドが今風に。ifやwhileはマクロで実現。Rubyに似た部分も多かった。
Smalltalk-80からメタクラス、無名関数（後にクロージャー）が追加され、ifやwhileもメッセージで表現されるように。
これの直系がCincom社のVisualWorks。商品化されたv2の前のv1から派生したのがSqueak、さらにそのフォークがPharo。
他にも、企業製の独自処理系（旧VisualAge、Dolphin他）、ファンお手製の変わり種（GNU、Amber、Little等）がある。

0253デフォルトの名無しさん

2016/06/22(水) 07:20:29.59ID:cIEa5wGZ

それは誤解だと思う。本当にクラスベースの話しかしてない時は説教はしない。

0254デフォルトの名無しさん

2016/06/22(水) 07:49:15.13ID:gWGdK3G+

言ってないのに言ったことになってる現象は伝言ゲーム
Smalltalkerではない人までSmalltalkerということになってる現象は主語が大きい

0255デフォルトの名無しさん

2016/06/22(水) 07:53:00.90ID:Nlt5xIVl

自分もそうしているつもりだけれど、どうしてもSmalltalkをかじりたてだったり、
ケイの主張すらあまり理解せずにメッセージングのOOPを盲信する人はやはり居て、
そういう人たちが話の流れをぶったぎるのはよく見かけるから、Smalltalkが反感を買うのはしょうがないね。

0256デフォルトの名無しさん

2016/06/22(水) 08:08:31.13ID:6WbnOXGX

アランケイですらSmalltalkよりRubyの方が好きだって言ってるんだから、
本当に今のSmalltalkには何の存在意義も無いんだよなぁ

0257デフォルトの名無しさん

2016/06/22(水) 08:36:19.81ID:RAGA0TKw

そんで結局は今も昔もJAVAが覇権なんだよなw

0258デフォルトの名無しさん

2016/06/22(水) 09:05:59.89ID:TUFzUUYS

Smalltalkに反発する人は自分の分類だと三種類いる。
- アラン・ケイみたいに価値を認めつつもさらなる高みを望む叱咤激励系
- 昔勉強をしてみたものの落ちこぼれたとか、若い頃Smalltalkerにプライドを傷つけられたとかの逆恨み系
- 自分が知らずに済ませてこれたコトは価値無しと考えているわりに、ちょこちょこ登場するSmalltalkが目障りで排除したがる怠惰系

0259デフォルトの名無しさん

2016/06/22(水) 09:14:35.81ID:vJ6x61Bg

Smalltalkは特に好きも嫌いもない。嫌いなのは空気を読まないSmalltalkerだよ

0260デフォルトの名無しさん

2016/06/22(水) 09:18:46.46ID:TUFzUUYS

>>256
> アランケイですらSmalltalkよりRubyの方が好きだって言ってる

それは Matz が無理矢理言わせたってやつだよね？
「Alan Kayに「Rubyは好きだ」と言わせた。それなんて罰ゲーム？」
http://www.rubyist.net/~matz/20060608.html

個人的にはメタクラスがない、if/whileなどをメッセージ式に統一していないことなど一部を除けば、
ケイの普段言っていることに照らして、RubyがSmalltalkより優れた点は見当たらないなぁ…。

そもそもアラン・ケイは開発当時からすでにSmalltalkには批判的だったことは知っていれば何をいまさらって感じだし
「The idealist in me gritted my teeth, but the practical results were good.」
https://news.ycombinator.com/item?id=11808551

0261デフォルトの名無しさん

2016/06/22(水) 09:22:23.72ID:TUFzUUYS

Smalltalkアンチも空気読まないところあるよね
まあ、お互い様だけど　^^;

0262デフォルトの名無しさん

2016/06/22(水) 09:28:38.36ID:VqkkoD+F

Smalltalkerって、意識高い系なんだけどメジャーな言語で頭角を表す実力が無いから
どマイナーな言語に逃げ込んで「アラン・ケイが～」とかブツブツ呟いてるんだよね？

0263デフォルトの名無しさん

2016/06/22(水) 09:36:53.63ID:XjFtMFIf

> RubyがSmalltalkより優れた点は見当たらないなぁ…。

言語だけの小さい観点から見ればそうなるかもね。
でも現実にはライブラリとフレームワーク込で考えなきゃいけないから。

Railsに変わるフレームワークがSmalltalkにあればねぇｗ

0264デフォルトの名無しさん

2016/06/22(水) 09:36:55.77ID:vJ6x61Bg

>>261
そうだね

0265デフォルトの名無しさん

2016/06/22(水) 09:41:25.15ID:VqkkoD+F

>>260
＞それは Matz が無理矢理言わせたってやつだよね？
＞「Alan Kayに「Rubyは好きだ」と言わせた。それなんて罰ゲーム？」
＞http://www.rubyist.net/~matz/20060608.html

無理矢理って、それあなたの主観ですよね？
それともmatzに弱みでも握られてんの？

0266デフォルトの名無しさん

2016/06/22(水) 09:47:01.33ID:TUFzUUYS

>>262
いわゆる「意識高い系」だと、今は下火だけど以前のRubyistとか、近頃はJSerの方が多いような気がするけど？
Smalltalkerは世をはかなんでいる世捨て人っぽいのが多い印象　ｗ

ああでも若いとPharo関連プロジェクトやったり、スタートアップ作ってばりばり活用しようって人も多いか
https://www.sorabito.com/news/20160509.html

あとSmalltalkなんか使っているとメジャーな言語で頭角をあらわす実力がなくなるってことだとすると、
ケント・ベックとかマーチン・ファウラーとかランダル・シュワルツとかはSmalltalkerとしては例外的だったのか
ああ、いまだにアラン・ケイがーとか言ったり、Smalltalkなんか使っている奴はダメダメだってことか

0267デフォルトの名無しさん

2016/06/22(水) 09:49:21.77ID:TUFzUUYS

>>265
> 無理矢理って、それあなたの主観ですよね？

本人が「罰ゲーム」って書いているからそうなのかと思ったのだけれども、主観と言われればそうかもね。
気に障ったのならスマン

0268デフォルトの名無しさん

2016/06/22(水) 09:59:02.44ID:TUFzUUYS

>>263
> 言語だけの小さい観点から見ればそうなるかも

いやそういうことではなくて「アラン・ケイが好き」って文脈だったので
彼が好きだと思うような、たとえば言語の枠組みすら変えられる動的結合性とかのアドバンテージはなさそうだなって話。
彼好みというくくりを外して、一般人好みってことなら優れている点は多いと思うよ。だから人気が出たのだろうし。
自分としてはSmalltalkで書けるコードなら、よほどのことがない限りRubyで書こうとは思わないけれど。

0269デフォルトの名無しさん

2016/06/22(水) 11:26:27.92ID:gWGdK3G+

もしかしてファイルシステムとRDBが使えるSmalltalkに需要があるのかな
ただ、いつでも梯子を外せるやつじゃなくて一蓮托生な感じにしないと信用できないけど

0270デフォルトの名無しさん

2016/06/22(水) 12:02:59.99ID:TUFzUUYS

> ファイルシステムとRDBが使えるSmalltalk

RDBはさておき、独自GUIや仮想イメージにさほど依存しないGNU Smalltalkという変わり種がすでにあるわけだけど、
だったらRubyのほうがずっといいんじゃないかと思う。そういうことじゃなく？

梯子がどうこうとかいうのは FileTree で Git に対応するとか姑息な手を使わずにってことだよね？
http://qiita.com/tomooda/items/8685782c42f674307dfe

自分としては、梯子を外されるってことではむしろ、外されるのはSmalltalkの方じゃないかと危惧していて
たとえば今流行りのVCSとか自動ビルド系に合わせてSmalltalkを作りかえてしまうと
そういうツールが廃れた後にひどいことになりそうで怖い
Monticello（は便利だし、感謝しているけど）がプロトコルをパッケージ名に流用してぐじゃぐちゃにしちゃったり
PharoがSmalltalkの伝統的なプロジェクト機構を削っちゃっていろいろ使いづらくなった苦い経験からも

0271デフォルトの名無しさん

2016/06/22(水) 13:09:06.95ID:1owlsp3d

Smalltalkが梯子を外されると危惧する、の意味が分からない
何故上から目線なのか
常に超低空飛行をしているのだから、はしごを外されて落ちても痛くないでしょ
今の状態で、誰も使ってない無価値な存在なのに、何か価値を持っていると思い込むのはやめたまえ
C言語はコンパイラごとの独自機能や処理系依存だらけでズブズブではあるが
少なくともSmalltalkよりは価値のある言語
皆が使うとはそういう事
Smalltalkは誰も使ってないから、統一的な価値観が守られているというだけであって
そんな糞みたいなものを、大切に思う発想が分からない

0272デフォルトの名無しさん

2016/06/22(水) 13:37:39.81ID:TUFzUUYS

>>265
> それともmatzに弱みでも握られてんの？

それについてはリンク先にもあるように、
> 彼の考えている「子供たちのためのプログラミング環境」のために
> RubyなどSqueak以外の言語コミュニティからアイディアを借りたい、
> ということで今回のセッティングであった。

とのことなので、協力をあおぐケイ側からすればMatzの機嫌を損ねる発言は控えただろうね
だからこの場に限っては「弱みを握られていた」と言えるかも　^^;

そんな配慮に気付いてか気付かずか、Matzがケイとの対面やその中での発言を切り取って
自分やRubyの宣伝に活用しようと画策しているのが透けて見えるようで、当時ずいぶんとゲンナリさせられたのを今思い出した
とか書くと ID:VqkkoD+F はまた気分を害するかな…スマンね

0273デフォルトの名無しさん

2016/06/22(水) 13:39:41.66ID:TUFzUUYS

>>271
そんな誰にも使われていないはずの糞みたいなものに目くじらをたてるキミの思考アルゴリズムの方が私にはわからんよ　^^;

0274デフォルトの名無しさん

2016/06/22(水) 13:59:44.94ID:wBQFgwBY

Rubyは流行らないだろうな～

0275デフォルトの名無しさん

2016/06/22(水) 14:06:47.60ID:1owlsp3d

君の物の考え方に意見しただけで、Smalltalkについて意見したわけではない
誰も使っていないから統一感がある状態を保てているだけであり
そんな統一感を素晴らしいことのように思っていることを、糞だと言っている
誰も使わない無価値な工具がいつまでも新品なのは当たり前であり
そこに価値を見出すのは糞の発想
道具は使われてこそ価値があるとは考えないのか？

エスペラント語とか、誰も使っていないから、きっと方言も無いのだろう
君からすればこれは素晴らしいことに見えるのかもしれないが
世間的には無価値
利用価値があって使われるから方言は生まれるわけで
誰も使わなきゃそりゃ方言も生まれないわな
これが素晴らしいか？

僕の考えた最強の～の類

0276デフォルトの名無しさん

2016/06/22(水) 14:39:06.39ID:TUFzUUYS

個人的に、Smalltalkが面白いと思うところは、
ID:1owlsp3d の固執する統一感というよりは>>252からも分かるように、むしろ変化しまくっているところで
ほんの申し訳程度のオブジェクトストアとシンプルなバイトコードインタープリタ
それとプリミティブな画面描画関数をセットにして、そこにメッセージングというお題目だけ与えておいて、
あとはユーザーに自由にさせるってなんともいいかげんなシステムにもかかわらず、思ったよりちゃんと動いて、
少なからず技術や文化を創出しながら、想像以上に長生きしているってところなんだけどな…

文法とかIDEツール群とかライブラリとかは（まあ、使うときにはすごく便利だし愛着もあるけど）けっこうどーでもいい

0277デフォルトの名無しさん

2016/06/22(水) 16:20:27.71ID:mFneZ1Wa

>>275
＞誰も使わなきゃそりゃ方言も生まれないわな

SmalltalkってLispかそれ以上に方言が多い言語じゃなかったっけ？
Lispもそんな使われてないけど方言の種類も価値ももちろんあるし
利用者が少ない＝無価値　という持論も含めいろいろ破綻している

0278デフォルトの名無しさん

2016/06/22(水) 19:15:46.33ID:aRlphdXp

何処もかしこもパイパイぱいぱいオッパイソン(*^◯^*)
"ソフトウェアエンジニアは一般的な人々と比べてどのくらい稼ぐのか : Pythonでのデータ収集・処理・可視化"
http://postd.cc/what-software-engineers-earn-compared-to-the-general-population/

0279デフォルトの名無しさん

2016/06/22(水) 19:23:54.67ID:0j+OfU6X

>>272
そんな打算で心にもないこと言うなんて
アランケイってセコくて下らない人なんだね
幻滅したわ

0280デフォルトの名無しさん

2016/06/22(水) 19:32:54.82ID:0j+OfU6X

>>276
＞文法とかIDEツール群とかライブラリとかは（まあ、使うときにはすごく便利だし愛着もあるけど）けっこうどーでもいい

それって全部Smalltalkがショボイところだよね？

0281デフォルトの名無しさん

2016/06/22(水) 20:32:08.39ID:TUFzUUYS

>>279
打算というか、何か人にものを頼むときは、その人の不愉快になることは言わないって当然の配慮でしょう　^^;

Ruby が好きっていうのは、ケイが Smalltalk 歴代実装のなかで一番気に入っている Smalltalk-76 と
Ruby が似たところがあるからで単なるおべっかというわけではないと思いますよ。
ただ Matz は「好き」って部分だけを作為的に切り取って Ruby の宣伝に使ったんだろうってだけの話かと

0282デフォルトの名無しさん

2016/06/22(水) 20:48:02.08ID:Uiz2+MrP

MatzがRubyという言語を使ってどんな素晴らしいソフトウエアを作ったか。

Pythonを作った人はDropboxで働いたりGoogleで働いたりしているね。

これが天と地の差だよ。

0283デフォルトの名無しさん

2016/06/22(水) 21:36:39.46ID:V3koZGgU

最も厳格であり美しさを追求する言語、それはPython

0284デフォルトの名無しさん

2016/06/22(水) 22:01:12.60ID:1DvIaRNW

>>256
>アランケイですらSmalltalkよりRubyの方が好きだって言ってるんだから、
>本当に今のSmalltalkには何の存在意義も無いんだよなぁ

えーと、「アランケイはSmalltalkが好き」なのは作者本人であれば当たり前で、
同時に「アランケイはRubyが好き」というのも自然な話だろ
好きなプログラミング言語が複数あるのは誰にでも共通するものだ

それが、いったいどこから「アランケイはRubyよりもSmalltalkが好き」になったの？
いくら Ruby や Smalltak が嫌いだからといって、嘘やデマを垂れ流すべきじゃないよ
まあ、>>256が日本語の文章に不慣れな出自だったり、嘘でも何でも議論に勝てばいいという
社会の中で育ったのなら、しかたないのかもしれないけどね

0285デフォルトの名無しさん

2016/06/22(水) 22:10:02.26ID:K9FJhQUK

>>284
＞えーと、「アランケイはSmalltalkが好き」なのは作者本人であれば当たり前で、

「Smalltalkのことをもう愛していない」と言ってたらしいよ？w

0286デフォルトの名無しさん

2016/06/22(水) 22:11:15.59ID:1DvIaRNW

>>263
あるよ、Rails に代わるフレームワークは
それは Zopeさ！！w
これからは Python の時代だよね！！！www

おもしろいなあ、結局、>>244に対して反論できたのは、
最後のしかもカッコ内で書かれた Smalltalk に関連した箇所だけだとは...
これだけに着目しても、スクリプト言語の未来はPythonが支配するに
決定したようなもんだね！！！>>241,243

0287デフォルトの名無しさん

2016/06/22(水) 22:29:59.37ID:1DvIaRNW

>>285
アランケイが「もう愛していない」のは Smalltalk-80 のことだよ
ケイがSmalltalkの言語設計に直接関わったのは Smalltalk-72まで、
Smalltalk-76 ではアドバイザという形で開発へ間接的に関わった

そして今日、素人がSmalltalkと言えばSmalltalk-80を指すんだろうけど、
Smalltalk-80はケイがSmalltalkプロジェクトを去った後、
ソフトウェア工学の成果をフィードバックして洗練させる目的で開発された
だから子供向けの楽しい教育用言語としてSmalltalkを誕生させたケイからすれば、
今のSmalltalk-80はあまりに大人向けの言語に見えるから好きになれないんだろう

ということで、素人さんがSmalltalk-72から-80の違いを知らずに無知を晒した、
ってことね

0288デフォルトの名無しさん

2016/06/22(水) 22:35:25.20ID:AVzTjw3o

SmalltalkerのせいでSmalltalkの人気が落ちる不思議な現象に名前を付けよう

0289デフォルトの名無しさん

2016/06/22(水) 22:38:54.81ID:WXglfH4p

もう10年も前に終わったプロダクトに今更粘着してる>>286キモいわ

https://www.google.co.jp/trends/explore#q=Zope%2C%20Django%2C%20Rails%2C%20Flask&;cmpt=q&tz=Etc%2FGMT-9

とはいえ、Smalltalkは30年も前に終わってるのに引きずってるんだから、さもありなん

0290デフォルトの名無しさん

2016/06/22(水) 23:06:39.59ID:K9FJhQUK

>>287
アランケイがまだ愛してるかもしれない（愛してるとは言ってない）Smalltalk-76の実用レベルの処理系ってまだ生き残ってるの？
もうWindows1.0（10じゃないよ）と同レベルで死んでんじゃないの？

0291デフォルトの名無しさん

2016/06/22(水) 23:21:25.99ID:1DvIaRNW

>>290
たしかに生き残ってはいないだろね
何しろSmalltalk-80は複数のプラットフォーム(Unix や Mac)へ移植されたけど、
それ以前の(-76を含む)Smalltalkは Alto(とその後継機?)でしか動いていないから

で、処理系が死んでるからって、何をいいたいのかね？

たとえ処理系が生き残ってなくても、その概念や思想は今でも引き継がれているよ
たとえばイテレータという概念はCLUという言語で生まれたけど、
イテレータの概念はPythonやRubyのコレクション処理に引き継がれている
同様にリスト内包表記はKRCという関数型言語で生まれたけど、
リスト内包表記はHaskellやPythonに引き継がれている

もちろんCLUもKRCも実用的な処理系は生き残っていない訳だが

0292デフォルトの名無しさん

2016/06/22(水) 23:42:55.37ID:K9FJhQUK

>>291
じゃあアランケイは信者がウッキウキで使ってるSmalltalkは好きじゃないけどRubyは好きってことじゃん
お前ら誰もSmalltalk-76なんて使ってないんだろ？

0293デフォルトの名無しさん

2016/06/23(木) 00:10:39.89ID:AN7rYHRc

どうでもいいからredhatはpythonを早く3系に移行してくれよ

0294デフォルトの名無しさん

2016/06/23(木) 00:14:49.75ID:l5Yxsat6

>>292
なぜそんな発想になるの？面白い人だね

自身が情熱を賭けて設計したプロダクトであるSmalltalk-72と-76、
たとえその実用的な処理系が今生き残っていないとしても、
そのプロダクトに対する愛情は死ぬまで消えるはずがないでしょ

それとも言語と言語処理系との区別ができないのかなあ…

ちなみにアランケイはXEROXオリジナル版Smalltalk-80仕様をベースした
Squeakの開発において、主導的な役目を担っているよ(今でもね)
もしケイがSmalltalk(-80)が好きじゃないなら、Squeakのプロジェクトで
わざわざリーダーの責任を負ったのはナゼなんだろね？

なんだかなあ、ヒトの形はしているけどヒトの心を持たない
ヒトモドキと会話してるみたいだ

0295デフォルトの名無しさん

2016/06/23(木) 00:55:36.71ID:W4u3AiNW

> もしケイがSmalltalk(-80)が好きじゃないなら、Squeakのプロジェクトで
> わざわざリーダーの責任を負ったのはナゼなんだろね？

給料が良いから

0296デフォルトの名無しさん

2016/06/23(木) 01:06:49.10ID:cCLDY84q

>>294
＞もしケイがSmalltalk(-80)が好きじゃないなら、

んん？

>>287
＞アランケイが「もう愛していない」のは Smalltalk-80 のことだよ

こう書いたのオマエ自身だろ？

0297デフォルトの名無しさん

2016/06/23(木) 01:11:47.81ID:W4u3AiNW

アキバ系 VS アラン系

0298デフォルトの名無しさん

2016/06/23(木) 05:36:05.13ID:7CKET8cw

>>290
> Smalltalk-76の実用レベルの処理系ってまだ生き残ってるの？
> もうWindows1.0（10じゃないよ）と同レベルで死んでんじゃないの？

参考まで、Alto やその高速版である Dorado 向けの処理系そのものは失われてしまったけれど
8086 で動くポータブルPC試作機の NoteTaker 向けにシュリンクされたバージョンの
Smalltalk-78 なら生き残って（というか蘇生させられて、かｗ）いるよ。
http://www.freudenbergs.de/bert/publications/Ingalls-2014-Smalltalk78.pdf

これにプレゼン機能を追加してアラン・ケイがそれでプレゼンをしたことがある
https://www.youtube.com/watch?v=AnrlSqtpOkw&;t=3m52s

から、Windows 1.0 よりはずっと実用レベルで使われているとも言える。ｗ

あと、そのものではないけれど、Smalltalk-76 も Java で再実装されたものなら動かせる
http://web.archive.org/web/20110918104701/http://home.netsurf.de/helge.horch/esug/index.html

0299デフォルトの名無しさん

2016/06/23(木) 09:14:58.58ID:cCLDY84q

>>298
Smalltalkerの考える実用ってレベル低いんだね

そんなので良かったら、Windows 1.0をインストールして遊んでるやつ何人もいるから（youtubeに沢山動画上がってる）
ユーザベースならWindows 1.0の方が多いと思う

うん。やっぱりSmalltalk-76のライバルはWindows 1.0で十分だと思うぞw

0300デフォルトの名無しさん

2016/06/23(木) 09:28:58.38ID:W4u3AiNW

Smalltalkは理論上動くという検証とデモまでで
それより上の使いやすさといった実用レベルにまでは
到達してないからな。

0301デフォルトの名無しさん

2016/06/23(木) 09:31:06.46ID:53SjK6zR

でも使い物になるように改造しようとしたら、彼みたいな人が梯子を外されると危惧するらしいから
どうしようもないよ

0302デフォルトの名無しさん

2016/06/23(木) 11:17:12.63ID:BiGB2wU7

Smalltalkファンとしては、
Smalltalk-76/78 が否定的とはいえこんなに語られているのを見られるとは感慨無量だ
Matz には感謝しないといけないな
ちなみに自称言語オタクの Matz をもってしても Smalltalk-76 のことは１ミリも知らないらしいw
（Smalltalk-72 は月刊ASCIIでコードを見たことがある程度は知っているらしいけど）
せっかく褒めてもらったのに、アラン・ケイもがっかりのへっぽこ言語オタクっぷりだな＞Matz

0303デフォルトの名無しさん

2016/06/23(木) 16:52:34.41ID:5IpeQnCv

いつまでスレチ続けるんだこの糞は

0304デフォルトの名無しさん

2016/06/23(木) 19:27:22.94ID:NmuAlDwp

>>301
Linuxもカーネルだけ作って残りは後で改造しようとしたら、色々と大変らしいから

0305デフォルトの名無しさん

2016/06/24(金) 11:13:12.41ID:eaUqouTj

JS、PHP、Pythonは各々の得意分野で盤石の態勢を築いてるけど
Rubyは中途半端でヤバそう

0306デフォルトの名無しさん

2016/06/24(金) 12:44:17.87ID:xEd+6tYG

Groovyには、ビルドシステムのGradle。
Rubyには、Compass

Compassとは、Sass(Syntactically Awesome Stylesheets)を元に開発したフレームワーク。
Sassで記述されたファイルをコンパイルして、CSSファイルを生成出来る

0307デフォルトの名無しさん

2016/06/24(金) 15:59:18.27ID:Ah+FOV/X

>>257
みたいね

リクルートの「2016年おすすめプログラミング言語」、1位はJava
http://developers.srad.jp/story/16/06/23/1931246/

0308デフォルトの名無しさん

2016/06/24(金) 16:27:17.64ID:EevunhA0

結論に異論は無いが、テクノロジーズになんかおすすめされたく無いわ

0309デフォルトの名無しさん

2016/06/24(金) 17:39:47.05ID:hSLmnyaY

このスレ民にオススメされるよりはマシ

0310デフォルトの名無しさん

2016/06/24(金) 17:49:21.28ID:EevunhA0

>「仮に、ご自身をプログラミング言語に例えるとしたら、どの言語が最も近いと思いますか？」という質問項目もある。リクルートテクノロジーズでは「それぞれの「プログラミング言語の性質に対するイメージ」がを知ることができる」と述べている。

wwww

0311デフォルトの名無しさん

2016/06/24(金) 21:23:23.06ID:hSLmnyaY

「２年後コンピューターが人類を超える。まだ社長やめられない」　孫社長が独演会
http://www.sankei.com/economy/news/160622/ecn1606220024-n1.html

２年後にシンギュラリティが起きるらしい

0312デフォルトの名無しさん

2016/06/24(金) 22:19:15.17ID:hDq/MQ4q

大企業が金をつぎ込めば限定的に10年は技術を先行させられることが実証されてるから、
限定的なシンギュラリティが2020年とすると、誰しも認めるようになるのはやはり2030年頃だろう。

0313デフォルトの名無しさん

2016/06/24(金) 22:25:04.18ID:SwddNomm

問題は10年が長いか短いかだな。
10年前って言ったら2006年だしな。

0314デフォルトの名無しさん

2016/06/24(金) 23:07:09.17ID:oHe0MFCJ

人間を超えるってことは人間が嘘をつくとすぐバレるんだよな

0315デフォルトの名無しさん

2016/06/25(土) 08:19:51.16ID:qwSrCJ6q

人間を超えるプログラムが出来たとしたら
それはPythonで書かれてるだろうね

0316デフォルトの名無しさん

2016/06/25(土) 10:35:43.85ID:0GlvEeuA

>>307
派遣で人送り込むには必須だからな。

0317デフォルトの名無しさん

2016/06/25(土) 10:47:35.82ID:3+HB44WN

Winで開発してUNIXサーバーにそのまま持っていけるのって事実上Javaしかないからなあ
Pythonがデータ分析とかで流行ったのも、そういう分野はビジネスな人が多いから
Winと比較的相性の良いものが選ばれただけという面がある

0318デフォルトの名無しさん

2016/06/25(土) 19:13:23.29ID:qwSrCJ6q

ビジネスな人達が分析用途でPython使うようになったのって
ここ数年前の話だろう
その頃にはnumpy、scipy、pandasは十分育ってたから
ビジネス云々は関係無いと思う

0319デフォルトの名無しさん

2016/06/25(土) 23:20:26.29ID:LWoDO68j

> RubyはSmalltalk-80よりAlanのOOを体現してる

https://mobile.twitter.com/yukihiro_matz/status/746706348520312833

0320デフォルトの名無しさん

2016/06/26(日) 01:01:32.65ID:vF2rjjdx

キモ

0321デフォルトの名無しさん

2016/06/26(日) 13:43:40.91ID:kOUAeqMS

けっきょくBoolClassを入れなかったRubyの設計は間違っているという指摘だし
ましてそんなRubyがアラン・ケイのOOを体現できているわけもないのだが
MatzってRubyとか自分の宣伝しか考えてないただのバカなの？

0322デフォルトの名無しさん

2016/06/26(日) 13:50:59.45ID:mUNVGGWd

でもアランケイはRubyが好きだしSmalltalk-80は好きじゃないよ

0323デフォルトの名無しさん

2016/06/26(日) 17:29:14.69ID:2AHwRte/

アランのOOを忖度するのは自由だ
忖度する事がITの仕事なんだという意見があってもいい
でもそれはアランの意見じゃないな

0324デフォルトの名無しさん

2016/06/26(日) 17:53:32.44ID:fCYkvTCl

そしてここはSmalltalkスレじゃない

0325デフォルトの名無しさん

2016/06/26(日) 18:07:31.08ID:yNhVlefq

テッド・ネルソンとかアラン・ケイは言うことばかりデカくて大したことは成し遂げていない山師

0326デフォルトの名無しさん

2016/06/26(日) 18:40:02.55ID:2HVJZ7e6

偉そうな口を叩く資格があるのはゴスリンとヘルスバーグだけ

0327デフォルトの名無しさん

2016/06/26(日) 19:00:14.12ID:2AHwRte/

そういうこと言うから、自分には資格がないと思って他人の気持ちを忖度するんだよね

0328デフォルトの名無しさん

2016/06/26(日) 19:01:11.82ID:MOs+lhSh

アランケイが言ってるのだから正しい

0329デフォルトの名無しさん

2016/06/26(日) 20:46:18.75ID:tFXL6zPh

Smalltalkなんか真似してっから
RubyはPythonに勝てないんだよ

0330uy ◆e6.oHu1j.o

2016/06/27(月) 12:31:44.43ID:fzKuFJZp

http://i.imgur.com/4gxFT71.png
ゴミ

0331uy ◆e6.oHu1j.o

2016/06/30(木) 13:13:17.30ID:U+B64GZ8

一応rubyでも実装されているものの
rubyで書く人が少なく使用頻度が低いんだろなーっていうライブラリ
そこはバグばっかり

普通なら変数を閉じ込めて
loop do
　var = クラス.new
　＜処理＞
end
こうしたいところを
loopの外でクラス.newをしないと、長時間動かすと以下のような症状出る事が多い
主にネットワーク関係のコードは昔から悲惨

１どう見てもメモリリーク
２ nilになっちゃいけない変数が突然nilになる
３ SEGV
４ http://i.imgur.com/4gxFT71.png

そろそろnodejsへの鞍替えも考えてる

0332デフォルトの名無しさん

2016/06/30(木) 23:58:07.02ID:iTuzTFvO

> そろそろnodejsへの鞍替えも考えてる
こんな未練がましいこと書かずに勝手に鞍替えすればいいのに
かまってちゃん？

0333デフォルトの名無しさん

2016/07/01(金) 00:51:45.89ID:82BHCo7S

>>331
ruby嫌いな要因の1つだ

0334デフォルトの名無しさん

2016/07/01(金) 01:11:26.28ID:3rPGiaEJ

まあJSだってアマがネイティブ部分を実装することがないブラウザ環境ではありえないが、
Nodeだったら似たようなことはあり得る話だ。
しいて言えばNodeや準標準ライブラリがしっかり安全な低レベルAPIを公開してくれてて、
ネイティブ部分を自分で弄らず公開されているAPIの上で頑張るJSの文化的特長なのかな。

0335デフォルトの名無しさん

2016/07/01(金) 01:41:28.32ID:rLMTR09R

>>331
そのライブラリだってオープンソースなんだろうから、issue 登録するなり pull request 投げるなりすりゃいいのに

お客さん気分で使いたいなら金払って MS 製品でも使っとけ

0336デフォルトの名無しさん

2016/07/01(金) 02:52:28.12ID:eT6J2Ld/

そのお客さん気分を推進するのがオブジェクト指向だから
オープンソースでは使いずらい

0337uy ◆e6.oHu1j.o

2016/07/01(金) 15:54:43.51ID:S/5FGxnJ

>>335
労力を考えた事ありますか？
数百行のレベルじゃなくて、数千行の規模で書いてる時にバグ起きてんですけど
そこから削って最小の再現コードを見つけ出すか、
あるいは今書いてるソースコードそのままアップロード

つうかプロジェクト丸ごとアップとかありえないならバグ回避の手段を探して
２ｃｈスレに少しだけ愚痴を書いて泣き寝入り
バージョンアップでバグが修復されてる事を祈ることしか僕たちには出来ない

0338デフォルトの名無しさん

2016/07/01(金) 16:56:04.59ID:8Nl+zymn

>>337
> 泣き寝入り

おかしいね。
「プログラマーが泣き寝入りするしかないからマイクロソフトは悪の独裁者で、オープンソースは正義だ」とか主張してなかったっけ？

【ActiveScript】RubyをWindowsで使うスレ【GUI】
http://echo.2ch.net/test/read.cgi/tech/1155031689/
> 916 名前：デフォルトの名無しさん[sage] 投稿日：2016/06/26(日) 09:55:40.86 ID:eOF1WWDb
> 　「マイクロソフトを嫌っていたのではない、われわれが嫌われていたのだ」――Rubyまつもとゆきひろ氏が語る、MSの壁
> 　 http://www.itmedia.co.jp/news/articles/1606/08/news138.html

> 「こういう場合、対策は2つしかない。1つはWindowsを無視する。
> 「許しはするが、過去を忘れるわけではない」。

> 921 名前：デフォルトの名無しさん[] 投稿日：2016/06/30(木) 09:19:58.93 ID:U+B64GZ8
> 　上流は一般市民を飼いならそうとする
> 　rubyは一般国民に武器を持たせる類の言語

> 924 名前：uy ◆e6.oHu1j.o [] 投稿日：2016/06/30(木) 10:33:47.63 ID:U+B64GZ8
> 　植民地時代にインドネシアでは
　　（以下略

0339デフォルトの名無しさん

2016/07/01(金) 16:58:04.28ID:8Nl+zymn

> 「『ライセンス感染』といった言葉を使っている人が何を考えているかというと、
> 『お前の開発したソフトウェアはフリーソフトウェアだから俺が使う。
> けど、俺が作っているソフトウェアは商用ソフトウェアだから』ということ。
> これはすごいジャイアニズム。
> 今でも感染性などの言葉を使う人もいるが、これにはカチンときた」（まつもと氏）

> いつの日か「マイクロソフト嫌いってわけじゃないけど、
> すっごく困ってて、やっぱり嫌い」と
> 言うようになっている自分がいたという。

> 移植性がほしいのでLINUXでもWindowsでも動くツールを提供したい。
> マイクロソフトはそのために必要なAPIやシステムコールを提供してくれなかった。

> 実際問題として、マイクロソフトの方がわれわれを嫌っていたのだ」（まつもと氏）

> しかし「せめて自動車みたいな環境がほしい」とまつもと氏は言う。
> 丸いハンドルがあって、アクセル、ブレーキがあって……と、
> 基本的なユーザーインタフェースはどのクルマも変わらない。
> だからクルマを買い替えても運転できるし、国が違っても一応運転はできる。
> ソフトウェアも、せめてそのくらいの環境に持っていきたいとまつもと氏は話す。

> 「こういう場合、対策は2つしかない。1つはWindowsを無視する。
> もう1つは、ものすごく苦労して対応する」

> 「許しはするが、過去を忘れるわけではない」。

> 「こういう言い方をすると偉そうだけど、
> 私たちはオープンソースソフトウェア界の一員としてマイクロソフトが入ってくることを、
> 企業としても、個人としても、開発者としても歓迎する」（まつもと氏）。

0340デフォルトの名無しさん

2016/07/01(金) 17:16:43.56ID:rLMTR09R

>>337
労力なんてオープンソース使い始める時点から完全に分かってる部分だろうに
分かってて今更愚痴ってんならただのクレーマーだし、それすら分かってないなら
ただの情弱だし、どちらにせよ「僕は無能なプログラマです」と公言してるだけだという
ことに早く気付こうね

0341デフォルトの名無しさん

2016/07/01(金) 19:10:41.81ID:SAYknsg4

グラフライブラリを検索するとJavascriptのグラフ（描画）ライブラリで埋め尽くされるという。

0342uy ◆e6.oHu1j.o

2016/07/01(金) 20:56:33.12ID:VXADmiWq

>>340
たびたび勘違いされるけどプログラマとかいう下等生物になったつもりないし。

何故世界中で使われてるはずの言語のバグを
趣味でコード書いてるだけの奴が先に見つけるんだよ
この辺の頼りなさを憂慮してる

0343デフォルトの名無しさん

2016/07/01(金) 21:00:42.02ID:8Nl+zymn

先に見つけているけど、下等生物には教えない

下等生物（オープンソース）は永遠に下等生物でいろって事ね。

なんだ、お前、マイクロソフト帝国の回し者だったのか。

0344uy ◆e6.oHu1j.o

2016/07/01(金) 21:20:20.01ID:VXADmiWq

>>343
最初にもいったように、再現コードを取り出す労力がかかりすぎるんだよ
提出して良いコードと、提出しちゃいけないコードに分離する作業から始まる
いま温存してるバグなら時間見積もりをいうと48時間くらいほしい

自分は社畜ではないけど、社畜だったらこれ土日が休みでも（12時間＋12時間）＊２
7月の休日を半分をバグ報告の為に消費することになるよ
そこまで無償労働やる奴がいるのだろうか
大変な作業なんです

0345デフォルトの名無しさん

2016/07/01(金) 21:44:04.51ID:rLMTR09R

>>344
無償労働が嫌ならオープンソースなんて使うな
助け合いの精神のない奴に文句をやいやい言われてモチベーションが折れた人間が何人いたことか

0346デフォルトの名無しさん

2016/07/01(金) 22:02:20.96ID:rLMTR09R

そもそもオープンソースの大半はボランティアであり、趣味でやってるものだ
お前が趣味でコード書いてるように、オープンソースの開発者も趣味でコードを書いてるんだ
その開発者に対して何ら敬意も払ってるように見えないお前がいっちょまえに文句だけ垂らしてる
行為を日本ではクレーマーって言うんだよ

0347uy ◆e6.oHu1j.o

2016/07/01(金) 22:02:32.67ID:VXADmiWq

>>345
プログラマって献身的な奴多いけど異常だと思う
それも本人に余裕があって献身してるわけじゃなくて精神削った上で献身してるからな
一度ITの外に出てみろ「何こいつら？」と思うはず

ちなみに民主主義においてボランティア活動みたいな
利益を生まない行為は良くないとされてる
各々が自分の利益を好き勝手に求めた先にあるのが民主主義としての秩序であり向上だからな
叩かれてイヤになったというより民主主義に駆逐されたんだよ

＞無償労働が嫌ならオープンソースなんて使うな
これって、見つけたんだから何とかしろってのは
もうバグなんて見つけないほうが良かったって話になるよね？
助け合いが必要だというなら、自分は「この辺にバグがあったけど詳細わからん」と2chに愚痴った時点で
他の誰かが検証作業をしてみる流れになるのが普通だと思う

けど2chでは、それを周りがやった事は一度もない
結局は他人に働かせることしか考えてないだろ
そうこう2chに書いてる間にひとつはIssueしてきた
もうひとつのほうはやる気ないけど

で、君は何をしたの？

0348デフォルトの名無しさん

2016/07/01(金) 22:09:37.06ID:rLMTR09R

>>347
> 助け合いが必要だというなら、自分は「この辺にバグがあったけど詳細わからん」と2chに愚痴った時点で
> 他の誰かが検証作業をしてみる流れになるのが普通だと思う
意味分からん
お前がそのバグを踏んで苦しんでて助けて欲しいならお前が報告すりゃいい話じゃん

> で、君は何をしたの？
Pull Request は色んなプロジェクトに数十は出したし、Issue ならもっと多い
全部俺が困ったことだし、Pull Request はその困ってた部分を解決できたんでそれを
フィードバックしただけの話

0349デフォルトの名無しさんぱよぱよちーん©2ch.net

2016/07/01(金) 22:15:48.05ID:8Nl+zymn

> 叩かれてイヤになったというより民主主義に駆逐されたんだよ

民主主義に駆逐された東京都知事

> 2chに愚痴った時点で
> 他の誰かが検証作業をしてみる流れになるのが普通だと思う

２ちゃんねらーはそんな連中じゃないはずだが・・・
民主主義だの奴隷制だの政治的な話を持ち出してくる割にはぱよぱよちーんとかの存在を無視してるなあ・・・
agetepayopayo って知ってる？

>>347
「そうこう」ってどういう意味？辞書引いても分からない。

> そうこう
> 【倉皇・蒼惶】
> あわてふためくこと。にわかで、どうしたらよいかわからなくなること。

> そうこう
> 【草稿】
> 下書き。草案。原稿。

0350デフォルトの名無しさん

2016/07/01(金) 22:17:34.54ID:rLMTR09R

>>347
> 一度ITの外に出てみろ「何こいつら？」と思うはず
日本人はえらいね。こういうときにピッタリの言葉があるよ

郷に入っては郷に従え

0351uy ◆e6.oHu1j.o

2016/07/01(金) 22:17:58.95ID:VXADmiWq

>>348
俺が望んでるのはIT全体の効率向上
全体を考えた上で、自分以外も困るだろうからバグ情報を半端な状態でも一応見つけ次第書いてるんだよ
ソフトウェアだってβリリースしたりするだろ
それと同じように見つけたバグ情報をβリリースしてるようなもん
あと別に困ってなどいない、メンドクサイと思う程度の事で
他の正常に動くライブラリを使えば良いだけ

＞Pull Request は色んなプロジェクトに数十は出したし、Issue ならもっと多い
俺には出来ないね

0352uy ◆e6.oHu1j.o

2016/07/01(金) 22:19:09.55ID:VXADmiWq

>>349
方言かもしれない
そんな事やこんな事をしているうちに　という意味

0353デフォルトの名無しさん

2016/07/01(金) 22:19:28.42ID:rLMTR09R

>>351
> 俺には出来ないね
できないならこんなとこで管巻いてないで、金払ってプロプラのライブラリを使うんだね
MS 周りならそんなのがいっぱいいるからさ

0354uy ◆e6.oHu1j.o

2016/07/01(金) 22:28:14.05ID:VXADmiWq

>>350
やだ従わない

>>349
あと、政治っていうか
人が集まった時に形成されていく構造の話かな
自分勝手に最も効率良いと思う事を
各自がやってることが一番良いと思うよ
今ここで語られてるOOPは、
自分は苦労してるんだから周りも苦労しろっていう、足の引っ張り合いでしかない

0355デフォルトの名無しさん

2016/07/01(金) 22:31:47.20ID:SAYknsg4

ダンゴちゃんが一言↓

0356デフォルトの名無しさん

2016/07/01(金) 22:43:04.30ID:ZNe1vyZ3

三兄弟♪

0357デフォルトの名無しさん

2016/07/01(金) 23:57:18.23ID:/oDxerZf

ソースコードを読める人が多数派になれば、読めない人が喧嘩や裁判で勝つのは難いから
読める人の利益になる
だから無料でいいから読んでほしいんだと思う

0358デフォルトの名無しさん

2016/07/02(土) 00:38:11.27ID:xFxO48gn

>>354
従わないならそれでいいんじゃね？
そのかわりフルボッコは覚悟した上でね

0359uy ◆e6.oHu1j.o

2016/07/02(土) 02:04:59.07ID:iqIMwrQM

>>358
つまり、
2chから一方的に煽られ叩かれ
フルボッコにされてる事が気にくわないんだよね？

実名を出して活動している人たちは
まるでしゃがみ小パンチで少しずつHPを減らされるが如く名誉棄損されているような気分で、
気づけば頑張ってきたはずの自分たちの地位が落とされているという

気持ちは察するけど、現実とはそんなもの
厳しい現実を知っているからこそ自分は表へ出ない
自分はITの世界で名を上げたいなんて気持ちは全く無いし
永久に匿名の中から突っつき続けるから
「uy」とは、人ではなく自然災害のようなものとして扱うのがベストだと思う

0360デフォルトの名無しさん

2016/07/02(土) 09:14:41.68ID:WnybQ8jc

俺何度か実名で投稿したけど削除されたよ

0361デフォルトの名無しさん

2016/07/02(土) 10:05:39.87ID:9rtmvwfu

本人証明ないから　なりすまし・荒らしと同等
本名を出したいならトリップ必須

まあ人気化しても嫌われてもどっちにしろ邪魔だからやめれ

0362デフォルトの名無しさん

2016/07/02(土) 10:09:20.90ID:Xa7r0vLw

ゴーストライターみたいに名前を偽装するよりは単に名前を隠すだけの方が良心的だな

0363デフォルトの名無しさん

2016/07/02(土) 10:15:11.30ID:xFxO48gn

>>359
> 自然災害のようなものとして扱うのがベストだと思う
自分で自分のことを迷惑だと認識してるなら来るな

0364uy ◆e6.oHu1j.o

2016/07/02(土) 12:57:48.14ID:iqIMwrQM

>>363
http://pic.i-imgs.com/wp-content/uploads/1992/03/19e31c86a073a747e1da447d9a686879.jpg

0365デフォルトの名無しさん

2016/07/02(土) 13:03:54.36ID:/wal4gbU

>>364
それなんの写真？リンクをクリックするのがめんどくさいから
言葉で説明してよｗ

0366デフォルトの名無しさん

2016/07/02(土) 14:12:07.26ID:60oUOAbz

>>364
黙ってPythone使え

0367デフォルトの名無しさん

2016/07/02(土) 14:12:23.40ID:60oUOAbz

Pythonなw

0368デフォルトの名無しさん

2016/07/02(土) 23:34:15.70ID:u5yD0E4E

そう、パイソーンならね。

0369uy ◆e6.oHu1j.o

2016/07/05(火) 22:07:51.09ID:1uRQlpDk

ファイルポインタをGCで回収してる言語の、とんでもない欠点に気づいてしまったんだけど

0370uy ◆e6.oHu1j.o

2016/07/05(火) 22:26:25.40ID:1uRQlpDk

あーはいはいごめんね
黙ってruby issue行けばいいんだよね
uyは嫌われ者ですよ

0371デフォルトの名無しさん

2016/07/06(水) 01:07:36.48ID:OJW6Sf+f

オブジェクトをGC管理下に置いたり、そこからリリース・自前管理って任意に切り替えられないもんかね？

0372デフォルトの名無しさん

2016/07/06(水) 01:15:59.94ID:mxUXCuWS

>>371
静的フィールドから辿れるところで参照掴んどけばGC対象にはならない

0373デフォルトの名無しさん

2016/07/06(水) 01:45:34.38ID:DQh08+gO

リリースを自分でしたいということでしょう

0374デフォルトの名無しさん

2016/07/06(水) 07:17:22.80ID:sTXK0Kzp

ArrayBufferで一定のメモリを取っておいて
そこでやりくりするくらいが精々

0375デフォルトの名無しさん

2016/07/06(水) 08:35:20.03ID:XoIPMfxx

まだ開いているファイルと閉じたファイルの型を区別しない理由はなんだろう
閉じたら違う型になる言語はないのかな

0376デフォルトの名無しさん

2016/07/06(水) 18:23:44.85ID:sTXK0Kzp

つまりそれって、１つのオブジェクトの__proto__が状況に応じて動的に変化するってことでしょ？
確かに粒度の大きい、メイン的なオブジェクトに関して、そうするのはありかもしれない。
自分もゲームエンジンを作った時、描画モードを切り替えると__proto__が変わるようにしたこともある。
それはOSや補助システムととユーザーランドで同じキャンバスオブジェクトを持っていて、
並列して色んな描画モードを使用するので参照は１つのままでモードが変えられる方が、
整合性やらエラー処理やらなんやらで横着ができたから。
でもかなり例外的だし、そんなに状態の数も状態間の差もなく、
操作も少ないファイルでそうする理由もないと思う。

0377デフォルトの名無しさん

2016/07/06(水) 21:13:03.26ID:73ByLRkJ

>>375
意味ないからだろ。内部状態によって動作を変えるだけならたいていの言語でできる。

0378デフォルトの名無しさん

2016/07/06(水) 21:21:45.95ID:DQh08+gO

いやたぶん、型安全性的な何かだろう
静的型の型チェック機能を使ってコンパイル時にチェックしよう、的な
動的型脳には理解できない概念のようだが・・・
長文お疲れ、といった感じ

0379uy ◆e6.oHu1j.o

2016/07/06(水) 23:41:59.72ID:4XXkMTdx

ファイルの話題になってるから昨日書こうとしたもの投下しよう

func str
　open("file.txt" , "w").print str
end

loop {
　...
　func str
}

このfunc呼び出しが、12時間毎に1回呼び出しとかならバグる確率は極めて低い
funcを呼び出す間隔が狭くなるほど書き込み失敗する確率が高くなる

ようは開いたファイルポインタを、GCでcloseするタイミングが不定だから
再現率の低いバグを潜ませるコード

けど、実際ふつうに全速力で廻しても書き込みは全然失敗しない
色んな条件を重ねていくと、GCのcloseタイミングによる書き込み失敗が、現れるようだった
rubyはこうなってるらしいけど、こんな初歩的なところにトラップあったなんて知らなかったんだが
多分GCでファイルポインタ回収してる言語は、多くがこのトラップを潜ませてると思う

0380デフォルトの名無しさん

2016/07/07(木) 00:48:52.73ID:XB960VIm

> C# の各種トピック > GC のタイミングでファイルを閉じるのではダメ、ということを目で見て理解する
http://csharp.keicode.com/topics/file-handle.php
要はマネージドのオブジェクトと、アンマネージドのリソース管理は
別々に考えなければならないということです。

アンマネージドのリソース（この場合ファイルハンドル）を、
スコープが抜けたタイミングでしっかりクリーンアップするということをしたい場合は、
IDisposable インターフェイスを実装します。
そして、その変数を using ステートメントと共に使います。

前述の例を書き直すと次のようになります。

　　...
　　using( var fs = File.Open( path, FileMode.Create ) ) {
　　　　// FileStream を使う...
　　}
これによって、using で定義されたスコープを抜けたときに
IDisposable インターフェイスの Dispose メソッドが呼ばれ、
そこでハンドルを閉じるように実装しておけばハンドルリークを避けることができます。

0381デフォルトの名無しさん

2016/07/07(木) 00:53:52.08ID:ZEMHX3he

そういうMicrosoftローカルだけに必要な知識っていくら詰め込んでも意味ねえよなあ

0382デフォルトの名無しさん

2016/07/07(木) 00:58:05.63ID:ZZ+/7KR2

いやJavaとかPythonとかも同じ仕組みはあるから

0383デフォルトの名無しさん

2016/07/07(木) 03:52:45.03ID:dDDKCxpD

>>379
まずはRubyにissue登録はしたの？

0384デフォルトの名無しさん

2016/07/07(木) 06:47:54.00ID:Ry0ooGfS

usingは、try-catch-finallyを使って、finallyで、リソースを閉じているだけ

Pythonのwith。コンテキスト・マネージャー

0385デフォルトの名無しさん

2016/07/07(木) 07:32:23.87ID:9nALhBhc

RubyならFile.openにブロックを渡せばusing相当

0386デフォルトの名無しさん

2016/07/07(木) 08:00:31.70ID:j5TOflcB

>>378
そういうのは型チェック機能の能力を超えてると思う。
ファイルの概念がビルトインでそれだけ限定的に適応することはできるかもしれないけどさ。
それが汎用的一般的に可能なら全てのランタイムアサーションが不要になる。

0387デフォルトの名無しさん

2016/07/07(木) 08:35:36.58ID:ZXhLupqO

>>375
ファイルを指し示す型と開かれたファイル(のように振舞う何か)の型を区別する言語/ライブラリは
普通に存在するが。
前者を開かれているかいないかで別の型にする意味はないだろう。

0388uy ◆e6.oHu1j.o

2016/07/08(金) 15:32:41.85ID:ReeCCMlZ

>>383
西行寺うゆとして活動中

0389デフォルトの名無しさん

2016/07/09(土) 10:43:12.51ID:70tfGxUK

ファイルのような外部リソースのCloseをGCにまかせたらアカンってのはどの言語でも
常識なんだけどね
C#のusingってのはまさにそのためにあるわけだし

0390デフォルトの名無しさん

2016/07/09(土) 11:11:27.57ID:3DBY5ZwO

>>389
何言ってるんですかｗ
GCっていうのはメモリ専用ですよｗｗｗ
ファイルをGCが管理する言語なんて存在しません。

0391デフォルトの名無しさん

2016/07/09(土) 12:50:56.98ID:nw/Tgfsc

外部リソースのClose（されるタイミング）をGCにまかせたらアカン

0392デフォルトの名無しさん

2016/07/09(土) 12:54:55.79ID:FZzh0UKS

vbaで片っ端からnothing入れていった若き日を思い出すわ

0393デフォルトの名無しさん

2016/07/09(土) 12:59:58.35ID:1nvCXdBR

>>392
nothing代入がclose操作だと勘違いしていたやつ多かったなｗ
ローカル変数なのに関数の最後でnothing代入とか意味なしｗｗｗ

0394デフォルトの名無しさん

2016/07/09(土) 14:18:27.68ID:Mn3UGZ+O

問題は2点あるだろ
・バグらせる書き方が残されてる
・警告が出ない

0395デフォルトの名無しさん

2016/07/10(日) 01:11:36.49ID:E6q7e73V

GCありだけど任意にデストラクタよべる言語ってある？

0396デフォルトの名無しさん

2016/07/10(日) 01:22:48.49ID:D0PozWsA

スクリプト言語ではないがC++/CLI

0397名無しさん＠そうだ選挙に行こう！ Go to vote!

2016/07/10(日) 09:09:53.48ID:QwOzaSp+

C++/CLIのマネージクラス(GCあり)のデストラクタは
C#のDisposeパターンのシンタックスシュガーだぞ

0398名無しさん＠そうだ選挙に行こう！ Go to vote!

2016/07/10(日) 09:33:18.60ID:D0PozWsA

？
シンタックスシュガーのデストラクタとそうでないデストラクタの違いがあると？

0399名無しさん＠そうだ選挙に行こう！ Go to vote!

2016/07/10(日) 09:55:47.57ID:7UmbBN03

>>398
メモリの開放は結局GC任せ
まあdeleteしたタイミングでメモリの開放までやるかどうかはプログラマの知るところではないから
実質的に重要な違いがあるとは俺は思わないけど、
今の文脈だとDisposeパターンはデストラクタではないというのが前提だったんじゃないの?

0400名無しさん＠そうだ選挙に行こう！ Go to vote!

2016/07/10(日) 10:10:25.22ID:D0PozWsA

そりゃ、前提がGCありって話なんだから。
普通のC++だってdelete時にデストラクタが呼ばれるってだけで、デストラクタがメモリを解放するわけじゃない。
要は、デストラクタの有無とメモリをどのタイミングで解放するかに直接の関係はないってこと。

0401デフォルトの名無しさん

2016/07/19(火) 19:43:20.98ID:y3yY1Ovu

473 名前:名無しさん＠１周年 :2016/07/19(火) 08:40:16.41 ID:iHE/uEU80
ARMを押さえるだけでツールチェインも周辺IPもデバガもOSもミドルウェアにも影響力を持てるってことだもんな

組み込みでARMの覇権が進んで20年以上経つがその知的財産の膨大さはすぐには置き換え不可能だわ

>>457
jazzelってどこまで真面目にやるんだろな

>>460
Intelはatomで戦おうとしたが惨敗したよ
いまは戦略の練り直し中ですぐには代わりのものない

>>462
それも一つの事業としてあるだろけど、プレゼンを見るといまの製品やサービスにこだわる気はまったくないみたい
身の回りの情報機器がすべて通信と演算能力をもって連携したとき、いよんな新しい価値がでてくるだろな

ちっこい知能たちに囲まれそれが世界と繋がる生活とかどんなんだろ？

618 名前:名無しさん＠１周年 :2016/07/19(火) 10:13:51.00 ID:nLLrJ97b0
組み込み技術をやってるものとしてはこれはソフトバンクの勝ちだわ
ARMの覇権が決まってからよく買えたな

619 名前:名無しさん＠１周年 [sage] :2016/07/19(火) 10:13:54.76 ID:NR4RVxD+0
まさか日本がモバイルCPUのトップに君臨できる日が来るとは夢にも思わなんだ(´・ω・｀)

0402uy ◆e6.oHu1j.o

2016/07/24(日) 18:09:50.86ID:OTYg2OHa

これからもRubyの一強時代は続いてゆく

2016年プログラミング言語トップ21が発表、1位は昨年と同様 | マイナビニュース
http://news.mynavi.jp/news/2016/07/24/080/

1 Ruby
2 JavaScript
3 Java
4 PHP
5 Python
5 C#
5 C++
8 CSS
9 C
10 Objective-C
11 Shell
12 R
13 Perl
14 Scala
15 Go
16 Haskell
17 Swift
18 Matlab
19 Visual Basic
20 Clojure
20 Groovy

0403デフォルトの名無しさん

2016/07/24(日) 18:30:25.88ID:p8SJSbCV

>>402
嘘書くな

1 JavaScript
2 Java
3 PHP
4 Python
5 C#
5 C++
5 Ruby
8 CSS
9 C
10 Objective-C
11 Shell
12 R
13 Perl
14 Scala
15 Go
16 Haskell
17 Swift
18 Matlab
19 Visual Basic
20 Clojure
20 Groovy

0404デフォルトの名無しさん

2016/07/24(日) 21:14:32.41ID:5J1ShuAC

やっぱこれからは、そしてこれからもJAVAとPythonだな
特にここ最近のPythonの強さは異常、機械学習/AIがこれから未来をイノベーティブしていく以上、Pythonが最強になる

そして、日本で急に人気出た理由はただ一つ
日本人は世界的にオッパイ星人でありオッパイソンという響きに靡いてしまったのだ

0405デフォルトの名無しさん

2016/07/25(月) 01:52:10.11ID:qDvRhoUY

>>404
python嫌いなんだけど、ライブラリやツールなど周辺そろってるが強いね。
正の循環にはいってる？
redhatやdebian linuxが完全にpython3に移行してくれればなぁ

0406デフォルトの名無しさん

2016/07/25(月) 20:49:08.38ID:oORbOkwx

あくまで使われているランキングだからね
Javaのように使わさせられているものもあるし、
Pythonのように知らずと使っているものもある
Goは自らすすんで使っているものだろう
JavaScriptは３つとも当てはまる

0407デフォルトの名無しさん

2016/07/25(月) 21:27:00.32ID:QsUdyR6M

>>406
> Webで最も議論の対象となり活用されているプログラミング言語トップ21

Python なのかどうかわからない人間が議論に参加できるんだ？すげーな。

あんな特徴的な言語を区別できないなんて、ぼけ老人クラスだと思うけど
ぼけ老人にも使える Python ってすげくね？

0408デフォルトの名無しさん

2016/07/25(月) 21:27:24.61ID:umEBYYKN

>>406
それはお前の想像であって
事実ではない。

0409デフォルトの名無しさん

2016/07/25(月) 21:31:24.41ID:umEBYYKN

>>407
> ぼけ老人にも使える Python ってすげくね？

ぼけ老人が使っているって情報は
どこにあるんですか？
老人ホームで使われてるとかですかね？

0410デフォルトの名無しさん

2016/07/25(月) 21:39:59.85ID:QsUdyR6M

>>409
「ぼけ老人」に速攻で反論してくる奴はだいたいぼけ老人の法則

0411デフォルトの名無しさん

2016/07/25(月) 21:40:51.60ID:umEBYYKN

>>410
その法則は証明されたものですか？

0412デフォルトの名無しさん

2016/07/25(月) 21:54:06.99ID:QsUdyR6M

>>411
広く認知された事実ではあります。

http://i.imgur.com/5tS6mm4.jpg

0413デフォルトの名無しさん

2016/07/25(月) 21:55:34.22ID:umEBYYKN

>>412
どこで認知されているのか教えてくれませんか？

なぜこうしつこく聞いているかというと、
なんの根拠もないのに「そういうことにしたがってるだけ」
じゃないかって疑っているのです。

0414デフォルトの名無しさん

2016/07/25(月) 22:21:57.41ID:QsUdyR6M

>>413
僕は自分の名前を思い出せないほどの記憶喪失を何度も経験しました。
そのたびに半年くらいかけて回復してましたが
最近は物の名前がどうしても出てこない事が多く、
関連する話題をググってその言葉を探し当ててます。
僕はまだ40代ですが、実は、二十歳以下の時点で「お前は若年性痴ほう症だ」と何度も言われていて
周囲の人間はそういう認識です。
その僕が、JavaScript でコードを書いてます。
Python も数行程度なら書いた経験があります。
易しさでは Ruby が一番と言う事らしいですが、
Ruby、Python、JavaScript はそれほど変わらないと思います。
認知症と呼ばれ続けて20年以上経っている僕が JavaScript でコーディングできるんだから
同じ程度の易しさである Python だって使えるでしょう。

僕は Ruby と HSP が嫌いですが、基本的には各言語に公平だと思っています。
だから下記のように公平に比較しています。
http://echo.2ch.net/test/read.cgi/tech/1378978504/53+328+358

ところであんたは真面目に書いてるように見えるけど、国語能力は中学の内容で75点レベルかな？

「バカと言った人がバカ」と言うのは子供でも知ってるし、僕もまさにその通りだと実感しているところです。

都知事選に関しては毎日全国放送されているので
視聴率10％なら視聴者の10％が知っているわけで、
これは広く知られていると言って過言ではないと思いますよ。

0415デフォルトの名無しさん

2016/07/25(月) 23:14:59.55ID:oORbOkwx

>>407言い方が悪かったな。
>>406は>>405を受けて書いたものだ。
後は分かるだろう？

0416デフォルトの名無しさん

2016/07/26(火) 01:18:08.28ID:qQPpojae

>>414
一行にまとめて

0417デフォルトの名無しさん

2016/07/27(水) 23:05:35.94ID:tfAZ9CiD

結局スクリプトはPythonさんの覇権かよ

0418uy ◆e6.oHu1j.o

2016/08/07(日) 09:12:20.37ID:PWyfS198

本物のプログラマーがrubyを好み、Pythonを使わない４１８の理由　　著:uy

0419デフォルトの名無しさん

2016/08/07(日) 16:18:53.22ID:SkXCww44

Ruby/RailsってWEBでしか使われないじゃんw
Pythonは様々な分野に拡がってるというのに、特に科学技術に強いのは凄いね

0420デフォルトの名無しさん

2016/08/07(日) 17:18:44.81ID:OaRABY3s

本物のプログラマはガタガタ抜かす前にモノを作るんだぜ
uyがPythonのライブラリをそのままRubyで使えるような仕組みを作りさえすれば、
サイエンス分野におけるPythonの素晴らしいリソースを丸ごとぶん取ることができる
自己顕示欲の塊であるuyが世間に名を轟かせるチャンスだぞ

0421デフォルトの名無しさん

2016/08/07(日) 18:51:58.78ID:SkXCww44

オッパイソンのライブラリ全部自力でRuby用に書き直せばいい

0422デフォルトの名無しさん

2016/08/07(日) 21:51:00.48ID:65wMyQQ/

>>420
>本物のプログラマはガタガタ抜かす前にモノを作るんだぜ

つまり、このスレにいる本物のPythonプログラマが Ruby on Rails を置き換える
WEBフレームワーク作りさえすれば、WEB分野におけるRubyのリソースを
丸ごとぶんどることができる、ってことですね
今のところ海外のZopeは沈没してDjangoは鳴かず飛ばずですけど、
日本在住のPythonプログラマが世間に名を轟かすチャンスですね！！

ぜひ頑張ってきださい、期待してます

0423デフォルトの名無しさん

2016/08/07(日) 22:53:59.00ID:kDOIwKrR

潰し合え

0424デフォルトの名無しさん

2016/08/07(日) 23:59:43.11ID:L3ZVTZUX

pyramidはどうよ

0425デフォルトの名無しさん

2016/08/08(月) 11:28:21.28ID:15uVV3zK

>>422
大差無いじゃん>>289

0426デフォルトの名無しさん

2016/08/08(月) 22:19:47.20ID:m7ddtlnV

>>425
そうですか、大差ないんですね

でしたら、Zopeの経験者を優遇してくれるWEBの求人案件を教えて下さいませ
PHPやRailsなら条件を絞れば求人は見つけられるのですけど、
ことZopeにいたっては皆無なんですよ

大差ないんだったら、天下のPythonフレームワークであるZope案件なんて
いくらでも見つかりますよね？

0427デフォルトの名無しさん

2016/08/08(月) 22:55:48.58ID:4wAqez6C

Python Serverless Microframework for AWS みたいなのの方が将来性がある
Railsみたいに小手先でコードをこねくり回すんじゃなくて
基盤でしっかり支えてやってPythonはクリーンに保つのがPython的なやり方

0428デフォルトの名無しさん

2016/08/08(月) 23:12:05.06ID:5TolF2I8

phpからbottleに移行しようと暇を見つけてはpython3を勉強していたのですが、php7が出たので移行を中止しました。

0429デフォルトの名無しさん

2016/08/09(火) 00:18:44.21ID:cIxIQRDv

>>427
>Python Serverless Microframework for AWS みたいなのの方が将来性がある

理由も無しに願望で将来性を語るなら、幼稚園児にもできますね
GoogleやAmazonでPythonサポートが始まったのは今日や昨日の話じゃないですし

>基盤でしっかり支えてやってPythonはクリーンに保つのがPython的なやり方

その「基盤でしっかり支えてやってPythonはクリーンに保つのがPython的なやり方」は、
まざにZopeの思想だったわけですけど、沈没しちゃいました
やっぱり "Python Serverless Microframework for AWS" も沈没しちゃうんですか？

0430デフォルトの名無しさん

2016/08/09(火) 01:13:04.25ID:GFJow9Sf

そうだね
いくら2chで理屈を述べても、現実のほうが重要だよね
現にRubyは沈没しかかっているからね

0431デフォルトの名無しさん

2016/08/09(火) 15:02:49.12ID:+ZfnWw/i

君たちをRubyに導いたnaoyaはc# asp.netの会社に転職した

0432デフォルトの名無しさん

2016/08/09(火) 21:08:28.01ID:R+CmsfqF

騙される奴は何度でも騙される

0433uy ◆e6.oHu1j.o

2016/08/10(水) 11:03:43.07ID:Gt6LYR8D

>>431
メイン言語を乗り換えられるのは、せいぜいその言語を2~3年くらいしか使ってない場合なのかもしれない
それ以上の期間「これがメイン言語」って、何でもかんでもその言語でコード書いてると、
細かいオタク知識が身についてきて、せっかくそういうの覚えたのに言語が変わる事で意味を成さなくなる事がイヤで乗り換えるの億劫過ぎる
自分がC#とかJAVAへあの時走ってて、
もし今そんな状況になっていたらと思うと恐ろしいね、大正解ではないかもしれないがrubyをメイン言語にしててほんと良かったよ

0434デフォルトの名無しさん

2016/08/10(水) 13:50:31.28ID:4F3fQqN9

ぶっちゃけると昨今各言語が最小公倍数的な進化をしてきてて差がなくなってきてるから、
乗り換えるとは言わずとも、一週間くらいあれば別の言語に慣れることも可能。

0435デフォルトの名無しさん

2016/08/10(水) 13:52:13.57ID:4F3fQqN9

C#とかJAVAだってそう。
Perlなどに比べれば十分親しみやすい。
まあPerlも6で幾分良くなったが。

0436デフォルトの名無しさん

2016/08/10(水) 17:04:09.75ID:KwXQGMzu

>>434
ぶっちゃけそれは
最小公倍数的な進化をして差がなくなってきてる言語群、もしくは
一週間くらいあれば慣れることが可能な言語群しか自分は眼中にない、
同時に、そんな狭い観測範囲で十分食っていける仕事や立ち位置を見つけたよって表明に過ぎなくて
まあ、幸せなことだし水を差すつもりもないけど、
構造的には特定の言語に囲い込まれているのと何ら変わらないし、案外脆いものだよ。

0437デフォルトの名無しさん

2016/08/10(水) 22:16:47.41ID:UWZg55pn

株式会社TOUAが2016年7月に破産
http://www.tdb.co.jp/tosan/syosai/4191.html

0438uy ◆e6.oHu1j.o

2016/08/11(木) 01:04:31.82ID:HURWf3IJ

>>434
かつてはそう思ってたけど本気で乗り換えようとしたときに違う事が分かった
言語仕様覚えた後に
存在するかすらわからないけど、調べないといけないもの　→　（良サイト/ブログ・良ライブラリ・周辺ツール・開発者の重要な過去のコメント・仕様変更の歩み）
何年も継続して使ってる事で、偶然見つけられる類の情報は全てリセットされ
特に細かい仕様や開発者のコメントを知らないと、言語に不釣り合いなコードを書いてたりしてソースコードが冗長してくる
まともなコード書けるのがいつになるかと考えると乗り換えはとても大変な決断

0439デフォルトの名無しさん

2016/08/11(木) 02:20:39.05ID:zwMFKNJ/

文法的なものはすぐ慣れる。
大変なのはライブラリとか開発環境の違い。

0440デフォルトの名無しさん

2016/08/11(木) 06:41:01.72ID:LPAM5Yv4

すぐコピペできるサイトを探すのが大変と言ってるだけだったりして

0441デフォルトの名無しさん

2016/08/11(木) 08:16:32.03ID:Ndtc1zRz

まあPythonをメインにして間違いないだろう

0442デフォルトの名無しさん

2016/08/11(木) 09:33:20.85ID:+5EuhwqI

まあ科学技術計算の分野ならば、
豊富なライブラリがあるPythonで間違いないね
手続き型プログラミング界の王者だ
21世紀のFORTRANとして地位は確立された

0443デフォルトの名無しさん

2016/08/12(金) 08:48:52.55ID:rlhGSfSo

>>436
俺はあくまでこのスレで、今までの話の流れを踏んで答えてるんだけど。

具体的にもう俺のスクリプト言語オワコンだ、別のが良いなってなった時
選択肢として重要な最小公倍数的な進化をしてない言語って何よ？

0444デフォルトの名無しさん

2016/08/12(金) 09:24:01.76ID:ZeYxvI9R

>>443
UWSC

0445デフォルトの名無しさん

2016/08/12(金) 11:57:41.82ID:mm4X6Gd9

HPUX

0446デフォルトの名無しさん

2016/08/13(土) 07:18:43.22ID:+WqHxJju

APL, Prolog, LISP, Scheme, Smalltalk, Haskell とか
スタイルの結晶化を果たした言語はただ古いというだけでオワコン扱いはできないし
機能を寄せ集めただけの普通の言語を知っていれば１週間で何かが得られるほどチョロくもない

0447デフォルトの名無しさん

2016/08/13(土) 13:47:42.33ID:O8savYa/

いやsmalltalkはオワコンだから

0448デフォルトの名無しさん

2016/08/13(土) 15:00:16.22ID:t1NGVfTn

>>446
確かに。でもオワコン＝０とは言わないがせいぜい重要度一割二割くらいでしょ。
それ全部集めてもSwiftに負けると思うし。
まあどれも実際のところ汎用的に使いにくい言語だから比較しにくいけど。

0449デフォルトの名無しさん

2016/08/13(土) 16:00:41.63ID:8cs2uvvR

結局のところ使われる言語っていうのな
色んな人がどれだけ人的リソースを投入しているかなんだわ。
その点でJavaScriptは最大級のリソースが投入されている。

使われる言語っていうのはこのように人的リソースが投入されている言語で
そうでない言語は、特徴的な機能のプレビュー版みたいな扱いだよ。
その機能を他の言語は取り入れる。

0450デフォルトの名無しさん

2016/08/13(土) 17:44:09.25ID:P6oYVlvt

>>449
＞その点でJavaScriptは最大級のリソースが投入されている。

え？例えば？

0451デフォルトの名無しさん

2016/08/13(土) 18:33:46.06ID:pifrZ9b5

>>450
大企業が数社それぞれで独自のコンパイラを作っていて
それらオープンソースで、ライブラリのコミュニティも活発で
標準化もされている言語ってJavaScript以外にありますか？

0452デフォルトの名無しさん

2016/08/13(土) 18:46:38.83ID:P6oYVlvt

つまりバラバラってことか

0453デフォルトの名無しさん

2016/08/13(土) 18:59:21.65ID:pifrZ9b5

>>452
そりゃそうだよｗ
競争じゃなきゃ意味がない。

IEだけの時代は進歩が遅れたじゃないか。
それと同じでどこかの一つの会社や団体が作ってるだけのものは
進歩しないんだよ。

でもう一度聞く。これだけ多くの人的リソースが
投入されている言語は他にあるか？

0454デフォルトの名無しさん

2016/08/13(土) 19:25:24.68ID:YstAWmCx

バラバラだけど合計したら大きいし合計しなければ小さい
合計する方が正しいという根拠は特にない
CとC++も合計すればJavaより大きいんじゃないか

0455デフォルトの名無しさん

2016/08/13(土) 19:51:38.37ID:P6oYVlvt

だから仕方なく使われる糞みたいな言語になって下火になってるのか
そらPythonさんが覇権とるわけだ

0456デフォルトの名無しさん

2016/08/13(土) 20:12:02.11ID:ke3Th6q/

>>455
まあ科学技術計算の分野ならば、
豊富なライブラリがあるPythonで間違いないな
手続き型プログラミング界の王者だ
21世紀のFORTRANとして、Pythonさんが
覇権をとることを否定する人は誰もいないよね

0457デフォルトの名無しさん

2016/08/13(土) 20:59:56.08ID:HQjOY7S4

そしてWEBではRoRだし

0458デフォルトの名無しさん

2016/08/13(土) 21:33:01.74ID:ke3Th6q/

>>457
え？、WEBのサーバサイドではPHPが絶対的王者でしょ
求人数や稼働サイト数では圧倒的だよね

0459デフォルトの名無しさん

2016/08/14(日) 02:03:21.46ID:Ccd3Odrv

>>454
何を言いたいのかわからん。
使っている人が多いのは当然のこと開発している会社や団体も多い。
この人的リソースに勝てる言語は他にないって話なんだが。

もちろん人的リソースが多くても開発が停滞しているような
言語は将来性に不安があるけどJavaScriptの場合はそれがない。
逆にこれだけのスピードで進化してる言語（関連技術含む）ってないよ。

0460デフォルトの名無しさん

2016/08/14(日) 06:28:57.49ID:5Y/KMCKQ

人的人的ってなにかと思ったら人月のことか
人口を倍にすれば進化のスピードも倍になるという都市伝説

0461デフォルトの名無しさん

2016/08/14(日) 06:29:30.47ID:YNmu3wYY

急速に進化してるのはWebであり、Web APIでしょ？
Web APIはJavaやDartやそれこそ他の言語からでも使えるわけでJSに含めるのは違うと思うよ？

そしてJSはむしろかなり進化の遅いほうでしょ。
Class構文入れるのに最初の討論から10年以上かかったくらいだからね。
でも遅いからこそ時代に合わせて進化していける余地があるんでしょ？

他のメジャーバージョンで区切って互換性を捨てる言語でさえ、
互換性壊していくのは言語の寿命を縮めていつか限界が来るって歴史が証明してるからね。
ましてやそれすらも難しいJSは慎重に策定していかないとダメでしょ。

元はと言えばそういうことを危惧して標準化団体に渡したようなものだしね。
今から考えるとJSとしてはそれは大正解だった。

0462デフォルトの名無しさん

2016/08/14(日) 06:58:39.86ID:EcwVprBa

>>460
COBOLだと人数通りにきれいにスケールして面白いよ
SI業界は未だにあの幻想を忘れられないでいる
まあスクリプトなら数十行で書けるような処理に1～2人日くらい費やすような世界なんだが

0463デフォルトの名無しさん

2016/08/14(日) 11:20:11.64ID:3VQYycZi

これだけのリソース割かれてこの程度の進化具合とかjsさんの亀具合にはホンット呆れる
つまりその程度の言語で本当は誰も期待なんかしてないんだよね

0464デフォルトの名無しさん

2016/08/14(日) 11:30:05.90ID:5Y/KMCKQ

一人でなんでもできる人間ばかりだったら人数を増やすだけでいいけど
ジャンルが細分化したら量だけでなく質を考えないと

0465デフォルトの名無しさん

2016/08/14(日) 11:30:57.25ID:2ASH1YAS

分野は違えどPythonとJSが争っている感じだね
そこへApple専用言語のSwiftが入ってきて
Rubyはフェードアウト

0466デフォルトの名無しさん

2016/08/14(日) 11:33:09.55ID:Ccd3Odrv

>>460
> 人口を倍にすれば進化のスピードも倍になるという都市伝説

何が言いたいのさｗ

人口じゃない。進化させようとしている人の数だ。
進化のスピードが倍になるとは限らないが、
進化させようとする人が多ければ、進化のスピードが上がる。

都市伝説にする前に、否定しろよ。
どうこういう理由でそうならない。という感じで
お前は否定も肯定もしとらんｗ

0467デフォルトの名無しさん

2016/08/14(日) 11:44:00.15ID:Ccd3Odrv

>>461
> 急速に進化してるのはWebであり、Web APIでしょ？

Web APIに引っ張られる形で、JavaScript（ECMAScript）も進化している。
ちょっと前までES5だったがES6になりつつある段階で名前が変わった。
ES6ではなくES2015になった

なぜこうなったかというと開発やリリースのスタイルが早くなり
毎年リリースされることになったから。もちろん今はES2016。

もっともこの名前には意味がなくECMAScriptは機能単位で仕様策定が行われている。
完成したらその時のES20XXに組み込まれるだけの話。
機能単位でのリリースだから進化のスピードも速い。

ここら辺見るとよく分かるよ。
https://azu.github.io/slide-what-is-ecmascript/slide/10.html

0468デフォルトの名無しさん

2016/08/14(日) 11:44:00.55ID:2ASH1YAS

船頭多くして船山に登る

0469デフォルトの名無しさん

2016/08/14(日) 11:46:09.27ID:Ccd3Odrv

>>468
船頭じゃなくて船がたくさんある状態だよｗ
なにせ機能ごとに独立して開発が行われてるからね。

他の言語ではほぼ一つの団体が牛耳ってる状態だから
まさに船頭多いしてってやつになってる。

0470デフォルトの名無しさん

2016/08/14(日) 11:49:51.76ID:2ASH1YAS

>他の言語ではほぼ一つの団体が牛耳ってる状態だから
>まさに船頭多いしてってやつになってる。

1行目と2行目のつながりが意味不明

0471デフォルトの名無しさん

2016/08/14(日) 12:01:20.22ID:Ccd3Odrv

>>470
ん？それをいうのなら、船頭多くしてって
言ったやつに、どういう意味か聞くべきでは？ｗ

0472デフォルトの名無しさん

2016/08/14(日) 12:13:22.04ID:2ASH1YAS

意味わからんし
言葉の意味も分からずに使ってたのか

0473デフォルトの名無しさん

2016/08/14(日) 13:03:21.48ID:Ccd3Odrv

>>472
言葉の意味ぐらいググれよｗ

0474デフォルトの名無しさん

2016/08/14(日) 13:11:36.22ID:yKRyt1Tf

>>460
人月w

0475デフォルトの名無しさん

2016/08/14(日) 17:34:00.23ID:d9Nb5GY4

ではどうして、言語を一つの団体が牛耳ったら
船頭多くして～になるんですか？
普通に考えれば逆なんですが

0476デフォルトの名無しさん

2016/08/14(日) 17:39:10.41ID:d9Nb5GY4

あえて反対の意味にとらえる必要性を問うているわけです

あえて逆に表現をする、あえて、あえて

君のプログラムは大変読みにくいだろう、ということです

0477デフォルトの名無しさん

2016/08/14(日) 17:50:49.77ID:Ccd3Odrv

>>475
あー、そうか。
ECMAScript特有の仕様の決め方が分かってないのか。
この特異さが進化ｎスピードにつながってるんだけど。

ここ見ればわかるだろうけどさ、仕様になったものを実装するんじゃないんだよ。
（実験的に）実装してその後に仕様になる。
https://azu.github.io/slide-what-is-ecmascript/slide/14.html
https://azu.github.io/slide-what-is-ecmascript/slide/16.html

じゃあ誰が提案・実装するかというと、それぞれのブラウザメーカー。
ブラウザメーカーは船だよ。船がいくつも有って船ごとに船頭がいる。
船が一つで船頭が多くいれば、あーだこーだ言って進まないが、
ブラウザメーカーはそれぞれ自分の考えで進むことができる。

自分が提案すれば早く実装できるから、他のブラウザメーカーより一歩先を行けるし、
そうでないブラウザメーカーは、それはそれで仕様が固まってから実装するから無駄がない。
そうやってお互いが競争しあうことで短期間でどんどん進化していくことになる。

0478デフォルトの名無しさん

2016/08/14(日) 18:06:05.05ID:d9Nb5GY4

まさに、船頭多くしてって感じだな
船がいっぱいあるとかも、あえて、そんな考え方する必要ないし
言い換えたところで現実は変わらないし、無駄な思考だ

で、↓の説明はまだ？

>他の言語ではほぼ一つの団体が牛耳ってる状態だから
>まさに船頭多いしてってやつになってる。

どうして一つの団体が牛耳ったら船頭多くして～になるの？

0479デフォルトの名無しさん

2016/08/14(日) 18:08:13.81ID:YNmu3wYY

間違ってる。毎年リリースされることと急速な進化は無関係。
もっと言えばオープンガバナンスモデルだからとかリビングスタンダートに近いから、
進化が早いというのは誤った感覚なんだよ。

実際にES2015から１年かけて最新のES2016で入ったのは？
「Array##includesメソッド」と、「べき乗演算子」、このたった２つだけ
じゃあES2017候補締め切りまで残り４ヶ月程、
stageが上がるミーティングの機会が実質１１月末の残り１回となった今、
stage3以上に達しているのは？
たったの３つ……

どこが？？？急速な？？？進化？？？
そもそもJSみたいな重要で幅広い影響を持つ言語がそんなに急速に進化しちゃ困るんだよ。
急速になってるのは、実装の方。ただそれも仕様と実装が切り離されてて、今までと比べてはってだけで、
別に他の言語環境と比べると歩みが早いわけではない。ただの錯覚。

0480デフォルトの名無しさん

2016/08/14(日) 19:29:13.63ID:Ccd3Odrv

>>478
だから俺に聞くなって

↓こいつに聞け

468 名前：デフォルトの名無しさん[sage] 投稿日：2016/08/14(日) 11:44:00.55 ID:2ASH1YAS [2/4]
船頭多くして船山に登る

0481デフォルトの名無しさん

2016/08/14(日) 19:53:31.07ID:3pxbNAv8

船頭多いのはjsだよね

0482デフォルトの名無しさん

2016/08/14(日) 20:01:51.38ID:d9Nb5GY4

>>480
お前　(ID:Ccd3Odrv)　が>>469で自分で言ったことだろ
自分の発言なのに、なんで説明できないんだ？

>他の言語ではほぼ一つの団体が牛耳ってる状態だから
>まさに船頭多いしてってやつになってる。

↑の説明をしろ

0483デフォルトの名無しさん

2016/08/14(日) 20:09:58.04ID:R3wwWztq

>>465
レベルの低い争いを静観してるw

0484デフォルトの名無しさん

2016/08/14(日) 20:10:23.18ID:Ccd3Odrv

馬鹿なのかな？
船頭が10人います。でも船は一艘しかありません。
船頭が10人います。船も十艘あるので競争できます。

0485デフォルトの名無しさん

2016/08/14(日) 20:28:28.78ID:YNmu3wYY

戦争なんてしてないと思うが。

0486デフォルトの名無しさん

2016/08/14(日) 20:35:34.84ID:d9Nb5GY4

なんで船頭が同じ数だけいる前提なの？
なんでJSだけ船頭と同じ数だけの船がある前提なの？

同じ量の人的リソースの分配方法っぽく問題をすり替えて詭弁してるけど
その前提がまずおかしい

お前は自分で

>>459
>使っている人が多いのは当然のこと開発している会社や団体も多い。
>この人的リソースに勝てる言語は他にないって話なんだが。

とか

>>466
>人口じゃない。進化させようとしている人の数だ。
>進化のスピードが倍になるとは限らないが、
>進化させようとする人が多ければ、進化のスピードが上がる。

とか書いてるだろ？自分の発言だろ？
JSは　「当然のこと開発している会社や団体も多い」
んだろ？お前が書いたことだぞ
だったら船頭も多いよな、当然

なに勝手に同じだけのリソースを割り振るときの方法論みたいな話にすり替えてんだよ

お前の言い方だったら
・船頭が100人います、船は十艘あります、一つの船あたり10人の船頭です、合計10蹟で一つのタンカーを引っ張ります
になるわけだが
まぁこんな意味不明な言い回しに何か意味があるとは思わないが

0487デフォルトの名無しさん

2016/08/14(日) 20:40:35.12ID:Ccd3Odrv

>>486
その理屈で良いのか？（笑）
ならこういうことだぞ。

別に船頭は多くない。

>>468に言ってやれよ。
船頭は多くないって。

0488デフォルトの名無しさん

2016/08/14(日) 20:42:02.97ID:Ccd3Odrv

つまり結論としてはにJavaScriptを開発している
団体が多いので、それぞれが開発を行い競争が行われる。
その結果JavaScriptの進化が早くなるわけだ。

0489デフォルトの名無しさん

2016/08/14(日) 20:47:22.07ID:d9Nb5GY4

船頭が多くない理由は？
それから
一つの団体が牛耳っている方が
船頭が多いという理由は？

0490デフォルトの名無しさん

2016/08/14(日) 20:48:25.11ID:Ccd3Odrv

> 船頭が多くない理由は？

先に船頭が多くなる理由を答えろよｗ

0491デフォルトの名無しさん

2016/08/14(日) 20:52:58.08ID:d9Nb5GY4

お前が自分で書いてるだろ

>当然のこと開発している会社や団体も多い。

って

たくさんの会社や団体が参加しているんだろ？
船頭が多いじゃないか
自分で書いといて何言ってんの？

そんで

>他の言語ではほぼ一つの団体が牛耳ってる状態だから
>まさに船頭多いしてってやつになってる。

の説明は？

0492デフォルトの名無しさん

2016/08/14(日) 20:54:26.96ID:Ccd3Odrv

> たくさんの会社や団体が参加しているんだろ？
> 船頭が多いじゃないか
> 自分で書いといて何言ってんの？

なんで参加者全員が船頭になってるんだよｗｗｗ
船頭の意味分かってないだろお前。

0493デフォルトの名無しさん

2016/08/14(日) 20:56:45.75ID:lGY0/ii7

>ブラウザメーカーは船だよ。船がいくつも有って船ごとに船頭がいる。
>船が一つで船頭が多くいれば、あーだこーだ言って進まないが、

そもそも「船頭多くして船山に登る」ってのは、進まないことじゃなくて
あらぬ方向に進んでしまうことを言うんだがな。

0494デフォルトの名無しさん

2016/08/14(日) 20:57:01.46ID:Ccd3Odrv

JavaScriptの特異な所が
たくさんの会社や団体が、それぞれ自分のスピードで
開発を進めるることができる所。
つまり船がたくさんある状態だよ。

一般的な、標準化 → 開発という流れではなく
開発 → 標準化という流れですすむから、
標準化の前に開発が行われる。

船が一つだと競争は生まれないが、
船がたくさんあるので競争が生まれ
速いスピードで進化することができる。

0495デフォルトの名無しさん

2016/08/14(日) 20:59:16.21ID:d9Nb5GY4

>なんで参加者全員が船頭になってるんだよ

そんなこと一言も書いてないだろ

>当然のこと開発している会社や団体も多い。
たくさんの会社や団体が参加しているんだろ？
お前の書いたことだろ？
すなわち船頭が多いだろ？

それから

>他の言語ではほぼ一つの団体が牛耳ってる状態だから
>まさに船頭多いしてってやつになってる。

の説明は？

0496デフォルトの名無しさん

2016/08/14(日) 21:01:46.17ID:Ccd3Odrv

>>493
同じことだよ。
あらゆる方向に進んでしまうから標準化された
正しい方向に進まないということ。

JavaScriptの場合は、標準化と言うプロセスがあるから
あらゆる方向に進むのではなく統一された方向に進む。
ただし進む順番は各自バラバラ。

そこに競争が生まれる。
開発→標準化という流れだから、
標準化されていながら、開発は素早く行われる。

0497デフォルトの名無しさん

2016/08/14(日) 21:03:56.59ID:Ccd3Odrv

>>495
> たくさんの会社や団体が参加しているんだろ？
> お前の書いたことだろ？
> すなわち船頭が多いだろ？

船頭が多くても船の数も多いのだから
船に対する船頭の数は変わらないだろｗ

船が多いから競争が生まれるってさっきから何度も言ってるだろ。

変わらないって結論になったよな？
それとも何か？ようやく船頭の数が多くなる理由を
答える気になったか？

0498デフォルトの名無しさん

2016/08/14(日) 21:04:47.57ID:Ccd3Odrv

>>495
> >他の言語ではほぼ一つの団体が牛耳ってる状態だから
> >まさに船頭多いしてってやつになってる。
>
> の説明は？

団体が一つしか無いんだから、
そこに全部の船頭が集まるしか無いだろｗ

0499デフォルトの名無しさん

2016/08/14(日) 21:07:02.27ID:d9Nb5GY4

たとえ船頭が沢山いても、船頭たちは心の中に自分だけの船を持っているので
一人ひとりの心の船に着目すれば、一つの船に一つの船頭～

なんてのは詭弁以外の何物でもない
バカバカしい
なにも現状を言い表していない
論点のすり替え
あえて、そのようなイカれた考えをする必要性がこの世の中に全くない
しいて言えば、子供を慰めるときに使えるぐらいか
最高のスイーツ
何の役にも立たないバカの発想

0500デフォルトの名無しさん

2016/08/14(日) 21:13:52.67ID:d9Nb5GY4

>船頭が多くても船の数も多いのだから
>船に対する船頭の数は変わらないだろ

まさしく俺が適当に書いたポエム>>498通りの回答が返ってきた
こんなふうに局所的に見て理屈をこねくり回して何になるのか

実際問題でいえば、船頭　=　それそれの思惑を持った企業・団体であるから

>当然のこと開発している会社や団体も多い

のであれば船頭が多い

>他の言語ではほぼ一つの団体が牛耳ってる状態

よりも船頭が多いということになる

0501デフォルトの名無しさん

2016/08/14(日) 21:16:18.04ID:d9Nb5GY4

アンカーミスしたわ
>まさしく俺が適当に書いたポエム>>498通りの回答が返ってきた
>こんなふうに局所的に見て理屈をこねくり回して何になるのか

まさしく俺が適当に書いたポエム>>499通りの回答が返ってきた
こんなふうに局所的に見て理屈をこねくり回して何になるのか

0502デフォルトの名無しさん

2016/08/14(日) 22:38:45.67ID:YNmu3wYY

いや、いろいろ考えてみたが、
ブラウザベンダー、エンジン、プログラマー、Webユーザーなどを、
船頭の例えで振り分けるのは無理があるわ。

無理やり振り分けて船頭がどうのこうの言っても仕方ない、
船頭の例えは原則船頭とその他下っ端の２者で構成されるチームという
単純な構成でしか上手くはまらない。

現実はもっと複雑だからね。
無価値な例え話や空想論をいくら積み重ねても説得力は上がらない。
>>ID:Ccd3Odrvは現実のデータを持ってきて説明してくれ。

0503デフォルトの名無しさん

2016/08/14(日) 23:08:22.54ID:Ccd3Odrv

>>ID:Ccd3Odrvは現実のデータを持ってきて説明してくれ。

データ？ほれ

ES.nextと策定プロセス
https://azu.github.io/slide-what-is-ecmascript/slide/10.html
> ECMAScript 2016からは機能ごとに仕様のプロポーザル(提案)を出し策定
> それぞれのプロポーザルにはStageと呼ばれる5段階のラベルがある
> 1年ごとに新しいECMAScript仕様がリリースされる
> Stage 4となったプロポーザルは次期ECMAScriptに取り込まれ、正式にECMAScriptの仕様となる

他のブラウザたちのレンダリングエンジンとJavaScriptエンジン
https://tsuchikazu.net/phantomjs-browser-javascript-engine/
> ブラウザレンダリングエンジン JavaScriptエンジン
> IE Trident Chakra
> Chrome Blink V8
> Opera Blink V8
> Safari WebKit JavaScriptCore(Nitro)
> PhantomJS WebKit JavaScriptCore(Nitro)
> Firefox Gecko SpiderMonkey

これだけ多くの開発会社・団体がそれぞれ競争しあって
開発している言語なんて無いよ。

他の言語なんてオリジナルが有って、それの派生版を
作ってるとかそんな感じだしな。

0504デフォルトの名無しさん

2016/08/14(日) 23:37:17.68ID:SaGN03aV

ESはライブラリの貧弱さがいつまでたっても解決されないよね
どこかの言語みたいに独裁者がいるようなとこだとまた違うんだろうけど…

0505デフォルトの名無しさん

2016/08/15(月) 00:04:53.22ID:WdXosg7c

>>503
いや、だからさー
早いように見えるのは今までが止まってからだって言ってんの
そうじゃなくて他の言語界と比較しても明らかに早いと言えるデータを出してよ

0506デフォルトの名無しさん

2016/08/15(月) 00:26:54.61ID:Q0oN0eQj

>>504
その某どこかの言語では「複数行のラムダ」問題が
いつまでたっても解決されないよね
その某独裁者様自身が「解けないパズル(unsolvable puzzle)」と
匙を投げる始末だし

http://echo.2ch.net/test/read.cgi/tech/1415419907/197

スレタイにあるJS(ES)/PHP/Rubyではあっさり解けてしまったのに、
Pythonで解けないのは、某独裁者が間抜けなのか、それとも
そものもの言語処理系の基本設計に致命的な欠陥があったのか、
どっちなんだろう？

0507デフォルトの名無しさん

2016/08/15(月) 01:25:14.98ID:vavdf6hQ

>>506
横だが、リンク先見てきた。
それで、そのPythonだが、何が問題なんだ？

今SyntaxErrorというのは分かったが、文法的に矛盾がなければ将来的には導入されるだろう。
もちろんそれが未だに為されていないのは何か問題があるはずという指摘なのだろうけど、
その原因の「致命的な部分」が何か知っていたら教えてくれ。

ただまあ、名前付ければ解決する話なら、割とどうでもいいから放置されている気もするが。

0508デフォルトの名無しさん

2016/08/15(月) 02:54:07.24ID:8uNftPIu

Pythonが複数行ラムダで困っているのは
特殊な変数スコープのせいだよ
参照だけならアウタースコープ
代入があればインナースコープ
っていう糞みたいなアイデアのおかげで
もうどうにもならないよ
それで、Pythonの人たちは、無名関数なんか糞で、名前が無いのは糞
明示的に関数名を書け！って言いだして、そんな感じ
個人的に代入の有る無しでスコープが変わるのは気持ちが悪い

そもそもの原因は変数宣言を代入で代用したことに始まっていて
だから代入があればインナースコープに新しい変数が宣言されたことになるし
代入無しで参照のみなら宣言がないのでアウタースコープの変数ってことになってしまった
動的型言語で宣言時に型を決める必要がないからと、宣言を無くそうって、早とちり
残念ながら変数宣言には変数の型を決める役割の他に、スコープを決める仕事もあるわけだが
宣言をなくして、これを代入で代用したのがそもそもの失敗だね

結局スコープを決めるために変数宣言は必要なんじゃね？って話で
だったらついでに型名を書くのもアリだし、型推論させてもよいよねってことで
制的型言語大勝利！！

0509デフォルトの名無しさん

2016/08/15(月) 03:10:48.21ID:8uNftPIu

動的型言語はどうも宣言を無くそうっていうエネルギーがあって
それもそのはずで
var i = 0　とか宣言書かされるのなら
int i = 0 って書くのも、auto i = 0 って書くのもタイプ量は大差ないわけで
そうすると動的型言語のディメリットばかりが目立ってくるから
明らかな目に見えるアドバンテージを得るために
どうにかして宣言を無くそうと企むわけだが
変数のスコープをどうやって表現するんだってところで煮詰まる
あの手この手って感じではあるが
Pythonのとった、代入に変数宣言を兼ねさせるという手は最悪手といえる
本質的に別なものが同一表現となり区別がない
X軸を動かすと一緒にY軸も連動するようなもの
確かにレバーは一つで済むが、これは便利なのか？

てことで、スコープの問題があるので変数宣言はあったほうが良いし
どうせ宣言をするなら型名を書いてもよいだろうし、型推論もあるので
静的型言語大勝利となったわけだ

0510デフォルトの名無しさん

2016/08/15(月) 03:17:31.15ID:Y0Jnfl62

宣言をなくすのは良いけど、なくしたら
可読性が下がったので、コメントでどんな型が入るのか
どんな型を戻り値として返すのかをちゃんと書きましょう
ってなったら本末転倒なんだよなｗ

0511デフォルトの名無しさん

2016/08/15(月) 03:21:31.74ID:Y0Jnfl62

推論もコンピュータならどんなに離れた所にある
情報からでも、素早く推論できてしまうけど、
コード読むのは人間なんだよね。

人間は推論できるからって一瞬でできるわけじゃない。
推論しなくて済むように情報を書いておくことが
高い可読性に繋がる。

だから推論もローカルスコープ程度の範囲で十分だと思う。
あとは明確に定義して矛盾があればコンパイラが指摘。

0512デフォルトの名無しさん

2016/08/15(月) 04:15:16.59ID:lVdQrwsf

>>511
でもJavaのようなコードは誰もが書きたくないわけで
そこら辺は難しい部分だよね

0513デフォルトの名無しさん

2016/08/15(月) 07:49:13.51ID:vavdf6hQ

>>508
これか。
http://d.hatena.ne.jp/saitodevel01/20101205/1291582273
先に言っておくが、俺はPythonとRubyは知らない。JavaScriptは知っている。

Pythonの4、確かにこれは癌だな。
クロージャ内での外部変数への再代入が文法的に出来ない。
ついでにその下のRubyも見てみたが、こちらは上記ケースには別宣言を使うって事か？
この点については文法的にはJavaScriptが一番マシだな。(一つの文法で全部対応出来る）
ただしそれに伴う「書き損なったら勝手にグローバル」ってのがあるので、
Rubyがこれを明示的に分けてSyntaxErrorで落とすのなら、それもかなり良い。

ただRubyが問題なく対応出来ているのにPythonがやらないのは政治的な理由だろう。
元々Pythonは「いろんな書き方が出来ること」を是としていない。
だから制約付きでも書ければいいということなのだろう。
この点は俺は間違っていると思っていて、俺が全くPythonに惹かれないのはこれによる。
プログラマに対して制約を付ける言語は要らない。

型推論については、多分C#の「関数内ローカルではあり、戻り値には無し」というのが正解だと思う。
関数内でいちいち書くのは面倒な時もあるが、戻り値は明示的に型を示しておいた方が後々いい。

0514デフォルトの名無しさん

2016/08/15(月) 08:43:31.46ID:Gg8fpt17

クロージャ内での外の変数への再代入なんて、できてもやるべきではない行為だからどうでもいいわ
これこそエセ関数型が生み出した癌

0515デフォルトの名無しさん

2016/08/15(月) 10:17:45.67ID:NgpYEBNI

でもその厳し過ぎるほどの厳とした制約故のシンプルさとスマートさがサイエンス領域での信頼を勝ち得ているとも言えるのでは
科学は試行錯誤の連続、天から降り注ぐ無数のアイディアをパパッと試せなければ意味が無いのだ

0516デフォルトの名無しさん

2016/08/15(月) 11:40:35.84ID:Y0Jnfl62

>>512
> でもJavaのようなコードは誰もが書きたくないわけで

そう【書きたくない】
わかってるじゃないかｗ

書きたくないのであって読みたくないわけじゃない。
【可読性】というのは文字通り読む時の話で、
Javaのようなコードを読みたくないわけじゃないんだよな。

書きたくないのなら書かなければいい。
つまりIDEやテキストエディタで補完させればいい。

0517デフォルトの名無しさん

2016/08/15(月) 11:45:56.02ID:Y0Jnfl62

>>514
> クロージャ内での外の変数への再代入なんて、できてもやるべきではない行為だからどうでもいいわ

外の変数の参照も不要な場合が多い。

で、俺は思うんだよ。

クロージャーはレキシカルスコープにある変数を参照できるが、
それは有った方がいいが、それとは別にレキシカルスコープにある変数を
参照できないただの（無名）関数もあったほうが良いんじゃないかって。

それがあると、クロージャーが長くなってしまったときに
別の関数に分離しやすくなる。

0518デフォルトの名無しさん

2016/08/15(月) 11:54:10.96ID:Gg8fpt17

>>517
外への参照だけなら引数で渡すのと実質的に等価だから害はないよ
外への書き込みができてしまうとスコープを昇格させたりと複雑になる

0519デフォルトの名無しさん

2016/08/15(月) 12:07:55.59ID:g49T5w75

Rubyみたいに、変数はスコープをまたげない。
またぎたいなら、引数・戻り値を使うのがシンプル

Pythonでは記述が減ったが、プログラマーが確かめなければならない、
組み合わせが増えた(組み合わせ爆発)。
テスト・デバッグも大変

1つでも可能性・抜け道があったら、それを確かめなければならないから、ダメなんだよ

0520デフォルトの名無しさん

2016/08/15(月) 12:11:34.87ID:IJ3qyh5x

ダイナミックスコープにスコープ指定子をブレンドしたPowerShellさんの場合
PS > $a=99; & { $a; $a=0; $a; $script:a; $script:a=55; $a; $script:a }
99
0
99
0
55

0521デフォルトの名無しさん

2016/08/15(月) 13:02:20.63ID:Iw/8BWbs

近い将来に必ず訪れるであろう人工知能時代に向け、俺は武器を身につけようと思う
Pythonと数学という最強の武器をね

俺は元々アート方面に才のあるクリエイターだったが、ある日、
「それは、世界を幸せにしているだろうか。」
という問いが舞い降りた

そう、アートだけでは真の幸せは提供できないと気付いたのだ
クリエイティブ+ICTで、Pythonと数学で、AIテクノロジーで、世界をクリエイティブにサイエンスし人々を幸せにしたい

0522デフォルトの名無しさん

2016/08/15(月) 13:05:17.02ID:Y0Jnfl62

>>518
> 外への参照だけなら引数で渡すのと実質的に等価だから害はないよ
害のある無しじゃなくて、クロージャーが長くなったときに
別関数にリファクタリングする時の話をしてるんだよ。

例えば、
function main() {
　sort(function() {
　　長ったらしいソート条件
　})
}
って有ったときに

function _hoge() {
　長ったらしいソート条件
}
function main() {
　sort(_hoge)
}

に置き換えていいものかどうか？
クロージャーではなく、外の変数の参照ができないならば、
この置き換えは簡単に行える。

0523デフォルトの名無しさん

2016/08/15(月) 13:10:24.56ID:t/SN5WKS

>>522
そんなの見りゃわかるだろ
外のシンボルを参照してるかどうかすらパッと見て分からないほど長ったらしい条件なら、
先にその条件の方をリファクタリングしろ

0524デフォルトの名無しさん

2016/08/15(月) 13:13:21.45ID:Y0Jnfl62

もう一つの例として、

function main() {
　var el = document.getElementById("id");
　var a = [どでかい配列];
　el.addEventListener("click", function() {
　　　// ここからelやaが参照できる
　}, false);
}

イベントハンドラの中からaが参照可能であるということは
たとえclickイベントの中で使わなかったとしても、
このa配列が解放されることはない。

function onclick() {・・・}
function main() {
　var el = document.getElementById("id");
　var a = [どでかい配列];
　el.addEventListener("click", onclick, false);
}

こうすることでa配列は解放されるが、このためだけに
クロージャーを別関数にするのはどうなんだろうか？

クロージャーではなくレキシカルスコープを持たない無名関数というものが
有ったとしてそれを引数にできていてればこの問題は起きない。

クロージャーは有ったほうが良いのはもちろんだが、
特に理由がないならば、ただの無名関数のほうがベターだろう。

0525デフォルトの名無しさん

2016/08/15(月) 13:15:04.77ID:Y0Jnfl62

>>523
> 外のシンボルを参照してるかどうかすらパッと見て分からないほど長ったらしい条件なら、
> 先にその条件の方をリファクタリングしろ

そのリファクタリングをするために、スコープをより小さくできる方が良いって話。

0526デフォルトの名無しさん

2016/08/15(月) 13:24:35.84ID:Y0Jnfl62

クロージャーはレキシカルスコープを持っているのが特徴だが、
レキシカルスコープ上の変数を参照することがない場合ってのは
少なくないんだよ。参照するにしてもその一部だけとか。

実はPHPのクロージャーはこんな感じで
useをつけた変数のみが参照可能になってる。
http://php.net/manual/ja/functions.anonymous.php

0527デフォルトの名無しさん

2016/08/15(月) 15:12:49.88ID:WdXosg7c

>>524
今のエンジンは実際に参照される可能性がなければきちんと開放する。
evalを使ってたりデバッグ中などでない限りね。

0528デフォルトの名無しさん

2016/08/15(月) 16:09:32.79ID:3EBVynfi

米国防高等研究計画局、Pythonに300万ドル支援
http://s.news.mynavi.jp/news/2013/03/29/083/
1位は「Python」、プログラミング言語別の平均年収ランキングが発表
http://www.mdn.co.jp/di/newstopics/44248/

0529デフォルトの名無しさん

2016/08/15(月) 16:24:26.72ID:/dYWmJLs

Pythonの読み方すら知らないクソSIerにPython導入してやったわ
Python知らないとメンテ不可能なサービスを残して辞めてやる

0530デフォルトの名無しさん

2016/08/15(月) 23:42:33.80ID:Jt6+bv4/

pythonのlambda式の中に代入文を書けないのは文だからだよ
lambda式の中にlambda式を書けるのは式だからだよ
これは機械的なルールだよ
つまり人間のように利益を追求するためならルールを変えていいみたいな考え方とは違う

0531デフォルトの名無しさん

2016/08/16(火) 00:39:20.22ID:sxoKSJmA

機械のほうが人間に合わせろ

0532デフォルトの名無しさん

2016/08/16(火) 01:29:13.37ID:pFCjgoYw

>>515
> 無数のアイディアをパパッと試せなければ意味が無いのだ
だから他のLL言語でパパッと書けることが書けないのなら駄目だろ。

0533デフォルトの名無しさん

2016/08/16(火) 08:42:13.01ID:IfLExIwZ

pythonは普通だと言われていたが、なかなか個性的じゃないか

0534デフォルトの名無しさん

2016/08/16(火) 13:18:17.28ID:L1mnCUZN

>>532
では何故ゆえに科学技術分野でPythonさんは覇権を取れてるのだろうね、ふふふ

0535デフォルトの名無しさん

2016/08/16(火) 13:20:06.90ID:ut1Cjuak

未来の世界へ

世界でいちばん面白いエンタテインメントを創りたい。圧倒的なコンピューティングパワーの遊び専門ですごいやつ。
こんな夢の中から俺の新たな決意>>521は生まれた。

俺たちが、創造する、新しく、ワクワク、ドキドキするエンタテインメントの世界。
エンタテインメントのかたちが、どんなに進化しようとも、楽しいものをつくりたい。創造したい。そして世界中に幸せを届けたい。
そんなエンタテインメントとクリエイティブへの熱き情熱を満たすＤＮＡが俺たちの中にはある。

最大限に能力を発揮するため、ひとりひとりに高次元な自由と責任があるこの世界。
高い志（パッション）と高い力量（プロフェッショナル）を持つ心熱き人々。
非常識なほどの最先端未来テクノロジーの実現へのチャレンジ精神。
全職種がクリエイター。
さあ、世界中を「あっ」と驚かせないか。
新たなエンタテインメントの創造に果敢に挑戦する好奇心と意欲、そして無限大の才能を持った新たな出会いを心から待ってる。

0536デフォルトの名無しさん

2016/08/16(火) 13:42:11.04ID:TKmF9qhA

>>534
単純にGoogleが肩入れする言語のひとつだからだろ。
Appleが躍進する前には誰も見向きもしなかったObj-Cがシェアを伸ばせたのと同じ構造。
そしてそのObj-CがSwift後に誰も見向きもされなくなるのと同じことがいずれPythonにもやってくる。

0537デフォルトの名無しさん

2016/08/16(火) 16:22:23.22ID:ooIS751I

ジャアアアアアアアアアアアｗｗｗｗｗｗｗｗｗ

0538デフォルトの名無しさん

2016/08/16(火) 16:26:14.32ID:uRC9VBAF

GoogleといえどもDartとかの失敗作もあるしなー
angularを通じてすっかりTypeScriptに転向しちゃったし

0539デフォルトの名無しさん

2016/08/16(火) 19:22:48.00ID:E0Gd5ppR

Angularも本気かどうか疑わしいし
Googleの失敗は意外とある

0540デフォルトの名無しさん

2016/08/16(火) 20:00:53.03ID:sxoKSJmA

>>534
> では何故ゆえに科学技術分野でPythonさんは覇権を取れてるのだろうね、ふふふ

COBOLが業務系で覇権を取れているのと同じでは？
JavaScriptがウェブ系で覇権を取れているのと同じでは？

0541デフォルトの名無しさん

2016/08/16(火) 22:34:57.60ID:uRC9VBAF

>>539
angularは今のコミット頻度を考えるとかなり本気みたいだけどね
成功するかどうかは知らんが

0542デフォルトの名無しさん

2016/08/16(火) 22:46:37.52ID:mR0JEmP+

Googleは戦略的な技術選びが苦手というか社風として嫌いなんだろうな
明確な戦略やビジョンがないとプログラミング言語は作れない

0543デフォルトの名無しさん

2016/08/16(火) 22:52:24.50ID:BQX0KEz5

dart自体は明確なビジョンがあったよ
全く空気読めて無かった結果がコレだけど

0544デフォルトの名無しさん

2016/08/16(火) 23:05:43.74ID:SZhaYTt6

Dartはまだ失敗とも成功とも言えないと思う。
実際にエンジン開発での副産物が沢山V8で活用されているし、
仕様や仕様を作る過程で出たノウハウを活かす
SoundScriptとかJSの新'use ～'案も挙がってるしね。

0545デフォルトの名無しさん

2016/08/16(火) 23:34:49.44ID:mR0JEmP+

>>544
いいかげん現実見ろよ
お前1年くらい前から同じこと言ってるだろ?
何か状況は進展したか?

0546デフォルトの名無しさん

2016/08/16(火) 23:42:40.43ID:H7s3Bc86

おつおつ

0547デフォルトの名無しさん

2016/08/17(水) 00:15:04.35ID:Gg2A+FYU

altJSも結局はES2015あるからもういいや状態だし

0548デフォルトの名無しさん

2016/08/17(水) 00:21:08.02ID:/KeBf+RU

Goは多分JAVAの代替を狙ってるね

0549デフォルトの名無しさん

2016/08/17(水) 15:01:42.56ID:7mpH/Vqy

>>545
自分はこれを言うのは初めてだし、現実を見ろという意味も分からない。
ただ単に何を持って成功と言うかは色いろあるということを言いたいだけなんだが。
逆に今「Dartは失敗」という結論を出したところで何がどう変わるというの？
君が何をそんなに拘ってて焦ってるのかが分からないな。
ただ自分はまだDartについて総論を出すのは早いでしょと至極当然のことを言ってるだけなんだが。

0550デフォルトの名無しさん

2016/08/17(水) 21:00:29.83ID:EvJVMuWG

>>549
君は結論を出すのが早いと言ってる。
俺は結論を出すのが遅いと言ってる。
それだけなんだが、なんであんたのほうが正しいってことになるんだ？

0551デフォルトの名無しさん

2016/08/17(水) 21:08:16.60ID:A8aakIgG

ダメなものはユーザーを無視してバッサリ切り捨てることがGoogleの強さの大きな一因だろ
信者なら自分が気に入っていたプロダクトが斬り捨てられたらGoogleの成長の犠牲になれたことを光栄に思うべきじゃないかや

0552デフォルトの名無しさん

2016/08/17(水) 21:52:06.72ID:snC5ca9e

>>544
> 実際にエンジン開発での副産物が沢山V8で活用されているし、
> 仕様や仕様を作る過程で出たノウハウを活かす

そんなんDartの成功・失敗とは何の関係もない話じゃん
Dartは失敗したんだよ

とはいえ別にGoogleの社運を賭けたプロジェクトというわけでもないし、
Googleとてすべてのプロジェクトを成功させられるとは自身でも思ってないだろうしね

0553デフォルトの名無しさん

2016/08/17(水) 23:51:04.52ID:3JeGu9I6

>>544
>SoundScriptとかJSの新'use ～'案も挙がってるしね。

strong modeのことならV8から削除されたよ
想定以下の性能と実装の複雑さが理由

>>549
生まれた日は確かだが、死んだ日はそうではない
意見が分かれるのは分かるよ

0554デフォルトの名無しさん

2016/08/18(木) 06:58:20.70ID:FdMcbMvO

>>552
自分はDartは言語というよりもプロジェクトだと認識してるから、
たとえDartが言語として日の目をみなくとも、
その仕様や実装がJSの方で活かされること、
また、その結果JSの代替言語を作るということは叶わなくとも、
その目的だったことがJSの進化に貢献することで叶うのならトータルで成功だと思う。

個人的にはこのプロジェクトは失敗の要素と成功の要素が拮抗してると思うから、
まだまだこの先のJS周りの動きを見ないと、
Dartって役に立ったプロジェクトだったよねと言えるかどうかはわからないと思う。

0555デフォルトの名無しさん

2016/08/18(木) 07:02:15.42ID:FdMcbMvO

>>550
君の考えが正しくないとは言っていない。
自分の前提を正しく汲みとってくれてないことを暗に批判してるだけ。

0556デフォルトの名無しさん

2016/08/18(木) 07:30:18.85ID:AN0ChobI

DartがGoogleやその他JS界にとって>>554が思っているほど重要な存在だったかについては
大いに議論の余地があると思うけどね。
ごく一部のチームのちょっと目立つアイデアを大袈裟に公表し、
ダメならあっさりフェードアウトというのはGoogleにはよくあるパターンだ。
社内でまともに検討してたらDartなんて世に出なかっただろう。
Dartの成果はJavaもどきのダックタイピング言語のコンパイラだけで
特に技術的に変わったことをしているわけではなく、性能も大したことない。
知名度も低かったし、Dartは取るに足りない数ある失敗プロジェクトの一つ、として切り捨ててしまっても全く問題ないと俺は思うよ。

0557デフォルトの名無しさん

2016/08/19(金) 08:34:04.78ID:ybmjJZzO

その大いに議論の余地あるということが言いたい。
ぶっちゃけると結論Dartが失敗だろうが成功だろうがどうでもいいかもしれない。
一番は、表面だけを見てすぐ結論を出す人は嫌いということ。
自分は優柔不断に生きてきた人間だからね。
ただそれだけのつまらないこと。終わり。

0558デフォルトの名無しさん

2016/08/19(金) 08:47:38.58ID:CvT4Ryaa

で、日本のITが世界で通用しない理由はまさに>>557のような企業文化にあるんだけどね
試行錯誤にコストがかからないというのがITと製造業や土建との間の大きな違いであり、
トップダウンの即断即決でダメなものはダメと切り捨ててどんどん新しいやり方を試す方が結果的に利益を生む

0559デフォルトの名無しさん

2016/08/19(金) 08:47:49.30ID:fihwHPa+

Dartを発表することでGoogleもJSはウンコだって思ってるって知らしめた
それだけで価値はあったよ

0560デフォルトの名無しさん

2016/08/19(金) 09:23:49.87ID:ybmjJZzO

>>558
それは飛躍し過ぎだろう。
仕事とプライベートを一緒にされてもな。

自分もマネージャーとしては全体を見て効率的にキッパリ運用させるし、
リーダーとしてはハッキリした指示が出せるよう毎日努めている。
ただ、よく迷った時は第一直感と聞くが、
経験上もう一回り二回り考えてから出した案の方が遥かに良いことが多い。

きっとそれだけ経験不足でセンスが無いということなんだろうが、
その分考えて出した答えにはまずまず自信がある。
だから優柔不断でいいと思っている。

0561デフォルトの名無しさん

2016/08/19(金) 09:26:47.69ID:Bg2sM+x4

切り捨てた結果利益を生むというのは典型的な大本営発表だな

損した結果切り捨てられる
これが現実だ

0562デフォルトの名無しさん

2016/08/19(金) 09:46:43.56ID:CvT4Ryaa

>>559
一方、Webブラウザネイティブなクライアント技術を嫌っているイメージのあったMSは
JSを否定するのではなくより良くするソリューションを示し、AltJS戦争に終止符を打った
皮肉な話だな

0563デフォルトの名無しさん

2016/08/19(金) 16:52:13.89ID:ybmjJZzO

より良くするソリューションってなんだ？
ひょっとしてES2016のこと？それともWASMのこと？

0564デフォルトの名無しさん

2016/08/19(金) 19:26:19.60ID:gmPyPSgz

TypeScriptではないからなんだろうな

0565デフォルトの名無しさん

2016/08/19(金) 20:17:10.24ID:sPqMn9Q1

ここまでJSが広まったのもgoogleのせいだしな

0566デフォルトの名無しさん

2016/08/19(金) 21:25:30.10ID:U1hiIUMq

>>562
> 一方、Webブラウザネイティブなクライアント技術を嫌っているイメージのあったMSは

俺はそうは思わないよ。むしろ逆。

MSが嫌っていたのは「貧弱な」フロントエンド実装でAjaxという言葉が出るよりも前から
DHTMLという名前でJavaScriptを使ってリッチなフロントエンドを実装しようと頑張っていたよ。

ネット上のMSDNライブラリとかかなり早い段階からローカルにインストールする
MSDNライブラリと同等の使い勝手を模索して作られていた。
当時のブラウザの実装は遅かったから、重くてたまらなかったけどな。

MSはHTML5など当然ない時代に、リッチなフロントエンドを実装しようとしていたがゆえに、
ブラウザの低い機能を補うためにActiveXなど一部に独自の拡張を入れざるをえなかっただけで、
ブラウザネイティブなクライアント技術を嫌っていたわけじゃない。

0567デフォルトの名無しさん

2016/08/19(金) 22:09:42.53ID:MUfetYKB

当時のMSはシェアにかまけてウェブ標準を軽視してたからしゃーなし
もしその気があればウェブの最先端は常にMSが仕切ってただろうに

0568デフォルトの名無しさん

2016/08/19(金) 23:40:40.47ID:U1hiIUMq

それはMSがウェブの標準化団体を作るってことか？

技術的にはMSはウェブの最先端だった。
IE6が長く生き残ったのがその証拠で、例えば
Polifillを作ることでIE6でもAjaxやCanvasが使えた。

ようは標準として採用されなかっただけで、MSがブラウザに搭載した機能は
最先端だったんだよ。

0569デフォルトの名無しさん

2016/08/20(土) 00:11:23.25ID:Ay6TwcxW

そして、Windowsでしか動かない機能、と
ActiveXとか完全にCOMに依存していたからね
標準に採用されるわけはなかった

0570デフォルトの名無しさん

2016/08/20(土) 00:27:28.77ID:GxTqSDb9

>>569
今すぐ手に入る機能の方がよっぽどユーザーのためになるからね。
他のブラウザがIE6なみになったのは、10年もあとなんだよ。

0571デフォルトの名無しさん

2016/08/20(土) 03:49:59.97ID:wE7MoeLi

一党独裁に反対するための標準化団体か

0572デフォルトの名無しさん

2016/08/20(土) 05:27:03.10ID:TeD+k3DW

皆もう忘れちゃってるみたいだけど、１０年前闊歩してたのはActiveXじゃなくプラグイン
ActiveXなんて最初から最後まで一部の信仰を持ったサイトでしか使われて来なかった。

0573デフォルトの名無しさん

2016/08/20(土) 05:30:41.73ID:TeD+k3DW

>>568も、その証拠はむしろ逆のことを示している
それまで見向きもされなかったActiveXが最も注目をあびいたのが、
他のブラウザがリッチになってきてそれをIEに補わすためのポリフィル用途だから。

0574デフォルトの名無しさん

2016/08/20(土) 05:32:24.71ID:TeD+k3DW

IEしか考慮しなくていいクローズドなイントラネットではそこそこ活躍したけれど、
結局Webってそうじゃないでしょということだろうな。

0575デフォルトの名無しさん

2016/08/20(土) 10:31:19.84ID:GxTqSDb9

>>573
何が逆なんだかわからんのだがｗ

Polyfillっていうのは過去の技術で実現可能だったってことだよ。
その技術が搭載されていなければ実現できない。

0576デフォルトの名無しさん

2016/08/20(土) 16:10:12.52ID:TeD+k3DW

最先端というのが逆。
モダンブラウザが時代にあった機能を適切に積んで台頭してきて、
その機能が認められて初めて、IEのポリフィルという話になる。
つまり言い方を変えると常にIEは最もウェブで遅れていたということ。

ActiveXを使っていくらでもエミュレートできるといって話が済むのであれば
それこそプラグインを使えば今のモダンWeb APIの多くがレガシーブサウザでエミュレートできることだしね。
今のFlash再生に厳しくなったChromeと、初期のChromeを比較して、初期を褒めても全くしょうがない。

というかIEはウェブやウェブ技術に興味が無かった。
重視していて最先端であったかもしれないのは精々イントラネットと業務アプリの話。

0577デフォルトの名無しさん

2016/08/20(土) 16:39:58.60ID:GxTqSDb9

>>576
何をそんなに必死になってるの？

いちばん重要なのは、それが今すぐ使える技術かってこと。
IEと同じ時期にウェブ標準で技術を搭載していれば褒められたものだけど
IE6から10年遅れてるんだよ。

0578デフォルトの名無しさん

2016/08/20(土) 18:13:44.98ID:TeD+k3DW

>>577
いちばん重要なのは、それが今すぐ使える技術かってこと。

使えるというのはあるということではない。

0579デフォルトの名無しさん

2016/08/20(土) 18:14:50.98ID:uZI+dI+W

ぶっちゃけスマホ全盛になってブラウザとかどうでも良くなったよね

0580デフォルトの名無しさん

2016/08/20(土) 18:49:00.92ID:Jp0NOcxJ

>>579
そうでもないかな。
ちゃんとモバイル向けに作ってあれば専用アプリのほうが性能いいが、そのへんイマイチなのも多いからね。
それならサイトをモバイル対応にしてくれるだけの方がマシだったりもする。

0581デフォルトの名無しさん

2016/08/20(土) 19:45:32.40ID:GxTqSDb9

>>578
IE6で使えただろ？
何いってんだ？

0582デフォルトの名無しさん

2016/08/20(土) 20:33:03.29ID:0RCZU/IA

たぶんそろそろWEBもオッパイソンさんの覇権が来ると思われ
Railsを超えるオッパイフレームワークがそれを叶える

0583デフォルトの名無しさん

2016/08/21(日) 00:32:23.17ID:RZDnAeyw

Pythonの環境作るの面倒くさいから
作って壊すのが前提のWebサーバサイドで使いたくない

0584デフォルトの名無しさん

2016/08/21(日) 00:42:37.65ID:vHDD4AcV

>>583
壊した後に一から環境を作るのが
面倒くさいってことですね。

自動化しなさいよｗ

0585デフォルトの名無しさん

2016/08/21(日) 19:05:04.01ID:21OYkO9i

webのサーバサイドの言語なんて何でもいいだろ
好きなの使いなよ

0586デフォルトの名無しさん

2016/08/21(日) 22:25:42.16ID:AhRtjf/j

>>585
何でもいいわけないだろ

0587デフォルトの名無しさん

2016/08/24(水) 01:18:40.51ID:OsCxdGwN

Go言語は俺には意識が高すぎる

0588デフォルトの名無しさん

2016/08/24(水) 08:38:06.26ID:YO5YWCQh

ジェネリクス無い今はまだイマイチ

0589デフォルトの名無しさん

2016/08/24(水) 08:44:10.34ID:u65p5RKL

何でも良いと思うけど、自動化できるなら自動化しといたほうがテスト楽じゃない？
goみたいな、全部静的リンクなら、デプロイだけで良いだろうけど。

0590デフォルトの名無しさん

2016/08/24(水) 12:20:32.11ID:o+gpyvLw

"Pythonコードを使用して、Pythonコードを書く方法を人工知能に学習させる"
http://postd.cc/teaching-an-ai-to-write-python-code-with-python-code/

0591デフォルトの名無しさん

2016/09/09(金) 10:31:49.54ID:eSudHJTU

結局はJavaなんだよなあ

0592デフォルトの名無しさん

2016/09/09(金) 10:39:53.06ID:vT9Hfq/x

まだJavaドカタって生息してるの？

0593デフォルトの名無しさん

2016/09/09(金) 21:26:29.38ID:oMlYA35z

とJavaで挫折した無能が

0594デフォルトの名無しさん

2016/09/09(金) 21:27:48.87ID:oMlYA35z

Java8で死屍累々になるのは目に見えている

0595デフォルトの名無しさん

2016/09/09(金) 22:11:02.43ID:UoPi6EMs

javaのscript版みたいなのってないの?

0596デフォルトの名無しさん

2016/09/10(土) 00:26:40.67ID:jVtgvLxZ

javascript

0597デフォルトの名無しさん

2016/09/10(土) 00:47:18.47ID:DkEyfYzQ

>>595
釣られんぞ

0598デフォルトの名無しさん

2016/09/10(土) 11:54:02.99ID:mLddSNc6

>>595
マジレスすると、groovy

0599デフォルトの名無しさん

2016/09/10(土) 13:52:32.73ID:7PYUz/R2

Javaドカタって恥ずかしくないの？

0600デフォルトの名無しさん

2016/09/10(土) 20:16:40.49ID:vL431mpn

と
継承もろくに使ったことがない奴隷が

0601デフォルトの名無しさん

2016/09/10(土) 23:30:00.72ID:7PYUz/R2

継承もクロージャもADTも使ってるけど？

あ、Javaにあるのはクロージャもどきだけで、ADTなんて影も形も無かったね

0602デフォルトの名無しさん

2016/09/11(日) 15:23:17.82ID:8kzcEVw8

>>601
クロージャはともかく、

> ADTなんて影も形も無かった

の意図が不明なんだけど。本当にADT、わかって使っている？　ADTってリスコフの抽象データ型のことだよね？
だとすれば特に狭義のADT（型に手続きを含めない。端的にはCLUのクラスタのような限定的なADT）なのかな。

そもそもJavaが踏襲するストラウストラップのOOPは、SIMULA67のクラス（継承を有する）で
ADT（広義の。端的にはユーザー定義型）を実践するアイデアなので、もしそうでないなら奇妙な話だ。
もっとも狭義のADTが無いという話だとしても、Javaがそんな限定的な機能をわざわざサポートしてないからって
何なのだろうかとは思うけど。

0603デフォルトの名無しさん

2016/09/11(日) 17:46:55.76ID:DEM3op8b

ADTで抽象データ型しか思い浮かばないってどんな老害だよ
代数的データ型だろ

0604デフォルトの名無しさん

2016/09/12(月) 13:40:11.03ID:yAWApVyo

Javaドカタw

0605デフォルトの名無しさん

2016/09/12(月) 22:05:10.37ID:LgKJwmNS

Smalltalkerってホント頭の中が1980年代で止まってるよな
頼まれてもいないのに歴史語りだすし

0606デフォルトの名無しさん

2016/09/12(月) 23:19:47.79ID:7DbjPQ05

Smalltalk発のTraitsとかClassboxes（RubyのRefinementsの元ネタ）とかは2000年以降だったような

0607デフォルトの名無しさん

2016/09/13(火) 06:53:29.31ID:dT7BjmFL

頭の中が1980年代で止まってるのはアンチの方だったというオチ？
頼まれてもいないのに脈略なくdisりだすし

0608デフォルトの名無しさん

2016/09/13(火) 08:08:02.18ID:8V/c56zZ

リスコフの抽象データ型w

0609デフォルトの名無しさん

2016/09/14(水) 13:13:22.73ID:XxEjeObi

Javaがウンコって言ってる奴らはHadoop使ってねーの？

0610デフォルトの名無しさん

2016/09/14(水) 22:29:46.65ID:XcTHbKFU

>>608
俺も初めて聞いた。置換原則と違うのかな？
後学のために誰か教えてくれると嬉しい

0611デフォルトの名無しさん

2016/09/14(水) 22:32:35.53ID:XcTHbKFU

>>610
ググったら何か出てきた。これでまた知識を増やせる。
でもその分の何かを忘れてそう。

0612デフォルトの名無しさん

2016/09/15(木) 00:05:57.01ID:jA0u0SmJ

そんな難しく考える必要はないよ。
簡単に言えば、ユーザー定義型のこと。
組み込み型＝具象（concrete）に対して、ユーザー定義の型＝抽象（abstract）。
型と手続きをひとくくりにして扱うことによるモジュール化手法のひとつで、置換原則で有名なバーバラ・リスコフが提唱した。

リスコフ自身は、クラスタという言語機能を持つ CLU という言語を作って ADT を実現したけれど、
Simula 67のクラスという言語機能を使っても ADT が出来ることに気付いて C++ を作ったのがビャーネ・ストラウストラップ。
これが現在主流の OOP の原型「カプセル化、継承、ポリモーフィズム」となった。
念のため、この OOP の三つのお題目のそれぞれ「カプセル化」は抽象データ型の特徴、「継承」はクラスの特徴、
「ポリモーフィズム」は両者の組み合わせで実現可能なことを端的に表わしている。

ちなみに、同じ Simula 67 のオブジェクトにメッセージの受け手としての性格を持たせるアイデアも OOP と名付けられていて
まぎらわしい。これを考えたのはアラン・ケイで、そのアイデアをダン・インガルスが Smalltalk-72 として実装している。
「オブジェクトにメッセージを送って～」という類のお題目はこちらの別筋の OOP の話。

0613デフォルトの名無しさん

2016/09/15(木) 23:45:38.81ID:RXreE/IG

smalltalkって九大病院で失敗した言語というイメージしかないわ

0614デフォルトの名無しさん

2016/09/16(金) 08:23:10.54ID:GMdlpqyO

あれは日本IBMのマネージメントの失態という印象が強いけどね。
http://drillbits.tumblr.com/post/15664104845/九大病院つまずきの真相-要件定義の甘さが尾を引く
http://d.hatena.ne.jp/kwatch/20080702/1215014534

Smalltalkの大きな失敗としては、ケント・ベックやマーチン・ファウラーが参加して火消しをした（が、結局切り捨てられた）
クライスラーの給与計算システムのCOBOLからの移行プロジェクトの方が有名では？
http://bliki-ja.github.io/C3/

0615デフォルトの名無しさん

2016/09/17(土) 10:19:32.87ID:e3sBcjRb

>>614
> SmalltalkをあきらめVBを採用へ

あ、そういう位置付けの言語なのね

0616デフォルトの名無しさん

2016/09/17(土) 11:27:22.12ID:u1efh43o

>>615
> GemStoneはサーバー側でSmalltalkプログラムを実行することができたが，
> Matisseではそれができない。このため，クライアント中心の処理へと，
> システムを大幅に設計し直す必要が生じた

とありますから、GemStoneを使わないならクライアント側はどうでもよくなったのでしょうね。
ちなみにGemStoneは、もともとオブジェクトストア内でSmalltalkオブジェクトで処理系を構築している
Smalltalk言語処理系の考え方を一歩進めて、本格的な分散OODB内にSmalltalk処理系を構築してしまった
他に例をみない処理系です。

0617デフォルトの名無しさん

2016/09/17(土) 11:44:18.02ID:Skwtkpj9

未だに例を見ないってことは
システム自体に大きな価値はなかったってことかな。

0618デフォルトの名無しさん

2016/09/17(土) 12:26:38.02ID:wV2Unwpb

クライアント中心の処理に変更になったなら
むしろクライアント側の重要性は増してるだろ

0619デフォルトの名無しさん

2016/09/17(土) 13:42:31.91ID:21nLXeLP

>>617
Smalltalk以外の言語だといろいろ難しいのでしょうね

0620デフォルトの名無しさん

2016/09/17(土) 13:46:57.97ID:5r5hyKhZ

その理屈だとSmalltalkのシステムがたくさんあるはずだが、
無いってことは、そもそもSmalltalkを使って
システム構築するのが難しいんでしょうねｗ
Smalltalkだから素晴らしいっていうシステムもないし。

0621デフォルトの名無しさん

2016/09/17(土) 13:49:34.50ID:21nLXeLP

>>618
重要度はどうあれ
Smalltalkでやる旨み（GemStone）がなくなれば
他のどの言語でも、まあメジャーな言語ならやれることはそう大差ないでしょう

0622デフォルトの名無しさん

2016/09/17(土) 13:50:47.66ID:21nLXeLP

>>620
無いんじゃなくて知られていないだけでは？

0623デフォルトの名無しさん

2016/09/17(土) 14:03:06.19ID:5r5hyKhZ

何で作られているか知られてない物なら
他の言語のほうがもっと多くあるだろうよｗ

0624デフォルトの名無しさん

2016/09/17(土) 14:08:03.05ID:21nLXeLP

そうですね
だからシェアなんて曖昧なものだし
さらにいえばよいものならシャアをとれるって単純な話でもないですよね

0625デフォルトの名無しさん

2016/09/17(土) 14:24:25.29ID:5r5hyKhZ

>>624
そんなこと一言も言ってないよｗ

公になるのは、ほんの一部だって言ってるだけ。
そのほんの一部（どの言語も公開されてるのはほんの一部）を
比べてみれば、公開されてない量も分る。

それにシェアの話はしてない。今の話は
より良いシステムを作るのに何を選ぶかってことだよ。
Smalltalkは選ばれなかったって話をしてる。

0626デフォルトの名無しさん

2016/09/17(土) 14:39:50.95ID:p4/FdeTB

>>625
より良いシステム作るためってより、ベンダーが使いこなせる(人を集めることができる)言語で作ったよってことだろ。
web案件でPHPが多いのだってそれ。
PHP自体は他と比べてより良い言語ってわけじゃない。

0627デフォルトの名無しさん

2016/09/17(土) 14:50:50.90ID:5r5hyKhZ

>>626
要件が同じ時、言語を変えただけで
違うものができるとでも思ってるの？

「より良いシステム」は何だと思う？

0628デフォルトの名無しさん

2016/09/17(土) 15:04:16.33ID:VbfmfVd0

>>627
言語は品質やメンテナンス性に大きく関係するよ
さすがにどの言語でも同じレベルのものが作れるなんて、プログラマなら誰も思ってないだろうね
手配師や経営層ならそう思ってるのかもしれんが

0629デフォルトの名無しさん

2016/09/17(土) 15:06:43.07ID:5r5hyKhZ

> 言語は品質やメンテナンス性に大きく関係するよ

少しは関係するが、大きく関係することはない。

例えば、品質やメンテナンス性が低いコードを書いている人が
Smalltalk（その他でも良い）を使っただけで、
品質もメンテナンス性もばっちり！ってなるのであれば、
その人が書いたコードを見てみたいもんだよｗ

0630デフォルトの名無しさん

2016/09/17(土) 15:07:46.44ID:5r5hyKhZ

逆にSmalltalk（その他でも良い）で品質やメンテナンス性が高いコードを書いている人が
PHP（？）を使っただけで、品質やメンテナンス性が大きく下がるのであれば面白い話だ。

0631デフォルトの名無しさん

2016/09/17(土) 15:13:26.96ID:VbfmfVd0

>>630
同じスケジュール・コストで比較した場合という前提のもとでは、言語によってかなりの
差が出るのは事実だよね
より良いシステムというからにはこの前提は必須だろうし

0632デフォルトの名無しさん

2016/09/17(土) 15:16:16.10ID:5r5hyKhZ

> 同じスケジュール・コストで比較した場合という前提のもとでは、言語によってかなりの
> 差が出るのは事実だよね

そんな事実無いよｗ

言語よりも使うフレームワークやライブラリとその習熟度の方が重要。
言語の違いは作りやすくするためではあるが、作らなくて良くするわけじゃない。

フレームワークやライブラリを使えば作らなくて良くなるので、
作るコストが大きく下がる。

0633デフォルトの名無しさん

2016/09/17(土) 15:19:52.80ID:VbfmfVd0

>>632
えー、Whitespace や BrainF*ck とか使って品質を担保できる自信はないなぁｗ

という極論はおいとくとしても、たとえばある程度の規模のシステムにおいて C++ で
メモリリークと戦う自信はおありなんでしょうね
いやースーパープログラマ様はすごいですねー

0634デフォルトの名無しさん

2016/09/17(土) 15:19:53.82ID:wV2Unwpb

>>631
＞>>630
＞同じスケジュール・コストで比較した場合という前提のもとでは、言語によってかなりの
＞差が出るのは事実だよね

その前提でSmalltalkはVBに負けちゃったって事？

0635デフォルトの名無しさん

2016/09/17(土) 15:41:14.61ID:5r5hyKhZ

>>633
> えー、Whitespace や BrainF*ck とか使って品質を担保できる自信はないなぁｗ
フレームワーク無いからねｗ

そういう生産性がわざと低くなるような言語の話はしてない。

選ばれない言語の生産性が悪いのは、
Smalltalkに限った話じゃないｗ

0636デフォルトの名無しさん

2016/09/17(土) 15:41:59.00ID:VbfmfVd0

>>635
C++ のくだりを無視すんなよｗ

0637デフォルトの名無しさん

2016/09/17(土) 15:43:25.71ID:5r5hyKhZ

>>636
C++でもフレームワークとライブラリを使えば
メモリリークの問題はほとんど解決できる。

0638デフォルトの名無しさん

2016/09/17(土) 15:45:11.66ID:VbfmfVd0

>>637
うわ…さては使ったことないな
スマートポインタだって万能じゃないことぐらい、ちょっと使えばすぐ分かることなのに…

0639デフォルトの名無しさん

2016/09/17(土) 16:02:15.59ID:5r5hyKhZ

万能だと言った覚えはないが？
同じスケジュール・コストで比較した際の差が大きく減るって言ってんの。
万能じゃなくても実用上の問題がほぼ解決すればそれで十分なんだよ。

0640デフォルトの名無しさん

2016/09/17(土) 16:07:02.44ID:VbfmfVd0

>>639
減ったところで戦いは残ってるよ
それは立派なコストだし、そのコストというハンデを背負ったままで他の言語と比較して同じ品質のものが
同じ期間で作れるわけないじゃん

C++はC++にしかなしえない領域があるから現役なんだし、そうじゃない領域のシステムにC++を投入した
としたらそこのPMは頭が悪いとしか言いようがない

どんな言語だって万能じゃないし、適切な分野がある
それを無視して「システムはどんな言語で作っても同じ」なんて暴言もいいところだわ

0641デフォルトの名無しさん

2016/09/17(土) 17:21:34.70ID:5r5hyKhZ

>>640
でもさ、あんたC＋＋はコストがかかるとしか言ってないよねｗ
そして問題はメモリリークだとしかいってない。

じゃあ、ガベコレがあるその他の言語では
どれを使ってもコストに大差はないってことで良さそうｗ

0642デフォルトの名無しさん

2016/09/17(土) 17:35:32.42ID:4/iIUGMP

言語に振り回されるほど愚かなことはない
それなら最初からJAVAを採用した方がマシだ

0643デフォルトの名無しさん

2016/09/17(土) 18:36:44.49ID:Hpn4CokY

どんな言語でもいいような処理ならSmalltalk以外の言語で書く気がしない

0644デフォルトの名無しさん

2016/09/17(土) 18:52:30.80ID:5r5hyKhZ

処理？単位が小さくね？

流石にアプリやサービスとまではいわないけどさ、
アプリやサービスに含まれる1機能ぐらいを
目安にしてほしいものだが。

0645デフォルトの名無しさん

2016/09/17(土) 18:52:57.31ID:VbfmfVd0

>>641
とりあえず「システムはどんな言語で作っても同じ」は嘘なんだから、まずはこれを訂正してもらわないとね
自分の誤りを認めることができない人間と議論してもしょうがないので

0646デフォルトの名無しさん

2016/09/17(土) 18:58:58.90ID:5r5hyKhZ

> 「システムはどんな言語で作っても同じ」
そんなことは俺は言ってない。

フレームワークやライブラリによるコスト削減の量に比べれば
言語の違いで開発コストに大きな差は出ないといった。

また、同じ人がコードを書いた時、言語によって品質や
メンテナンス性が大きく変わることもないとも言った。

俺の発言をすり替えるようなやつとは議論にならんなｗ

0647デフォルトの名無しさん

2016/09/17(土) 19:05:49.87ID:21nLXeLP

>>625
> そのほんの一部（どの言語も公開されてるのはほんの一部）を
> 比べてみれば、公開されてない量も分る。

公開されている一部が隠蔽されている全体のシェアをある程度反映しているというのは直感的に理解しがたいです。
統計的にはどんな根拠なのでしょうか？

0648デフォルトの名無しさん

2016/09/17(土) 19:07:03.91ID:VbfmfVd0

>>646
わかった。認める気はないんだね。じゃぁもういいや

0649デフォルトの名無しさん

2016/09/17(土) 19:20:34.23ID:5sHSpu6y

>>616
OODBまでいかずとも簡易オブジェクトストア内にセルフホスティングなOOPL処理系を作るって
そう難しいことじゃないと思うんだけど、なんでSmalltalk以外にできないのかな
やっぱり他言語のオブジェクトには荷が重いのか

0650デフォルトの名無しさん

2016/09/17(土) 19:21:28.30ID:5r5hyKhZ

>>647
統計学の説明はこんなもんでいいですかね？

http://www.albert2005.co.jp/technology/data/statistics.html
> 統計学とは、ある程度以上の数のバラツキのあるデータの性質を調べたり、
> 大きなデータ（母集団）から一部を抜き取って、その抜き取ったデータ（標本）の
> 性質を調べることで、元の大きなデータの性質を推測したりするための方法論を体系化したものです。

http://infolit.uec.tmu.ac.jp/2014/2a/02/index.html

0651デフォルトの名無しさん

2016/09/17(土) 19:24:55.88ID:/pdyt2fc

>>647
公開されてるものが全体のランダムサンプリングになってると仮定すればそうなる
むしろ、どの言語で書かれてるかで公開されやすさが違うと考える方が直感に反するけどな

0652デフォルトの名無しさん

2016/09/17(土) 19:25:52.19ID:5r5hyKhZ

>>648
> わかった。認める気はないんだね。じゃぁもういいや

無いよｗ

例えば、iOSとAndroid両対応のソフトを作る事を考える。

この場合、両対応のソフトが作れるフレームワークかどうかが重要。
そこで使われてる言語は二の次。

0653デフォルトの名無しさん

2016/09/17(土) 19:44:50.13ID:VbfmfVd0

願わくばこんな奴が誰かの上司にならないことを心から願う

0654デフォルトの名無しさん

2016/09/17(土) 20:04:00.10ID:21nLXeLP

>>650
651も指摘されていますが、公開されているものが全体からの無作為抽出であると
統計的にはどうやって担保されるのですか？

0655デフォルトの名無しさん

2016/09/17(土) 20:22:13.02ID:5r5hyKhZ

>>654
Smalltalkが使われてる事例が作為的に少なく報告されているというのなら、
作為的に多く事例を集めてもらってかまわないんだよw

無作為抽出以前に、作為的であってもSmalltalkの事例は集められない。

Smalltalkの事例が実はたくさんあるが、作為的に公開されてない可能性がある。
そしたら事例が集められなくても不思議じゃないということが成り立つが、
言語によって公開されやすさが違うわけがないだろうってことで
>>651は以下のように言ってるんだよ。

> むしろ、どの言語で書かれてるかで公開されやすさが違うと考える方が直感に反するけどな

0656デフォルトの名無しさん

2016/09/17(土) 20:48:24.09ID:BC0jMf6V

>>655
> 作為的であってもSmalltalkの事例は集められない。

もしかしてSmalltalkの事例が皆無とか思ってる？

あとこういう実際もある

> 実際にはSmalltalkならではの強みを活かしたシステム開発事例がしっかりと存在します。
> 守秘義務などで見えにくくなっているだけです。
http://www.smalltalk-users.jp/Home/gao-zhi/dai13kaismalltalkbenkyoukai

0657デフォルトの名無しさん

2016/09/17(土) 20:52:48.95ID:5r5hyKhZ

> もしかしてSmalltalkの事例が皆無とか思ってる？

あのさ、統計学の話なんだから、1件あるないとか
そういうレベルだと問題外なのよｗ

データを集められないのはデータが少ないのと一緒。

> 守秘義務などで見えにくくなっているだけです。
他の言語も条件は同じ。

そこでも「存在します」と言うふうに1件あるかないかのレベルで
話をしていて、多いとは言ってないんだよ。

開発事例は守秘義務に守られてるかもしれないが
求人事例なんかは守秘義務に守られてないからなｗ

0658デフォルトの名無しさん

2016/09/17(土) 21:56:42.27ID:BC0jMf6V

>>657
統計の話なんかしらんがな
ざっと読んだ感じあんたのは統計なんかじゃないってのはさておき
Smalltalkに事例や求人が皆無とか決めつけてるバカか
と思ったんで念のため確認してみただけ

0659デフォルトの名無しさん

2016/09/17(土) 22:01:37.51ID:Dxbs+KqA

>公になるのは、ほんの一部だって言ってるだけ。
>そのほんの一部（どの言語も公開されてるのはほんの一部）を
>比べてみれば、公開されてない量も分る。

1件じゃダメなら、何件挙げれば「公開されてない量も分る」んだろうか

0660デフォルトの名無しさん

2016/09/17(土) 22:05:58.64ID:5r5hyKhZ

>>658
皆無と決めつけてるのはお前じゃね？ｗ

俺は少ないと言ってるだけ。

0661デフォルトの名無しさん

2016/09/17(土) 22:07:00.90ID:5r5hyKhZ

>>659
適当に何件か上げて、その中からSmalltalkだった
割合を算出すればいいよ。

意図的にSmalltalkを探したとしても
数は少ないだろうけどねｗ

0662デフォルトの名無しさん

2016/09/17(土) 22:19:03.51ID:Dxbs+KqA

>>661
「1件あるないとかそういうレベルだと問題外」ってのと話が繋がらないが

0663デフォルトの名無しさん

2016/09/17(土) 22:20:07.84ID:BC0jMf6V

>>660
日本語不自由なの？
あんたの表現が皆無と決めつけているかのようにしか読めないから確認しただけだって
こう↓書いてるお前にそのつもりがないならここではまだ誰も皆無とは決めつけてなんかないよ

> 作為的であってもSmalltalkの事例は＊集められない＊

あと、統計処理に必要な条件、もっと勉強しようなｗ

0664デフォルトの名無しさん

2016/09/17(土) 22:25:39.56ID:5r5hyKhZ

>>662
言語関係なく事例を集めるってことだよｗ
その中でSmalltalkの事例がどれだけあるか。

作為的にSmalltalkの事例を集めるぐらいしない限り
それなりにあると言えるようなレベルにもならないだろうな。

0665デフォルトの名無しさん

2016/09/17(土) 22:26:16.01ID:5r5hyKhZ

>>663
> あと、統計処理に必要な条件、もっと勉強しようなｗ

いいんやで？その必要な条件を言ってもｗ

0666デフォルトの名無しさん

2016/09/17(土) 22:34:01.95ID:BC0jMf6V

>>664
> 作為的にSmalltalkの事例を集めるぐらいしない限り
> それなりにあると言えるようなレベルにもならないだろうな。

＊集められない＊からずいぶんトーンが変わったなｗ

あと、シェアの話はしてないんじゃなかったのか？
だったら極端な話、選ばれたのが１例でも「選ばれた」事例にはならんのか？

> より良いシステムを作るのに何を選ぶかってことだよ。
> Smalltalkは＊選ばれなかった＊って話をしてる。

それともやっぱりシェアの話をしているのか？

0667デフォルトの名無しさん

2016/09/17(土) 22:48:47.77ID:/pdyt2fc

集められない、の枕に「JavaやPHPやJavascriptと同じようには」ってのが付くと思うべきだろ
話の流れ的に

0668デフォルトの名無しさん

2016/09/17(土) 22:50:49.64ID:5r5hyKhZ

ん？集められないだろ？やってみていいんやで？ｗ

最初から今までずっとシェアの話はしてないが？
お前は選ばれないかどうかというシェアの話に固執しているようだが、

俺は選ばれないというのは事実であるという前提で、
それは技術的に優れてるわけじゃないから、
言語によって大差ないからだよって話をしてる。

何か言いたいことがあるなら、お前がその前提をひっくり返してみせれば良いんだよｗ

0669デフォルトの名無しさん

2016/09/17(土) 23:01:55.47ID:BC0jMf6V

>>668
なんか言ってることがよくわからんな

> 俺は選ばれないというのは事実であるという前提

で、なんで

> 言語によって大差ないからだよって話

になるんだ？

事実として、シェアにそくして多くはないが、断じて皆無ではない数、
Smalltalkは他の言語に求めにくい技術的優位性を理由に選ばれてるだろ？

0670デフォルトの名無しさん

2016/09/17(土) 23:26:46.69ID:WGFeqLSs

Smalltalkの採用が皆無じゃないからといって
技術的優位性を理由に選ばれてるとは限らないだろ
担当者が趣味で選んだだけかもしれない

大体、言語が技術的優位性を理由に選ばれるとしたら、
殆ど選ばれる事のないSmalltalkは他の言語よりも
大抵の問題領域で技術的に劣る事になるが、それで良いのか？

0671デフォルトの名無しさん

2016/09/17(土) 23:34:35.78ID:mscWw9Mu

該当の複数プログラミング言語を使いこなしてる奴なんて、人類の0.00001%にも満たないのに、
その中で「シェア」ｗを気にするって・・・随分狭い井戸の中に居る連中だな。

0672デフォルトの名無しさん

2016/09/17(土) 23:34:42.18ID:MeITF+Vl

やっぱJavaでいいや俺は

0673デフォルトの名無しさん

2016/09/17(土) 23:36:05.64ID:5r5hyKhZ

本当に言語程度で開発効率が上がるなら、もっと使われてるはずだろうね。
使われてないということは確定事項なんだ。
そこで争うつもりはない。

0674デフォルトの名無しさん

2016/09/17(土) 23:42:41.11ID:BC0jMf6V

>>670
> 殆ど選ばれる事のないSmalltalkは他の言語よりも
> 大抵の問題領域で技術的に劣る事になる

ならないよ？

お前は統計処理のお粗末さよろしく、ことごとく前提を間違うもんだから帰結も間違いだらけだな

0675デフォルトの名無しさん

2016/09/17(土) 23:47:01.97ID:WGFeqLSs

>>674
前提を飛ばして引用したのは何で？

> 大体、言語が技術的優位性を理由に選ばれるとしたら、

0676デフォルトの名無しさん

2016/09/17(土) 23:58:52.45ID:62bdm4cw

その影響度の大小に意見の相違はあれど、
Smalltalkが優れてるって前提で話が進んでるけど、
本当にそうだろうか？

0677デフォルトの名無しさん

2016/09/18(日) 00:17:40.45ID:8zKQ5/pX

>>676
そういうこと。

言語には特性というものはあるが、
やり方が少し違うって程度でどちらが優れてるかじゃない。
言語仕様程度で開発効率で差は生まれない。

今の開発っていうのは、どれだけ0から作り上げるかではなく
すでにあるものを使って、どれだけ少ない差分で作り上げられるかになってる。

どの言語もフレームワークやライブラリを整えることで、
システムを開発する必要なコードを最小化している。
裏方のコードに差はあれど、残りのコードはほんの僅かになってる。

そのせいで言語で左右される開発効率に殆ど差はなくなってしまってるんだよ。

0678デフォルトの名無しさん

2016/09/18(日) 00:23:29.68ID:v5zT4UNT

>>676
その立証も否定もなかなか難しいのでは？
たとえば、この企業はSmalltalkのプロトタイピングの容易さを優位性にあげているけど
https://thepedia.co/article/1068/

同じことを同程度のスキルを持つJavaやJS、Rubyといった言語の使い手でも可能かどうかを客観的に検証する手段が
事実上ないわけだし

0679デフォルトの名無しさん

2016/09/18(日) 00:30:00.38ID:7jfCU7SG

>>677
差は生まれるけど？
動的型付き言語はカッチリ作るのは得意ではないが、その分開発効率は高い
静的型付き言語は逆

典型的なのはJSONの扱いとかかな
大抵の言語にはJSONライブラリがあるが、静的型付きだと最初にJSONでどういうものを
扱うかをかっちり決めて、それにしたがってパースしていくのでちゃちゃっととりあえず
使いたいんじゃーって場面には合わない
動的型付きだとその辺はゆるくちゃちゃっとできるけど、JSONの構造の解釈は人間が
やるのでミスが出やすい

どっちがいいとかじゃなくて、適材適所
あるシステムを開発するときに、そのシステムの特性に合わせて言語は選ばれなければ
いけない
言語によって開発効率の差が生まれないとか言ってるのは実際に様々な言語で開発を
したことがないのでは？

0680デフォルトの名無しさん

2016/09/18(日) 01:02:13.04ID:8zKQ5/pX

> 動的型付き言語はカッチリ作るのは得意ではないが、その分開発効率は高い
> 静的型付き言語は逆

いや変わんない。
多分ほんの僅かなコードを書いて、その行数程度でみてるんだろうだけど、
アプリレベルの量になると、差がなくなる。

何故かと言うと、所詮コードの行数はタイプのスピードでしか無いから。
それ以上に人間が考えてる時間のほうが長い。

あと動的型付き言語だと最初に書く時は楽だが、修正する時は大変になる。
静的型付き言語は逆は最初に書くときは面倒だが、修正するときは楽になる。
使い捨て程度だと書いて終わりだろうけど、ある程度の量になると、
最初に書くのも修正するのも同じぐらいある。

だから結局開発効率に差はなくなる。

0681デフォルトの名無しさん

2016/09/18(日) 01:02:59.69ID:8zKQ5/pX

それから、フレームワークやライブラリを使うと、
そもそも書く必要性が大きく減る。
なので差も大きく減るわけ。

0682デフォルトの名無しさん

2016/09/18(日) 01:06:03.46ID:8zKQ5/pX

> あるシステムを開発するときに、そのシステムの特性に合わせて言語は選ばれなければ
> いけない

システムの特性に合わせるというか、その言語では出来ないことがある場合に
その言語は選択肢にならないことがあるだけだよ。開発効率とは無関係。

その言語で普通に作れるならば、どれを選んだところで大差はない。

0683デフォルトの名無しさん

2016/09/18(日) 01:29:08.06ID:7jfCU7SG

>>680
> 多分ほんの僅かなコードを書いて、その行数程度でみてるんだろうだけど
最初に全体の構造を把握する手間が必要かどうかだよ
静的型付きの場合は構造をすべて記述しておかないといけないので、全体を把握する手間が余計にかかる
これはコード量の問題ではない

修正についても、ちょっとした機能追加とかは動的型付きの方が速いことが多いね
これも全体を把握する必要のない動的型付きのメリットだね
もちろん、大規模なリファクタリングをやる場合などは静的型付きの方が有利だ
どういう規模の修正がどういう頻度で発生するかもシステムの特性であり、それを無視した
言語選択などありえないよ

0684デフォルトの名無しさん

2016/09/18(日) 01:49:08.02ID:RMuqGHmf

ユニットテストかっちり書いてたら動的言語の方がちょっとした機能追加でも早いなんてこと無いと思うけど。

0685デフォルトの名無しさん

2016/09/18(日) 01:54:06.07ID:8zKQ5/pX

> 静的型付きの場合は構造をすべて記述しておかないといけないので、全体を把握する手間が余計にかかる

何を言ってるんだろうか？
動的型付けの場合でも構造が無いわけじゃないぞ。
ソースコードを見れば構造はわかる。

構造が変わればソースコードも正しく動かなくなる。
ソースコードが正しく動く構造は一つしか無い。

静的型付きの場合は構造が動くドキュメントになってるってだけで
最初に準備すれば、あとはそれを参照することで、可読性が上がって
ソースを理解するスピードも早くなる。

0686デフォルトの名無しさん

2016/09/18(日) 01:55:33.92ID:8zKQ5/pX

> 修正についても、ちょっとした機能追加とかは動的型付きの方が速いことが多いね
> これも全体を把握する必要のない動的型付きのメリットだね

意味がわからんｗ
同じ機能の時、機能追加が動的のほうが早いなんて統計はない。
どちらが早いかはその場次第でまちまちだろうが、
どちらかに偏りはないよ。

全体を把握するなんて静的でもやらんし。

0687デフォルトの名無しさん

2016/09/18(日) 02:15:49.84ID:7jfCU7SG

>>684
どれだけカッチリ書くかを選べるのが特徴だね
選択肢が多いのはメリットにもなるしデメリットにもなるけど、そこはシステムの特性で
取捨選択することになるね

>>685
> 最初に準備すれば
これが面倒なんだよね
だからこそその面倒さと後から得られるメリットを比較して言語を選ぶことになるわけだね

0688デフォルトの名無しさん

2016/09/18(日) 03:17:25.23ID:8zKQ5/pX

面倒かどうかと開発効率に関係はないよｗ
最初に面倒なことをやればあとで楽になるんだから。

0689デフォルトの名無しさん

2016/09/18(日) 03:18:58.18ID:8zKQ5/pX

> 選択肢が多いのはメリットにもなるしデメリットにもなるけど、そこはシステムの特性で
> 取捨選択することになるね

システムの特性で取捨選択するのと開発効率も関係はないよｗ
さっきも言ったように選べない言語であれば、捨てるしか無い。
選べる言語であればどれも大差ない。

0690デフォルトの名無しさん

2016/09/18(日) 03:23:30.50ID:7jfCU7SG

>>688
めちゃくちゃあるよ
あとで、ってのがどれぐらいの規模でどれぐらいの頻度で来るかはシステムによるんだから

>>689
動的型付けの場合はテストをゆるくすることも可能ってことだよ
ゆるくすることが許されないシステムなら静的型付けを選んだ方が無難だってことだね
どんなシステムでも求められる品質が同じとでも思ってるんでしょうかね？

0691デフォルトの名無しさん

2016/09/18(日) 10:40:08.32ID:RMuqGHmf

ユニットテストについてはコンパイラがチェックしてくれる静的型言語の方が少なくて済むぞ。

0692デフォルトの名無しさん

2016/09/18(日) 11:26:12.51ID:dUQjUJ6E

経験上、チーム内で最もスキルの高い人間が
詳しく知ってる言語を使うのが
もっとも失敗が少ない
それがPHPであっても

0693デフォルトの名無しさん

2016/09/18(日) 11:36:59.19ID:LHERV0LA

JavaとSmalltalkとで同じお題のTDDにかかる時間を比較すると1.5～２倍の差が出るらしい
https://youtu.be/RLAZjiK4UHc
https://youtu.be/wXW9WN9ay2E

0694デフォルトの名無しさん

2016/09/18(日) 11:37:01.49ID:8zKQ5/pX

>>691
一部分だけを見ればどちらかが効率いいようにみえるけど
プロジェクト全体を見れば大差ないんだよね。

>>692
その通りなんだよね。言語によって大きな差は生まれないから
あとは慣れてる言語のほうが良い。

0695デフォルトの名無しさん

2016/09/18(日) 11:37:45.02ID:8zKQ5/pX

>>690
> 動的型付けの場合はテストをゆるくすることも可能ってことだよ

一例を言ってみて。
動的型付けの場合でゆるくできるテストなんて思いつかない。

0696デフォルトの名無しさん

2016/09/18(日) 11:39:58.82ID:8zKQ5/pX

>>693
> JavaとSmalltalkとで同じお題のTDDにかかる時間を比較すると1.5～２倍の差が出るらしい
うん。俺が言ってるのはプロジェクト全体の話。

あちらを立てればこちらが立たずってことで、
TDDに差が出たとしても他のところで逆の差が出たりするし
そもそもフレームワークやライブラリを使ったときの差に比べれば
僅かな差しかでない。

0697デフォルトの名無しさん

2016/09/18(日) 11:58:14.40ID:7jfCU7SG

>>691
動的型付けでもユニットテストで型をチェックしなければいけないわけではないよ
システムの要求品質によっては静的型付けと同じ程度のユニットテストで済ませてしまって
開発効率を確保するという選択肢があるよ

>>695
入力パターンで想定外の型のデータを突っ込む部分だね
動的型付けならありえる話なのでカッチリやるならチェックしなきゃいけないんだけど
ゆるくやるなら放っておけばいい

0698デフォルトの名無しさん

2016/09/18(日) 12:26:36.42ID:8zKQ5/pX

>>697
> 動的型付けならありえる話なのでカッチリやるならチェックしなきゃいけないんだけど
> ゆるくやるなら放っておけばいい

いまテストをゆるくするって話をしていたよね？

静的型付けなら決まった型しか入ってこないからテストを最初からゆるい状態。

でも動的型付けなら想定外の型も入ってくる可能性があるから本来は
そのテストをかないといけない（動的型付けは大変）
でも手抜きしてゆるく（静的型付けと同じ状態）にすることもできる。

って話をしてるわけ？

0699デフォルトの名無しさん

2016/09/18(日) 12:28:54.06ID:7jfCU7SG

>>698
誤字もあるし何言いたいのかよく分からない

0700デフォルトの名無しさん

2016/09/18(日) 12:31:16.62ID:8zKQ5/pX

>>699
動的型付けの場合はテストをゆるくすることも可能っていうから、

静的型付けよりも楽になるのかと思えば、
動的型付けは型チェックを省ける程度の意味だったのかよって話。
静的型付けではもともと型チェックをしていない。

0701デフォルトの名無しさん

2016/09/18(日) 12:32:35.13ID:7jfCU7SG

>>700
その分、本体コードの開発効率の高さをそのまま享受できるでしょ？

0702デフォルトの名無しさん

2016/09/18(日) 12:37:59.38ID:8zKQ5/pX

>>701
なんで動的だと本体コードの開発効率が高いって前提になってるんだよｗ
単にタイプが楽なだけだろ。プロジェクト全体を通すと変わらんわ。

なぜ変わらんかというと、開発っていうのはコードを書くだけじゃない。
むしろ書くよりも読むほうが多い。そのときに情報は多いほうが読みやすい。
動的でもコメントを書くことで読みやすくできるが間違いがある可能性もある。

コメントではなくコンパイラがチェックすることで、信頼できる矛盾のない情報を
コードとともに記述できるのが静的型付け言語。

動的型付けは、書くのが楽だが読むのが大変。
静的型付けは、書くのが面倒だが読むのは楽。

この違いがあるだけで、プロジェクト全体を通すと相殺されて大差ない。
ちなみにここまでテストの話は含めてない。本体コードの開発効率の話。

0703デフォルトの名無しさん

2016/09/18(日) 12:42:59.50ID:7jfCU7SG

>>702
> 単にタイプが楽なだけだろ
なわけないでしょｗ

複数の型を受け取るメソッドを用意したいんだけど、そのためにはこういうインタフェースを用意して…
とか考える部分がないとでも？

こういうことを平気で言い出す人間はコードを組んだことがない、よくある「俺は技術知ってるPMだぜ」
レベルじゃないかと本気で疑わざるをえない

0704デフォルトの名無しさん

2016/09/18(日) 12:52:03.01ID:8zKQ5/pX

> 複数の型を受け取るメソッドを用意したいんだけど、そのためにはこういうインタフェースを用意して…
> とか考える部分がないとでも？

動的型付けならインターフェースを考えなくていいとでも？

複数の型を受け取るメソッドが有ったとして、それは何の型を受け取ることができる？
その型には特定のメソッドがなければいけないだろ？
じゃあその「なければいけないメソッド」という情報はどこに書いてある？
ソースコード読んで判断しろと？どうせコメント書くだろ。

矛盾を検出できないコメントで書くか、
コメントの代わりにインターフェースとして書くかの違いでしか無い。

0705デフォルトの名無しさん

2016/09/18(日) 13:04:43.74ID:7jfCU7SG

>>704
この引数にはこういうメソッドがいるんだけど、別の場所ではこのメソッドは必須ではないな
ということはインタフェースを分割して…でもさらに別のメソッドでは…うまく直交性を保つには…
でもインタフェース地獄にはしたくないし…

静的型付けあるあるですね

もちろん、こういうのを設計段階でカッチリやれればそれは堅牢性につながるから、メリットとも
言えるけどね
設計をカッチリやるようなシステムでは静的型付けの方が合うだろうね

0706デフォルトの名無しさん

2016/09/18(日) 13:09:49.73ID:8zKQ5/pX

> この引数にはこういうメソッドがいるんだけど、別の場所ではこのメソッドは必須ではないな
そうすると動的型付けだとますます、なにが必要なメソッドで
何が必要ないメソッドなのかわからなくなるんだけど？
コードを読めばわかるって？面倒だな。

そしてコードを読んだ範囲でこのメソッドはいらないなと思って
書かなかったら、別の場所で必要だったとかなｗ

> ということはインタフェースを分割して…
する必要はない。一つで十分。

だって別の場所ではこのメソッドは必須じゃないんだろ？
ならメソッドの中身を空にすればいいだけじゃないかｗ
アサーションでも入れておけば、Not implementedって出すようにできる。

ほらな、何も変わらない。

0707デフォルトの名無しさん

2016/09/18(日) 13:13:19.98ID:7jfCU7SG

>>706
> そうすると動的型付けだとますます、なにが必要なメソッドで
> 何が必要ないメソッドなのかわからなくなるんだけど？
そういう状態になりやすい大人数のチームには動的型付けは合わないだろうね
少数精鋭でみんながシステム全体をある程度分かってる感じじゃないとね

> アサーションでも入れておけば、Not implementedって出すようにできる。
それ、静的型付けのメリットを捨ててますよｗ

0708デフォルトの名無しさん

2016/09/18(日) 13:20:45.54ID:8zKQ5/pX

>>707
チームの話はしてないんだわ。
言語によって違いが出るかどうか。

言語によって違いはないから、慣れてる言語のほうが良いっていうのは
言い換えると、チームが慣れているほうが良いってことと同じで、
お前が言ったことは、俺が最初から言ってることなんだよ。

> それ、静的型付けのメリットを捨ててますよｗ
別に捨ててない。
静的型付けのメリットは信頼性があるコメントがあるかどうかだから。
重要なのは実装の方じゃなくて、インターフェースの情報。

動的型付けだとインターフェースの情報がコメントでしかないから
それが正しいかがソースコードと突き合せないとわからない。

静的型付けだと「インターフェースとしては必要でその実装がされてない」と
はっきり断定できるが、動的型付けだと必要なのかどうなのかさっぱりわからない。

0709デフォルトの名無しさん

2016/09/18(日) 13:22:48.00ID:8zKQ5/pX

> 少数精鋭でみんながシステム全体をある程度分かってる感じじゃないとね

よくいるよな。少数だと精鋭だって勘違いするやつｗｗｗ

少数精鋭っていうのは、大人数の中から精鋭の人をあつめて作るものであって、
最初から選択肢がない少人数の場合、それが精鋭になることなんてないからさ。

0710デフォルトの名無しさん

2016/09/18(日) 13:23:27.95ID:7jfCU7SG

>>708
> 静的型付けのメリットは信頼性があるコメントがあるかどうかだから。
その信頼性は「コンパイル時に発見できる」ことが重要でしょ？
アサーションなんか入れて「動かしてみないと分からない」じゃ動的型付けじゃん
むしろインタフェースを書かなきゃいけない分、動的型付け以下の使い方だよ

0711デフォルトの名無しさん

2016/09/18(日) 13:31:32.32ID:8zKQ5/pX

> その信頼性は「コンパイル時に発見できる」ことが重要でしょ

違う。ソースコードの可読性の話だから、
コンパイル前に、コード読んでわかるのが重要。

> アサーションなんか入れて「動かしてみないと分からない」じゃ動的型付けじゃん
コードに書いてあるんだから、コンパイルする前にわかる。

> むしろインタフェースを書かなきゃいけない分、動的型付け以下の使い方だよ
書かなくても動くから「動かしてみないとわからない」んだよｗ

0712デフォルトの名無しさん

2016/09/18(日) 13:38:08.60ID:7jfCU7SG

> コードに書いてあるんだから、コンパイルする前にわかる。
え？え？
信頼性って機械がコンパイル時にエラーを吐いてくれることで担保されるんだよね？
その信頼性を得るために多少の面倒を我慢しよう、ってのが静的型付けだよね？

0713デフォルトの名無しさん

2016/09/18(日) 13:45:46.82ID:8zKQ5/pX

> え？え？
> 信頼性って機械がコンパイル時にエラーを吐いてくれることで担保されるんだよね？

だから機械がコンパイル時にエラーを吐いてくれるから
人間は安心してソースコードを読むことができるんだよ。

お前、そこを勘違いしてるのかｗ

コンパイラは矛盾をチェックするだけ。
最終的にソースコードを読むのは人間だ。
だからソースコードの品質は保証されてないといけない。

静的型付け言語だと一定の品質であることが保証される。
動的型付け言語だとその保証がないからコードを読む時間が増える。
結果として開発効率に大きな差が無くなる。

0714デフォルトの名無しさん

2016/09/18(日) 13:50:03.27ID:7jfCU7SG

>>713
アサーションはそのコンパイルエラーを潰してしまうんですが？

0715デフォルトの名無しさん

2016/09/18(日) 13:54:02.88ID:8zKQ5/pX

>>714
> アサーションはそのコンパイルエラーを潰してしまうんですが？

コンパイルエラーを潰すから、
そこに書いてあるコードが正しいって証明されるんだろ。

コンパイラの言う正しいっていうのは、バグがないことじゃないぞｗ

書いてあるコードが正しい、つまり、そこにはインターフェースが存在していて
そのインターフェースの実装が無いと書いてあるコードが正しいってことだ。

動的型付けだと、何も書かないだろ？
つまり、ソースコードには本来必要なインターフェースがあることが見えない。
該当のコードを実行するか念入にコードを読まない限り、
インターフェースが実装されてないことがわからならない。

0716デフォルトの名無しさん

2016/09/18(日) 14:03:55.07ID:7jfCU7SG

>>715
> コンパイラの言う正しいっていうのは、バグがないことじゃないぞｗ
そのバグを可能な範囲でコンパイラで潰すのが静的型付けのメリットだよね？
アサーションはそのメリットを放棄してるよね？

0717デフォルトの名無しさん

2016/09/18(日) 14:06:02.36ID:8zKQ5/pX

>>716
え？バグ？

お前が最初に言った↓じゃんか。
> 別の場所ではこのメソッドは必須ではないな

必須でないメソッドを実装しないのはバグじゃないんだけど？ｗ
お前自分で言ったことを覆すわけ？

0718デフォルトの名無しさん

2016/09/18(日) 14:09:09.87ID:7jfCU7SG

>>717
No Implemented を実装したオブジェクトを、そのメソッドが実装されていることを要求しているメソッドに
渡したらエラーになるよね？
しかもこれは動かしてみないと分からない

0719デフォルトの名無しさん

2016/09/18(日) 14:11:25.42ID:8zKQ5/pX

動かさなくてもソースコードに書いてあるじゃんかｗ

もしかしてソースコードを読むってことしないのかな？
コードレビューとかしたこと無い？

書いてないものをコードレビューで読み取るのは大変だが、
書いてあるものをコードレビューで見つけるのは簡単。

0720デフォルトの名無しさん

2016/09/18(日) 14:13:24.11ID:7jfCU7SG

>>719
人間の信頼性より機械の信頼性の方が高いからコンパイラにエラーを見つけてもらうんでしょ？
そのためのコンパイルエラーでしょ？

0721デフォルトの名無しさん

2016/09/18(日) 14:21:23.82ID:8zKQ5/pX

>>720
お前何か色々勘違いしてるなｗ
何でもかんでもごっちゃにしすぎ。

コンパイラがやってくれるのはソースコードの矛盾を見つけることだけ。
ソースコードのバグを探してくれるわけじゃないんだよｗ

どっちみち人間がソースコードを読む必要がある。
人間がソースコードを読むという行為は、
静的であれ、動的であれ避けられない。

その読むべきソースコードの品質の高さが可読性につながる。
静的型付けであれば、ソースコードの品質が高くなる。
明らかな矛盾はコンパイラによって取り除かれるし、
書いてある型情報が正しいことも証明される。
だから安心してソースコードを読むことができる。

コンパイルしたらどんな問題でも見つけてくれる
コンパイラは完璧な道具だって思ってるのは、実はお前だよｗ

0722デフォルトの名無しさん

2016/09/18(日) 14:22:48.83ID:7jfCU7SG

>>721
その矛盾を見つけるのをコンパイラに任せるのが静的型付けのメリットでしょ？
アサーションはそのメリットを捨ててますけど？

0723デフォルトの名無しさん

2016/09/18(日) 14:24:36.24ID:8zKQ5/pX

> その矛盾を見つけるのをコ
> アサーションはそのメリットを捨ててますけど？
だからなんで？ｗ
矛盾って何さ。

0724デフォルトの名無しさん

2016/09/18(日) 14:27:14.25ID:7jfCU7SG

>>723
渡してはいけない型のオブジェクトを渡してしまってる、というバグだよ
静的型付けなら厳密なインタフェースを定義することでコンパイラがそれを見つけてくれる
アサーションはそのメリットを捨てている

0725デフォルトの名無しさん

2016/09/18(日) 14:31:01.67ID:8zKQ5/pX

> 渡してはいけない型のオブジェクトを渡してしまってる、というバグだよ

お前が矛盾してるｗ

今は渡してはいい型のオブジェクトを渡す前提の話をしていたはずだが？

0726デフォルトの名無しさん

2016/09/18(日) 14:33:39.29ID:8zKQ5/pX

じゃあお前の言うとおり、
渡してはいけない型のオブジェクトを渡たす場合の話をしようか？

ならば、そのオブジェクトにはインターフェースを持たせなければいいので
静的型付け言語であれば、コンパイルエラーになる。
なのでコンパイルできるコードであれば、そこに書いてあるソースコードを
人間が安心して読むことができる。

だけど動的型付け言語ではコンパイルエラーにならないので、
渡してはいけない型のオブジェクトかどうかをコードを良く読まないといけなくなる。

だから書くときは動的型付けの方が楽だろうけど、開発の全体（読むほうが多い）を見ると
開発効率に大きな差はなくなるという話。

0727デフォルトの名無しさん

2016/09/18(日) 14:34:27.35ID:7jfCU7SG

>>725
え？
そんな前提作ってたらバグなんて潰せないよ？

バグを可能な範囲で潰すのがコンパイラを使うメリットでしょ？

0728デフォルトの名無しさん

2016/09/18(日) 14:34:59.09ID:7jfCU7SG

>>726
> ならば、そのオブジェクトにはインターフェースを持たせなければいいので
> 静的型付け言語であれば、コンパイルエラーになる。
アサーション使ったらコンパイルエラーにならないよ？

0729デフォルトの名無しさん

2016/09/18(日) 14:41:34.49ID:8zKQ5/pX

>>728
だからアサーションを使うのは
お前が最初に出した前提、

そのメソッドはインターフェースには必要だが、
必ずしも呼ばれるわけじゃないから、必須じゃない場合だって

自分で出した前提すら忘れたのかよｗ
うん。馬鹿だねこいつ。
次どんな反論をしてくるか楽しみだわｗ

0730デフォルトの名無しさん

2016/09/18(日) 14:42:36.20ID:7jfCU7SG

>>729
つまり静的型付け言語ではカッチリしたインタフェース設計が必要ってことだね

0731デフォルトの名無しさん

2016/09/18(日) 14:42:48.43ID:8zKQ5/pX

>>727
> そんな前提作ってたらバグなんて潰せないよ？

やっぱいろいろごっちゃにしてるなｗ

どうせそう言うだろうから、静的型付け言語の
コンパイルチェックはバグを潰すためのもんじゃないって言ってるのに。

ソースコードの可読性、品質を上げるためのもの。

0732デフォルトの名無しさん

2016/09/18(日) 14:43:37.23ID:7jfCU7SG

>>731
バグを潰すことは品質を上げることと同義だと思うんですが？

0733デフォルトの名無しさん

2016/09/18(日) 14:43:47.20ID:8zKQ5/pX

>>730
> つまり静的型付け言語ではカッチリしたインタフェース設計が必要ってことだね

それは動的型付け言語でも一緒。

それをコメントで書くか（書かない場合はコードを読まなければいけなくなる）
コンパイルチェック可能なコードで書くかの違いでしか無い。

0734デフォルトの名無しさん

2016/09/18(日) 14:45:09.52ID:8zKQ5/pX

>>732
> バグを潰すことは品質を上げることと同義だと思うんですが？

だから、お前はいろいろごっちゃにしてるなって書いたんだよｗ

バグを潰すだけなら、どんなに可読性悪くてメンテナンス性が悪くても
大量に人と時間をかければできる。

それはソフトウェアの品質であって、
ソースコードの品質じゃない。この二つをごっちゃにするな。

0735デフォルトの名無しさん

2016/09/18(日) 14:45:32.14ID:dUQjUJ6E

インターフェイス分割が不要って主張の行き着く先は
全てのメソッドの型をもつ神インターフェイスなんだから、
神インターフェイスを使った時にコンパイルチェックが機能するか考えてみたら良い

0736デフォルトの名無しさん

2016/09/18(日) 14:46:30.52ID:8zKQ5/pX

>>735
0か1かという考え方はやめよう。

0737デフォルトの名無しさん

2016/09/18(日) 14:46:30.72ID:7jfCU7SG

>>733
一緒じゃないよ
動的型付け言語では必要じゃないメソッドは実装しなければいいだけ
もちろんそれはバグの原因になることもあるが、そのバグの確率とカッチリしたインタフェース設計の手間を
比較して設計の手間の方が大きいと思えば省くことができる

0738デフォルトの名無しさん

2016/09/18(日) 14:47:31.58ID:8zKQ5/pX

>>737
> 動的型付け言語では必要じゃないメソッドは実装しなければいいだけ

静的型付け言語では、必要じゃないメソッドは中身をからにすればいいだけ。

0739デフォルトの名無しさん

2016/09/18(日) 14:48:37.79ID:7jfCU7SG

>>738
それは静的型付けのメリットを捨ててますね
コンパイラにエラーを発見させるのが静的型付けのメリットなのに

0740デフォルトの名無しさん

2016/09/18(日) 14:49:12.63ID:8zKQ5/pX

>>739
その理屈で言えば、

静的型付け言語では中身が空だとコンパイルチェックが有効にはたらかない。

これは、大変だー、大変だー、大変だー

という大変な状態が、動的型付け言語の状態なわけでｗ

0741デフォルトの名無しさん

2016/09/18(日) 14:50:19.75ID:8zKQ5/pX

739 名前：デフォルトの名無しさん[sage] 投稿日：2016/09/18(日) 14:48:37.79 ID:7jfCU7SG [24/24]
740 自分：デフォルトの名無しさん[sage] 投稿日：2016/09/18(日) 14:49:12.63 ID:8zKQ5/pX [34/34]

ところで、たった35秒で>>740の内容を書ききれると思うかい？ｗ

0742デフォルトの名無しさん

2016/09/18(日) 14:50:32.72ID:7jfCU7SG

>>740
だったら静的型付け使う必要がないじゃん

0743デフォルトの名無しさん

2016/09/18(日) 14:52:14.83ID:dUQjUJ6E

普段は静的型のメリットを享受しつつ
not imprementedって書くだけで動的型のメリットも
享受できるなんて最高だな

って話をしてるのか？

0744デフォルトの名無しさん

2016/09/18(日) 14:54:31.82ID:8zKQ5/pX

>>742
動的型付け言語では、何も書かなくて大変な状態。

でも静的型付け言語では、中身が空というコードを書かないと
大変な状態にならない。

中身が空のコードが書いてあればコードを読んだときに疑問になるだろ？
空なのはコードの中身であって定義は存在する。
空のメソッドがあるという重要な情報が書いてあるから、そのことに気付けるんだよ。

何も書いていなければ気づくのが遅れるが、
書いてあれば気づけやすい。それが重要な所。

人間はソースコードを読む。読まなければいけない。
だから可読性が重要になる。

動的型付け言語はでは書く方を省略できるが、読む方は大変になる。
静的型付け言語ではその逆。

だからプロジェクト全体を見たときに、言語の違い程度で
開発効率で大きな差は出ないという話。

0745デフォルトの名無しさん

2016/09/18(日) 14:55:42.00ID:8zKQ5/pX

>>743
あるインターフェースが有って、そこにメソッドが複数定義されている時に
そのメソッドのうち一つを使わないだけで、
別のインターフェースを作らないといけないと思いこんでる
設計の素人がいるって話だよｗ

0746デフォルトの名無しさん

2016/09/18(日) 14:56:55.88ID:7jfCU7SG

>>744
> 中身が空のコードが書いてあればコードを読んだときに疑問になるだろ？
こういう人間頼みの頼りないバグチェックより機械による厳密なバグチェックをしようというのが静的型付けだよね？

0747デフォルトの名無しさん

2016/09/18(日) 14:58:43.24ID:8zKQ5/pX

>>746
静的型付け言語を知らんものが、お前の浅い知識で
静的型付け言語はこういう言語だって語るんじゃないよｗ

0748デフォルトの名無しさん

2016/09/18(日) 14:59:54.88ID:8zKQ5/pX

ったく、静的型付け言語を知らんやつほど
静的型付け言語はコンパイルするだけでバグを見つけてくれるものだって
銀の弾丸のように考えてるんだよなｗ

0749デフォルトの名無しさん

2016/09/18(日) 14:59:57.12ID:7jfCU7SG

>>747
静的型付けはコンパイラにエラーを検出させることによって、余計なバグの入り込む余地を減らすことを目標にしてるんだよね？

0750デフォルトの名無しさん

2016/09/18(日) 15:00:30.68ID:8zKQ5/pX

>>749
静的型付け言語が嫌いなくせに、
静的型型付け言語を過大評価するのはやめなさい。

0751デフォルトの名無しさん

2016/09/18(日) 15:01:27.05ID:7jfCU7SG

>>748
コンパイラが発見できるバグをアサーションとかで潰してしまうのは静的型付けのメリットを捨ててますよね？

0752デフォルトの名無しさん

2016/09/18(日) 15:02:37.85ID:7jfCU7SG

>>750
じゃあなんで静的型付け使うの？
アサーションとかいう回避策を使ってまで静的型付けを使うメリットはないと思うけど？

0753デフォルトの名無しさん

2016/09/18(日) 15:03:09.35ID:8zKQ5/pX

>>751
わざわざ手間なコードを書いてアサーションで潰されなければ
静的型付け言語のメリットは潰れないよｗ

つーか、静的型付け言語のメリットを潰した状態＝動的型付け言語のデフォルト
って言う時点でだめなんだわ。

0754デフォルトの名無しさん

2016/09/18(日) 15:03:44.01ID:7jfCU7SG

もちろん、カッチリしたインタフェース設計ができるのであれは、静的型付けを使うメリットは大いにあるよね
変なオブジェクトが渡ってくる心配はないわけだし

0755デフォルトの名無しさん

2016/09/18(日) 15:03:51.69ID:8zKQ5/pX

>>752
> じゃあなんで静的型付け使うの？

ソースコードのあちこちに型などの情報を書いて
可読性を上げるためだよ。

何度も言ってるじゃん。

ソースコードは書くよりも読むほうが多い。

0756デフォルトの名無しさん

2016/09/18(日) 15:04:57.54ID:8zKQ5/pX

>>754
> もちろん、カッチリしたインタフェース設計ができるのであれは

インターフェース設計は後からでも変えられるから
別にかっちりしたインターフェース設計をする必要はないんだよｗ

0757デフォルトの名無しさん

2016/09/18(日) 15:05:05.77ID:7jfCU7SG

>>753
メリットを潰した後に残るのはバグ発見の役に立たないインタフェースという負の遺産だよね
動的型付けならそんな負の遺産はないし、動的型付けのデフォルトではないよ

0758デフォルトの名無しさん

2016/09/18(日) 15:06:29.02ID:7jfCU7SG

>>755
可読性なんて動的型付けでもコメントで書けばいいだけじゃん
コンパイラのエラーをすり抜けるインタフェースなんてコメントと同レベルの意義しかないよ

0759デフォルトの名無しさん

2016/09/18(日) 15:08:10.00ID:8zKQ5/pX

>>757
> メリットを潰した後に残るのはバグ発見の役に立たないインタフェースという負の遺産だよね

動的型付け言語では、インターフェースが無いのにバグ発見の役に立つんですか？
やっぱり静的型付け言語でメリットをなくした場合＝動的型付け言語のデフォルトじゃないですかｗ

静的型付け言語でメリットをなくすためには、そのために通常は書く必要がない
変なコードを書かないといけない。これが「情報」なわけ。

こういう情報を書いておくことで、後からコードを読んだときに気付けることが多くなって
それが可読性の高さにつながる。

0760デフォルトの名無しさん

2016/09/18(日) 15:09:18.89ID:8zKQ5/pX

>>758
> 可読性なんて動的型付けでもコメントで書けばいいだけじゃん

コメントでは書くことを強制されないし、
間違っていてもチェックすることができない。

コンパイラのエラーをすり抜けるインタフェースなんてコメントと同レベルの意義しかないが、
コンパイラのエラーをすり抜けないインタフェースは、コメントよりも遥かに価値がある。

0761デフォルトの名無しさん

2016/09/18(日) 15:09:37.94ID:7jfCU7SG

>>759
> 動的型付け言語では、インターフェースが無いのにバグ発見の役に立つんですか？
> やっぱり静的型付け言語でメリットをなくした場合＝動的型付け言語のデフォルトじゃないですかｗ
同じ役にたたないものなら、書くより書かない方がいいでしょ

0762デフォルトの名無しさん

2016/09/18(日) 15:10:07.05ID:7jfCU7SG

>>760
> コンパイラのエラーをすり抜けないインタフェースは、コメントよりも遥かに価値がある。
うんうん、そのためにはカッチリしたインタフェースの設計が必要だね

0763デフォルトの名無しさん

2016/09/18(日) 15:11:22.08ID:8zKQ5/pX

> 同じ役にたたないものなら、書くより書かない方がいいでしょ
だから、役に立たつものを書いたほうが良いよねｗ

> > コンパイラのエラーをすり抜けないインタフェースは、コメントよりも遥かに価値がある。
> うんうん、そのためにはカッチリしたインタフェースの設計が必要だね

インタフェースの設計は後から変えればいいので、
かっちりしたインターフェースを設計する必要はないよ。

えーと、リファクタリングって言葉しってる？

0764デフォルトの名無しさん

2016/09/18(日) 15:13:26.27ID:7jfCU7SG

>>763
> だから、役に立たつものを書いたほうが良いよねｗ
そうそう、だからこそ静的型付けでは設計は大事なわけで

> インタフェースの設計は後から変えればいいので、
> かっちりしたインターフェースを設計する必要はないよ。
つまり最初はバグ持ちのまま出してもおっけーということで
それって動的型付けじゃん？

0765デフォルトの名無しさん

2016/09/18(日) 15:14:20.64ID:8zKQ5/pX

動的型付け言語であっても、インターフェースを変えるときは大変なんだよね。

どんな型でも入れられるのは、所詮引数であって、
ソースコードには、特定のメソッドがなければ動かないから。

どんな型でもっていうのは、片手落ちなんだわｗ
インターフェースを変えるとソースコードは修正しないといけない。

だから動的型付け言語でも、インターフェース設計は必要なんだよ。

そしてインターフェースの設計を変更する時は、
動的型付け言語よりも、静的型付け言語の方が楽。

こういった点からも、動的型付け言語は最初に書くときは楽だけど
コードを読んだりその後に修正のが大変になるから
結局開発効率に差はなくなるわけ。

0766デフォルトの名無しさん

2016/09/18(日) 15:15:20.78ID:8zKQ5/pX

>>764
こいつまだ静的型付け言語はバグをなくするものだって
考えてるぜｗｗｗ

静的型付け言語が嫌いなやつほど
静的型付け言語を過大評価してるね。

0767デフォルトの名無しさん

2016/09/18(日) 15:15:45.44ID:7jfCU7SG

>>765
> 動的型付け言語であっても、インターフェースを変えるときは大変なんだよね。
コロコロインタフェースが変わるようなら、最初の設計を疑った方がいいよ

0768デフォルトの名無しさん

2016/09/18(日) 15:16:18.32ID:8zKQ5/pX

>>767
はい。動的型付け言語ではカッチリしたインタフェースの設計が必要だね

0769デフォルトの名無しさん

2016/09/18(日) 15:16:42.08ID:7jfCU7SG

>>766
> こいつまだ静的型付け言語はバグをなくするものだって
動的型付けに由来するバグは潰せるでしょ？
アサーションはその潰せるバグをスルーしようっていう思想なわけで

0770デフォルトの名無しさん

2016/09/18(日) 15:17:34.76ID:8zKQ5/pX

>>769
だから必須じゃないメソッドを空にするのはバグじゃないってｗ

0771デフォルトの名無しさん

2016/09/18(日) 15:18:03.54ID:7jfCU7SG

>>770
そのメソッドを呼んだら落ちるんでしょ？
バグじゃん

0772デフォルトの名無しさん

2016/09/18(日) 15:19:14.42ID:8zKQ5/pX

>>771
え？このメソッド呼ぶの？
だったらちゃんと実装するべきでは？

0773デフォルトの名無しさん

2016/09/18(日) 15:19:58.97ID:7jfCU7SG

>>772
意図せずに呼んじゃったら？

0774デフォルトの名無しさん

2016/09/18(日) 15:20:33.00ID:8zKQ5/pX

動的型付け言語の場合、メソッドを書かない時、
そのメソッドをを呼んだらメソッドがないエラーで落ちるんだよ。
困ったねｗ

0775デフォルトの名無しさん

2016/09/18(日) 15:20:55.80ID:7jfCU7SG

>>774
アサーションも同じこと

0776デフォルトの名無しさん

2016/09/18(日) 15:21:04.05ID:8zKQ5/pX

>>773
動的型付け言語の話をすると、
メソッドがないときに、そのメソッドを呼んだら落ちますね。

0777デフォルトの名無しさん

2016/09/18(日) 15:21:28.52ID:7jfCU7SG

>>776
アサーションもね

0778デフォルトの名無しさん

2016/09/18(日) 15:22:01.62ID:8zKQ5/pX

>>7775
どちらも同じならば、何も書かないで
落ちるよりも書いて落ちたほうが、

ソースコードに、情報が残る後者のほうが
優れてるってことです。

コードレビューしたときに、違和感があるコードを
目にすることになりますからね。

0779デフォルトの名無しさん

2016/09/18(日) 15:23:32.96ID:7jfCU7SG

>>778
違和感なんて人間の感覚に頼るんだったら、動的型付けでも同じこと
静的型付けは機械で判断できるところにメリットがあるというのに

0780デフォルトの名無しさん

2016/09/18(日) 15:24:38.90ID:8zKQ5/pX

>>779
ソースコードは人間が読むんですよｗ

人間の感覚に頼らないでコードが書けるって
あんたどんだけ嫌いな静的型付け言語を
過大評価してるんですかｗｗｗ

0781デフォルトの名無しさん

2016/09/18(日) 15:31:15.56ID:7jfCU7SG

>>780
メソッドにどんなオブジェクトが渡るかをいちいち完全に精査するのはおそろしく大変なこと
これを人間の違和感だけでやりきるのはほぼ不可能

動的型付けはそこを決め打ちでやってしまう分、余計なことを考えなくてもいい
バグってるかもしれないけど、そんな確率は低いよねと判断できるならこういうやり方もアリ
アサーションも同レベル

静的型付けはそこを厳密にやってそんな余計なバグを減らそうという思想
その分カッチリとした設計は必要になるが、動的型付けでおきるバグの確率が許されないレベルなら
こっちを使うべき

システムの許容されるバグの範囲はシステムごとに違う
この大前提が理解できていない感じもあるな

0782デフォルトの名無しさん

2016/09/18(日) 15:35:20.58ID:8zKQ5/pX

>>781
> メソッドにどんなオブジェクトが渡るかをいちいち完全に精査するのはおそろしく大変なこと
> これを人間の違和感だけでやりきるのはほぼ不可能

話をすり替えんなクソが。

俺が言った違和感っていうのは、ソースコードに通常では書かないような
コードが有ると、それを見たときに、気付けるポイントになるってん話だ。
何もコードが書いてないと、気づきづらい。

気づくきっかけがあることが可読性につながるって話だ。

後の書き込みにレスはしない。お前が話を
すり替えようとする行為に付き合うつもりはない。

0783デフォルトの名無しさん

2016/09/18(日) 15:36:45.68ID:7jfCU7SG

>>782
> 俺が言った違和感っていうのは、ソースコードに通常では書かないようなコード
インタフェース設計が面倒なときはアサーションで逃げるんでしょ？
その逃げは違和感なの？普通にあることなの？

0784デフォルトの名無しさん

2016/09/18(日) 15:38:23.40ID:8zKQ5/pX

結局動的型付け言語では
ソースコードに型情報を含めた色んな情報を書かなくていいから
楽だと言っているが、その反面情報がないから読むときに大変になるということ。
静的型付け言語ではこの逆。

最初に書くときは動的型付け言語が良いようにみえるから
小さなサンプルでは動的型付け有利に見えるが、
実際のプロジェクトではその逆にすらなり得る。

だから言語の違いで開発効率に大きな差は出なくなるといってる。

0785デフォルトの名無しさん

2016/09/18(日) 15:40:37.06ID:7jfCU7SG

>>784
アサーション使ってたら同じことだと思うけど？

0786デフォルトの名無しさん

2016/09/18(日) 15:42:29.07ID:8zKQ5/pX

>>783
> インタフェース設計が面倒なときはアサーションで逃げるんでしょ？

まーた、俺が言ってないことを、俺が言ったことにして、話をすり替えようとする。

アサーションを使うっていうのは、お前が言った前提である、
必須じゃないメソッドをどうするかって話で、

お前は、必須じゃないメソッドが合ったら、
動的型付け言語だなら書かないでOK（でも呼ばれたら落ちる）
静的型付け言語ではどうするんだ？って聞かれたから、

必須じゃないメソッドだけ空にするか、呼ばれたらエラーにして落とせばいいだろ
って答えただけなんだが？

その上で、動的型付け言語だと必須じゃないメソッドを書いてないという情報が
ソースコードにないから、そのことに気づきづらい。
静的型付け言語だと必須じゃないメソッドでも空かアサーションのみのコードという
違和感のあるコードがあるから、そのことに気づきやすいという
可読性の話をしてる。

0787デフォルトの名無しさん

2016/09/18(日) 15:43:37.94ID:7jfCU7SG

>>786
でもアサーション使ってたらコンパイラがエラー見つけてくれないよ？
それだと静的型付け使ってるメリットないよね？

0788デフォルトの名無しさん

2016/09/18(日) 15:43:45.69ID:8zKQ5/pX

>>785
> アサーション使ってたら同じことだと思うけど？

ソースコードに必須じゃないコードがあることを
書いてあるかどうかという点が違う。

0789デフォルトの名無しさん

2016/09/18(日) 15:44:25.89ID:8zKQ5/pX

>>787
ソースコードに、コンパイルエラーにならないようにしている
コードが書いてあるという点が違う。

コードに書いてあるから、気づくことができる。

0790デフォルトの名無しさん

2016/09/18(日) 15:44:55.24ID:7jfCU7SG

>>788
それって人間頼みだよね？
コンパイラにエラー検出をお願いするのが静的型付けのメリットだよね？

0791デフォルトの名無しさん

2016/09/18(日) 15:45:16.89ID:7jfCU7SG

>>798
それって人間頼みだよね？
コンパイラにエラー検出をお願いするのが静的型付けのメリットだよね？

0792デフォルトの名無しさん

2016/09/18(日) 15:45:36.12ID:8zKQ5/pX

>>790
またお前は静的型付け言語が嫌いなくせに
静的型付け言語を過大評価してるなｗ

ソースコードは人間が読むもの。
だから可読性が重要になる。

0793デフォルトの名無しさん

2016/09/18(日) 15:47:03.61ID:7jfCU7SG

>>792
まともに設計すればコンパイラが見つけてくれるエラーを捨てるぐらいなら静的型付け使うメリットないよね？

0794デフォルトの名無しさん

2016/09/18(日) 15:51:25.03ID:8zKQ5/pX

>>793
言い返せなくなったからって、関係ない話に持っていこうとすんなｗ

ソースコードは人間が読むものだから可読性が重要になる。

静的型付け言語を使えば、型情報などの情報を書くことを強制される。
コンパイラがチェックしてくれる範囲において、
その情報に矛盾がないことが証明される。

安心してソースコードに書いてある情報を信用することができる。
それが可読性の高さにつながる。

動的型付け言語ではソースコードに型情報を含めた色んな情報を書かなくても動くから
楽だと言っているが、その反面情報がないから読むときに大変になるということ。
静的型付け言語ではこの逆。

だから言語の違いで開発効率に大きな差は出なくなるといってる。

0795デフォルトの名無しさん

2016/09/18(日) 15:52:13.30ID:7jfCU7SG

>>794
> コンパイラがチェックしてくれる範囲において、
アサーション使ったらコンパイラがチェックしてくれないじゃん

0796デフォルトの名無しさん

2016/09/18(日) 15:53:16.15ID:8zKQ5/pX

>>795
その話は結論出ただろ。
なんで結論出た話に戻そうとしてんの？ｗ

ソースコードに必須じゃないコードがあることを
書いてあるかどうかという点が違う。

0797デフォルトの名無しさん

2016/09/18(日) 15:54:09.42ID:7jfCU7SG

>>796
それはコンパイラがチェックしてくれないじゃん
どうせしてくれないなら余計な型情報を書く分、静的型付けの方が面倒が増えてるだけじゃん

0798デフォルトの名無しさん

2016/09/18(日) 15:56:08.96ID:8zKQ5/pX

>>797
だからなんで静的型付け言語嫌いなくせに
静的型付け言語を高い評価してるんだよｗ

静的型付け言語は、コンパイルチェックでバグが
ないことを証明してくれるもんじゃないんだぞｗ

コンパイルチェックでしてくれるのは、人間がソースコードを読んだ時に
そのソースコードに矛盾がないかどうかだけだ。

> どうせしてくれないなら余計な型情報を書く分、静的型付けの方が面倒が増えてるだけじゃん

だから最初から言ってるだろ。

動的型付け言語ではソースコードに型情報を含めた色んな情報を書かなくても動くから
楽だと言っているが、その反面情報がないから読むときに大変になるということ。
静的型付け言語ではこの逆。

だからプロジェクト全体を見れば、言語の違いで開発効率に大きな差は出なくなるといってる。

0799デフォルトの名無しさん

2016/09/18(日) 15:57:06.83ID:7jfCU7SG

>>798
コンパイラでできる範囲のチェックをするのが静的型付けでしょ？
アサーションはそのチェックをすりぬけてるじゃん

0800デフォルトの名無しさん

2016/09/18(日) 15:57:34.52ID:8zKQ5/pX

>>799
また結論が出た話に戻そうとしてるねｗ

0801デフォルトの名無しさん

2016/09/18(日) 15:59:07.91ID:7jfCU7SG

>>800
静的型付けのメリットとしてコンパイラによるチェックという信頼性の話をあげて置きながら、
アサーションの話になると「読めば分かるだろ」って人間のチェックにすりかえてるじゃん

0802デフォルトの名無しさん

2016/09/18(日) 16:01:09.36ID:8zKQ5/pX

コンパイルチェックというのはソースコードの矛盾がないことを
チェックするもので、バグがないことを証明するものじゃないと言ってるのに、
なんどもアサーションでチェックすり抜けてバグになるじゃんって言ってるんだよなｗ

重要なのは、アサーションでチェックすり抜けるというコードが
ちゃんと書いてあること（可読性につながる）だって言ってるのに、
理解能力がないｗ

0803デフォルトの名無しさん

2016/09/18(日) 16:04:17.09ID:8zKQ5/pX

>>801
だーかーらー、
いろんなもんをごっちゃにするな。
お前が言ってるのはバグが有るかどうかの信頼性だろ。

俺はソースコードに矛盾がなくて
安心して読めるかどうかの信頼性。

0804デフォルトの名無しさん

2016/09/18(日) 16:04:23.97ID:7jfCU7SG

>>802
そのアサーションを実装しているオブジェクトがメソッドに渡される可能性はチェックできないじゃん
インタフェースだけでオブジェクトを持ち回っててそのオブジェクトの実体は相当深く追わないと
分からないことが多いのに、それを「この実体はアサーションしてるから気づくでしょ」なんて
妄想もいいとこでしょ

0805デフォルトの名無しさん

2016/09/18(日) 16:04:58.57ID:7jfCU7SG

>>803
> 安心して読めるかどうかの信頼性。
コンパイラがチェックできないのにどこに信頼性を求めるんですか

0806デフォルトの名無しさん

2016/09/18(日) 16:07:24.11ID:8zKQ5/pX

>>804
> そのアサーションを実装しているオブジェクトがメソッドに渡される可能性はチェックできないじゃん

だーかーら、チェックできないと言ってるそれは
お前はバグをチェックできないって言ってるだろ。

静的型付け言語嫌いなくせに静的型付け言語は
すべてのバグをチェックできるなんて過大評価すんなや。
嫌いなくせになんで過大評価してるんだよ。

オブジェクトがメソッドに渡される可能性はコンパイラでチェックできなくていいんだよ。
アサーションを実装しているというコードが書いてあるんだから
人間がそれをみていろいろ気づくことができる。

ソースコードは書いてある通りに動くだけ。
バクかどうかは人間が判断するものなのに、
なんでお前は、「お・ま・え・は」　コンパイラがバグかどうか
判断してくれるって思ってんの？

0807デフォルトの名無しさん

2016/09/18(日) 16:08:58.13ID:8zKQ5/pX

>>805
> コンパイラがチェックできないのにどこに信頼性を求めるんですか

ソースコードに矛盾がないことの信頼性。
お前が言ってるのはソースコードにバグがないことに信頼性だが
俺は最初からコンパイルチェックでバグがなくなるなんて一言も言ってない。

ソースコードにいろんな情報が書いてあって、その情報が
正しいと安心して読めるという信頼性の話だ。

0808デフォルトの名無しさん

2016/09/18(日) 16:09:19.61ID:7jfCU7SG

>>806
> アサーションを実装しているというコードが書いてあるんだから
> 人間がそれをみていろいろ気づくことができる。
それは無理
インタフェースだけで持ち回るオブジェクトの実体を探し出してアサーションがあるかどうか
読むぐらいなら動的型付けでも同じこと

> ソースコードは書いてある通りに動くだけ。
> バクかどうかは人間が判断するものなのに、
だったら動的型付けでいいじゃん

0809デフォルトの名無しさん

2016/09/18(日) 16:09:52.97ID:8zKQ5/pX

> インタフェースだけで持ち回るオブジェクトの実体を探し出してアサーションがあるかどうか
> 読むぐらいなら動的型付けでも同じこと

同じことである根拠は？

どうせ言えないよねｗ

0810デフォルトの名無しさん

2016/09/18(日) 16:11:07.41ID:7jfCU7SG

>>807
> ソースコードに矛盾がないことの信頼性。
だったら動的型付けでいいじゃん
動的型付けでもシンタックスチェックはちゃんとやってくれるぞ

静的型付けのメリットはシンタックスチェック＋渡される型が問題ないことが保証されていることだ
それをアサーションで逃げるようでは、後者の保証なんて要らないと言ってるのと同じだからね

0811デフォルトの名無しさん

2016/09/18(日) 16:12:34.77ID:8zKQ5/pX

>>808
> だったら動的型付けでいいじゃん

同じ動的型付けでも、ソースコードにコメントが
書いてあるかどうかでソースコードの可読性は
大きく変わるって分かってないのか？

コメントと言ったが、本来はコメントは少なくて
ソースコード自身で表現できたほうが良い。

静的型付け言語であれば型情報などソースコードで表現できる幅が広いから
ソースコードに多くの情報を含めることができる。

動的型付けでは表現の幅が狭いから、コメントで書くしか無い。
だがコメントは信頼性が低い。

ソフトウェアの信頼性の話はしてないんだわ。
ソースコードに含まれるコメントの信頼性が低いって話をしてる。

0812デフォルトの名無しさん

2016/09/18(日) 16:13:20.80ID:8zKQ5/pX

>>810
> それをアサーションで逃げるようでは、後者の保証なんて要らないと言ってるのと同じだからね

何度も言ってるが「アサーションで逃げる」というコードが
書いて有ることが重要。

0813デフォルトの名無しさん

2016/09/18(日) 16:13:53.58ID:7jfCU7SG

>>809
インタフェースの実体を探し出すということはそのメソッドの呼び出し元を調べて、その呼び出し元から
さらに呼び出し元を調べて…という流れを追わなければいけない
こんな面倒なことをしたくないから静的型付けはコンパイラにエラーを吐かせるんだよね

0814デフォルトの名無しさん

2016/09/18(日) 16:15:07.82ID:7jfCU7SG

>>812
アサーションで逃げるコードに到達する可能性があるかどうかは、インタフェースだけでは分からない
結局実体を追わなければいけない
そうすると>>813に書いたような作業が必要になる

0815デフォルトの名無しさん

2016/09/18(日) 16:18:17.47ID:8zKQ5/pX

アサーションで逃げるコードに到達する可能性があるかどうかは～

と考えてる時点で「アサーションで逃げるコード」が
可能性を考える情報源になってるなｗ

そうやってコードレビューするんだよ。
何も書いてないと、そういう検討を見逃してしまう。

0816デフォルトの名無しさん

2016/09/18(日) 16:20:14.26ID:8zKQ5/pX

>>813
はい。そうやってコードに矛盾がないことが証明されますから
あとは人間がバグがないかを確認することに集中できます。

お前はどうせまた、バグがどうとかいいだすんだろうけど、
バグは人間が確認するもの。

そのためにソースコードを読むわけで、
ソースコードに矛盾がないことがチェックされるので
安心してソースコードを読んで人間がバグを見つけることができるのです。

またコンパイラを過大評価すんなよ？ｗ

0817デフォルトの名無しさん

2016/09/18(日) 16:23:33.71ID:7jfCU7SG

>>815
インタフェースで渡ってきたオブジェクトに対して、そのインタフェースを実装しているクラスすべてに対して
アサーションチェックがあるかどうかを見て、渡されたオブジェクトの実体がアサーションを実装しているクラスか
どうかを調べるために呼び出し元をどんどん遡って調べて…

アホか
こんなコードレビューなんてできるわけないだろｗ
そんなレビューするぐらいのコストを出せるならまともに設計するわｗ

0818デフォルトの名無しさん

2016/09/18(日) 16:25:06.68ID:8zKQ5/pX

>>817
あの、まともな設計するわって、
その、クソな設計を考えたのはお前ですが？

なに自分のクソな設計に
自分で文句言ってるんですか？

0819デフォルトの名無しさん

2016/09/18(日) 16:26:38.42ID:7jfCU7SG

>>818
アサーションチェックで違和感を感じてコードレビューでバグを見つけろって言ったのはあなたですが？

0820デフォルトの名無しさん

2016/09/18(日) 16:28:09.47ID:8zKQ5/pX

>>819
えーと、だから動的型付け言語では違和感がないからバグを
スルーしてしまうってことですよね？

バグをスルーしたらだめでしょｗ．

0821デフォルトの名無しさん

2016/09/18(日) 16:30:28.50ID:7jfCU7SG

>>820
それが許容できる範囲かどうかはシステムによって違うんだよ
「バグならなんでも許せない！」なんておこちゃまな考えはこの業界ではとーっくに淘汰されてるんですよ

やはり静的型付けを使うようなガッチガチのシステムにどっぷり漬かってしまって
こういうバグコントロールの概念がない人でしたか

0822デフォルトの名無しさん

2016/09/18(日) 16:30:46.60ID:8zKQ5/pX

呼び出し元をどんどん遡って調べて…じゃないと
バグが見つけられないというクソ設計は
動的型付け言語を使っても同じことなんですがね。

0823デフォルトの名無しさん

2016/09/18(日) 16:31:29.86ID:7jfCU7SG

>>822
そうですよ？
その代わり決め打ちで開発できて余計なインタフェースを書かなくていいので開発効率が高いのです

0824デフォルトの名無しさん

2016/09/18(日) 16:31:48.83ID:8zKQ5/pX

>>821
自分で何を言ってるかわかってるのか？

バグが許せるというのなら、静的型付け言語でも
コードレビューしなければいいだけじゃんかｗ

0825デフォルトの名無しさん

2016/09/18(日) 16:32:50.70ID:7jfCU7SG

>>824
だったら余計なインタフェースを書かない動的型付けの方が開発効率は高いですね

0826デフォルトの名無しさん

2016/09/18(日) 16:34:39.51ID:8zKQ5/pX

>>823
> その代わり決め打ちで開発できて余計なインタフェースを書かなくていいので開発効率が高いのです

やっぱり、書かないでいいだけって言ってるだろｗ
お前、どれだけタイプ速度遅いんだよｗ

タイプ速度を計算すればわかるだろうが、インターフェースをタイプするのに
かかる時間なんて数分程度だよ。プロジェクト内にインターフェースは何個ある？
そんなに数無いだろ。その程度で開発効率が高いといわれてもなｗ

インターフェースを書かない代わりに、インターフェースの情報を調べようとすると
時間がかかる。プロジェクト全体を見れば書くよりも読む時間のほうが長い。

だから

動的型付け言語ではソースコードに型情報を含めた色んな情報を書かなくても動くから
楽だと言っているが、その反面情報がないから読むときに大変になるということ。
静的型付け言語ではこの逆。

だからプロジェクト全体を見れば、言語の違いで開発効率に大きな差は出なくなるといってる。

0827デフォルトの名無しさん

2016/09/18(日) 16:39:26.78ID:7jfCU7SG

>>826
> プロジェクト内にインターフェースは何個ある？
> そんなに数無いだろ。

ええ…普通に開発してたらちょっとしたシステムでも数十個のインタフェースができあがるんですが…
Java とかだと DI の仕組みもふんだんに使うしね…

0828デフォルトの名無しさん

2016/09/18(日) 16:46:02.16ID:8zKQ5/pX

数十個のインタフェースってことは
数十個×2倍以上のクラスがあるってことだよな？
動的型付け言語でもそれは同じなはずだ。

まずここまでは良いか？

0829デフォルトの名無しさん

2016/09/18(日) 16:49:25.08ID:7jfCU7SG

>>828
> 数十個のインタフェースってことは
> 数十個×2倍以上のクラスがあるってことだよな？

いやそれは違うな
クラスによっては複数のインタフェースを持つこともあるし

まぁ、俺は Java 使うときはしっかり設計してからやるから、アサーション使って動的言語のような
組み方したことないからかもしれんが
（そんな組み方するぐらいなら動的言語使いましょうって言うしなｗ）

0830デフォルトの名無しさん

2016/09/18(日) 16:50:49.49ID:8zKQ5/pX

>>829
ほうほう（苦笑）

じゃあ、その複数のインターフェースがあるクラスがあるとして、
そのクラスがどのインターフェースを持っているかは
どうやって判断するんだ？

0831デフォルトの名無しさん

2016/09/18(日) 16:51:41.27ID:7jfCU7SG

>>830
え？クラス宣言を見るけど？

0832デフォルトの名無しさん

2016/09/18(日) 16:52:24.39ID:8zKQ5/pX

>>831
動的型付け言語の話でいいよね？

0833デフォルトの名無しさん

2016/09/18(日) 16:55:22.93ID:8zKQ5/pX

インターフェースを書かなくていいと言った割に、
クラス宣言を見ればわかる。（そこにインターフェース名が書いてあるということ）

という言葉からもわかるように、
動的型付け言語でも、インターフェースを書くわけだよｗ

0834デフォルトの名無しさん

2016/09/18(日) 16:58:38.99ID:7jfCU7SG

>>831
動的型付けの場合は考え方を変えるよ

あー、なんとなく噛み合わない原因が分かってきたかも
静的型付けの考え方で動的型付けで開発したらそりゃ効率も落ちるわ

お互いで開発するときの考え方が違うんだよ
片方にどっぷり漬かってしまって同じ考え方でもう片方の言語を使うと
効率はそりゃ落ちるわ

昨今で言うと、関数型言語とかまるで考え方が違うしな
関数型言語をオブジェクト指向脳の人間を作ろうとしても全然だめだろ？
あれと同じで静的型付き脳の人間が動的型付き言語を使っても意味ないんだよ

だから俺は使う言語によって脳を切り替えるようにしてる
そりゃ静的型付き脳の人間からみれば動的型付き言語なんて効率悪そうに見えるわ
考え方がまったく違うんだから

0835デフォルトの名無しさん

2016/09/18(日) 17:12:44.81ID:8zKQ5/pX

静的型付けと動的型付けで考え方が違うんだよと言うくせに
その長文に、何が違うかを書いて無くてワロタｗ

0836デフォルトの名無しさん

2016/09/18(日) 17:15:48.44ID:7jfCU7SG

>>834
これは一言で説明できるもんでもないしな
両方使ってて勘でつかむもんだから

君も動的型付き言語で開発してみるといいよ
何度かハマったりして乗り越えたりして、ある日突然「あー、こういうことなのね」って瞬間が来るから

あと、関数型言語も面白いよ
するすると関数を繋げられたときの快感はまさに至福

0837デフォルトの名無しさん

2016/09/18(日) 17:20:34.88ID:8zKQ5/pX

>>836
はぁ？動的型付け言語を使っていて言ってるんだけど？ｗ

最初からずーっと言ってるよね？

動的型付け言語ではソースコードに型情報を含めた色んな情報を書かなくても動くから
楽だと言っているが、その反面情報がないから読むときに大変になるということ。
静的型付け言語ではこの逆。
だからプロジェクト全体を見れば、言語の違いで開発効率に大きな差は出なくなるといってる。

俺は最初からどちらが有利とも言ってない。言語程度で開発速度に差がないと言ってる。
フレームワークやライブラリによる開発速度の違いからみれば
限定程度の差なんて考えるに値しない。

0838デフォルトの名無しさん

2016/09/18(日) 17:22:38.98ID:8zKQ5/pX

× 限定程度の差なんて考えるに値しない。
○ 言語程度の差なんて考えるに値しない。

0839デフォルトの名無しさん

2016/09/18(日) 17:23:01.98ID:7jfCU7SG

>>837
ちゃんと脳を切り替えてる？
片方の脳で解釈している限り、もう片方の脳は理解できないよ？

関数型とか使ってみた？
あれをやると脳の切り替えがいかに重要かが分かるよ

0840デフォルトの名無しさん

2016/09/18(日) 17:23:34.92ID:8zKQ5/pX

>>839
めんどくせーやつだな。
お前よりもうまくつかている。

0841デフォルトの名無しさん

2016/09/18(日) 17:24:44.75ID:8zKQ5/pX

つーかそもそも脳を切り替えてるからこそ、
大差ねーなって結論になってるんだがｗ

0842デフォルトの名無しさん

2016/09/18(日) 17:25:13.40ID:7jfCU7SG

>>840
うまく使ってるなら動的型付きのフリーダムな世界は実感できてるはずだけどなー
静的言語脳の縛りが開発速度を落としてるんだろうねー

0843デフォルトの名無しさん

2016/09/18(日) 17:29:52.64ID:7jfCU7SG

>>841
静的型付き脳の俺からすると、きっちりした設計、整然とした開発、こういう場面での静的型付き言語は安心感に
溢れてるねー
やっぱちゃんと設計できてると楽だわーと感じる

動的型付き脳の俺からすると、スピード命、バグは後から修正しましょうって世界だと動的型付き言語はプロだね
頭の中だけで設計してそれをするするとコードに出せる快感は静的型付き言語にはないねー

システム開発の特性でこういう切り替えができると楽だよー
上司がクソで逆パターンにハマったら最悪だけど…

0844デフォルトの名無しさん

2016/09/18(日) 17:33:42.44ID:8zKQ5/pX

>>842
フリーダムと開発効率は違う問題だってことだよ。

小さなサンプル程度では違いが出るが
プロジェクトと呼べる程度の大きなものを作るとなると話は別

フリーダムだけど、フリーダムなことはあまり必要ないし、
なんでもできるよりか、制限があったほうがメンテナンス性が上がることも多い。
というか、言語の構文っていうのは最初はなんでもできる状態から
ある処理専用に特化することで、メンテナンス性を上げてきてるんだが。

それからフレームワークやライブラリによる開発効率の影響は
言語のそれよりも遥かに高い。

0845デフォルトの名無しさん

2016/09/18(日) 17:34:18.87ID:+iC0HZAY

なめ腐りミステイクしてね？

0846デフォルトの名無しさん

2016/09/18(日) 17:38:22.28ID:8zKQ5/pX

>>843
だから、静的型付け言語と動的型付け言語では、
考え方が違うだけで、最終的な開発効率は変わらないだろ。

設計できてるのも楽だし、
さっさとコードに書けるのも楽。

何が楽かっていう違いがあるだけで
全体を通した開発効率に言語程度では大きな差はない。
フレームワークやライブラリによってあっさりと覆されてしまう程度

0847デフォルトの名無しさん

2016/09/18(日) 17:39:15.31ID:7jfCU7SG

>>844
> なんでもできるよりか、制限があったほうがメンテナンス性が上がることも多い。
そこは静的型付きだと強制されるからねー

動的型付きだと強制されない分、プログラマの能力がもろに出るね
少数精鋭の方がいいと言った理由はここにあるんだよ

どんなレベルの人間が参入するか分からないようなチームだと強制は必要だけど、
コアメンバーがしっかりと確保できているなら余計な強制をせずにメンバーの裁量にまかせた方が
結果的にいいことの方が多いねー

システム開発も色んな特性があるから、どんな言語でも一緒じゃないんだよー

0848デフォルトの名無しさん

2016/09/18(日) 17:41:07.50ID:7jfCU7SG

>>846
C++ だってライブラリは豊富すぎるぐらいに豊富だけど、これを使って Web システム開発してるとこなんて
ないでしょ？
言語の特性は大事だよー

0849デフォルトの名無しさん

2016/09/18(日) 17:56:07.88ID:8zKQ5/pX

>>847
> 少数精鋭の方がいいと言った理由はここにあるんだよ

だから恥ずかしいから少数=精鋭だとおもうのはやめてくれｗｗｗ

0850デフォルトの名無しさん

2016/09/18(日) 17:57:24.14ID:+iC0HZAY

少数無能とか絶望じゃねぇか…

0851デフォルトの名無しさん

2016/09/18(日) 17:58:11.34ID:7jfCU7SG

>>849
少数精鋭を確保できない状況を自慢されても困りますｗ
そんな愚痴はチラシの裏にでも書いておいてください

0852デフォルトの名無しさん

2016/09/18(日) 18:00:21.77ID:+iC0HZAY

お疲れさまでした！

0853デフォルトの名無しさん

2016/09/18(日) 18:00:48.75ID:8zKQ5/pX

>>848
選ぶ人が少ないのと、開発効率の話は別。

俺がC++を選ばないのは、開発効率が低いからではなく、
実績がないのとC++用のウェブフレームワークがないから
言語のせいだとは思わない。

ちょっと調べたがcrowってのがあるらしいな。
これだけらしいぞ。やっぱり他の言語との差がある用には見えない。

http://qiita.com/noco/items/ce08a39e7be4120f1ba0
#include "crow_all.h"

int main() {
　crow::SimpleApp app;

　CROW_ROUTE(app, "/")([](){
　　return "Hello, World!";
　});

　app.port(8080).multithreaded().run();
}

0854デフォルトの名無しさん

2016/09/18(日) 18:16:33.91ID:7jfCU7SG

>>849
結局この人って、まともなプロジェクトチームを組めないPMとか経営層の人なんだろうね
そういう状況なら静的型付き言語を信奉するのも分からないでもないね

それなりの技術力を持った人間を数人集めればいいんだけど、そういう人間は単価も
高いからね

その単価の高さにビビって安い人間を数だけ集めてプロジェクトは崩壊、ってよくある
話だけど、プログラマの生産性の差は単価の差以上にあるってことを理解してないんだろうね

0855デフォルトの名無しさん

2016/09/18(日) 18:32:56.33ID:7jfCU7SG

そう考えると「言語によって差なんて生じない」という発言にも合点がいくね
経営層からすればプログラマなんて使い捨てだろうし、そこに言語によって差があったら
安い人材を集められないもんね

0856 ◆SEdFBOkLSw

2016/09/18(日) 19:36:08.52ID:pBvlgmH/

babel君がまた発狂してるのかと思ったわ

0857デフォルトの名無しさん

2016/09/18(日) 21:03:40.80ID:4A67n4Iq

id二つNGに突っ込んだら200くらい数字が飛んでるけど

0858デフォルトの名無しさん

2016/09/18(日) 22:57:19.51ID:8zKQ5/pX

>>855
最後言い返せなくなったらそれかｗ

自分の妄想に夢を抱いて自己満足ｗｗｗ

0859デフォルトの名無しさん

2016/09/19(月) 00:15:33.48ID:EdcTl4fm

>>858 の意見見てたらそう思う気も分かるわ
言語によって違いがないなんてプログラマをバカにしてるもんな
プログラマを職人として敬う雰囲気が微塵も見えないし

0860デフォルトの名無しさん

2016/09/19(月) 00:28:31.28ID:Rfn/Judi

>>859
言語によって違いはあるが開発効率はほとんど変わらないって言ってるんが？

フレームワークやライブラリの方が開発効率に大きく影響し、
言語の違いは自分の好みなんかはあるだろうが、
開発効率そのものには影響しないって言ってる。

俺が言ってないことに話をすり替えるな。

0861デフォルトの名無しさん

2016/09/19(月) 00:30:40.90ID:EdcTl4fm

>>860
そんなトンチンカンな意見で現場に合わない言語を押し付けられたら現場が可哀想だよね
現場のことは現場に任せた方がいいよ

0862デフォルトの名無しさん

2016/09/19(月) 00:32:57.11ID:Rfn/Judi

>>861
どの言語も開発効率は変わらないって言ってるんだから
俺が開発効率を理由に、言語を押し付けることはない。

どれでも良いってことは、好きな言語を使えって言ってるのと
同じなんだが？

0863デフォルトの名無しさん

2016/09/19(月) 00:34:27.71ID:EdcTl4fm

>>862
そっか
てっきり「安く人を集められるんだからJavaかPHPを使え」とか言ってるんだと思った
そうじゃないなら今後も現場にはノータッチでいてくれ

0864デフォルトの名無しさん

2016/09/19(月) 02:02:32.10ID:4xkC7LBW

>>751
アサーションは表明でしかないなんだから、コンパイラが発見したバグ潰してないだろ。

0865デフォルトの名無しさん

2016/09/19(月) 03:16:23.35ID:Rfn/Judi

>>863
最初から言語によって開発効率に差は殆ど出ないっていってる。
それよりもフレームワークやライブラリの方が重要で、
言語による僅かな違いはそれらによって簡単に覆る。

0866デフォルトの名無しさん

2016/09/19(月) 03:17:24.26ID:Rfn/Judi

>>863
> そうじゃないなら今後も現場にはノータッチでいてくれ
はぁ？俺が現場だし、俺は何も強要してない。

言語による違いなんて僅かなんだからどれでもいい。

0867デフォルトの名無しさん

2016/09/19(月) 03:20:24.57ID:Rfn/Judi

つーか、言語によって大差でるっていうのなら、

例えばPHPで10ヶ月かかる見積もりの仕事です。
でも○○言語を使えば、○ヶ月で出来ますって言ってみたら良い。
大差でるというのなら2～3ヶ月は軽く縮められるだろう？

0868デフォルトの名無しさん

2016/09/19(月) 03:56:05.70ID:EdcTl4fm

>>867
品質とかそのへんの情報を抜きにして言語だけで縮められるわけないでしょ
なんでそういう極論に持っていこうとするかな…

0869デフォルトの名無しさん

2016/09/19(月) 10:42:54.91ID:eq5kiSUF

ライブラリを使うだけでなく
作る必要もあるレベルのプログラマにとっては
言語の差は重要なんだよなあ

0870デフォルトの名無しさん

2016/09/19(月) 11:50:22.78ID:Rfn/Judi

言語の差が重要じゃないなんて言ってない。
言語の違いで開発効率に大きな差が出ることはないといってる。

0871デフォルトの名無しさん

2016/09/19(月) 11:57:08.76ID:nrpDbgrS

同意できないな
JavaとRubyで大規模開発したことあるけどRubyのほうが手間がかかることが多かったよ

0872デフォルトの名無しさん

2016/09/19(月) 12:17:46.47ID:d/dsjAXw

１週間で立ち上げて３ヶ月で捨てる Ruby
２０年たたかえる Java

0873デフォルトの名無しさん

2016/09/19(月) 12:51:43.68ID:3uBbHrP4

>>871
そりゃIDEのサポートがないRubyだからだよ。
静的言語のような漏れのない補完とかは無理でも
動的言語だってIDEの手厚い言語はほかにある。

0874デフォルトの名無しさん

2016/09/19(月) 13:07:02.10ID:/npYylc/

人を集められるかどうかも開発効率の一部と考えると、言語によってかなり差が出るのじゃないか

0875デフォルトの名無しさん

2016/09/19(月) 13:16:11.20ID:nrpDbgrS

>>873
彼は言語の違いで開発効率に差がでないという話をしてる
彼の言い分が正しいならJavaとRubyで大して差はでないはずだよ

0876デフォルトの名無しさん

2016/09/19(月) 13:25:38.44ID:eq5kiSUF

Javaドカタに無理矢理Rubyを使わせても
開発効率なんて出るわけ無いだろ

0877 ◆SEdFBOkLSw

2016/09/19(月) 13:48:25.16ID:YRbv8ESl

まー、schemeのソースが生きてる業種に居たら、言語の違いで開発効率に大きな差は出るとしか言えんな。
Ruby使いは、なんか特別視してほしいきらいが強いわ。

0878デフォルトの名無しさん

2016/09/19(月) 14:07:54.37ID:Rfn/Judi

>>875
> 彼の言い分が正しいならJavaとRubyで大して差はでないはずだよ
その通り。結局フレームワークやライブラリで
開発効率の大半は決まるので、言語変えた所で数%の違いが出るかどうか。
だから特定の言語で作るから開発期間は減りますなんて言えんわけよ。

0879デフォルトの名無しさん

2016/09/19(月) 14:33:10.95ID:KnX9vMV5

>>878
IDEのサポートの有無も大きいよ。そしてそれは対象となる言語でずいぶん違ってくる。
それはさておき、君の主張はけっきょく、言語を変えても数％の違いが出るかどうかわからんような条件の
案件しか対象にしていない、あるいはそういうのが大半の世界に住んでいるってだけの話のように聞こえるけど？

0880デフォルトの名無しさん

2016/09/19(月) 14:36:15.92ID:3uBbHrP4

なんだ前提が間違っているから結論もおかしくなってるだけか
人騒がせなやつだな

0881デフォルトの名無しさん

2016/09/19(月) 14:43:47.50ID:fIqWe4kn

>>879
じゃあ、言語を変えるだけで、数%を超えるような差がでる条件を言ってみてよ。

念の為に言っておくけどフレームワークやライブラリで大きな差がでるとは言ってるんだから、
数%を超える差の理由が、一方ではフレームワークなし、もう一方ではフレームワークありとかはだめなｗ
両方で同等のフレームワークやライブラリを使ってることが条件。
あと開発者の能力も同じ。

0882デフォルトの名無しさん

2016/09/19(月) 14:52:21.29ID:nrpDbgrS

>>878
何のトラブルもなく開発が終わるという前提ならそうかもしれんけどそうじゃないことは多々ある
RubyとかC++は躓いた時に解決にどれくらい時間食うかわからんよ

0883デフォルトの名無しさん

2016/09/19(月) 15:08:40.68ID:fIqWe4kn

>>882
じゃあ何言語ならトラブル起きないと？

0884デフォルトの名無しさん

2016/09/19(月) 15:08:58.87ID:fIqWe4kn

それとも他の言語なら躓いてもすぐに解決できるってこと？

0885デフォルトの名無しさん

2016/09/19(月) 15:12:21.48ID:1dfbjatZ

>>882
つまり躓いたときに解決できるエキスパートがチームにいる言語で
開発するのが一番って事だよな
エキスパートがRubyやC++を得意とするならそれを選ぶべき

0886デフォルトの名無しさん

2016/09/19(月) 15:13:40.09ID:fIqWe4kn

>>885
そうよだね。
開発効率は言語によって変わるんじゃなくて
人の影響も、もちろん大きい。

0887デフォルトの名無しさん

2016/09/19(月) 15:21:22.59ID:1dfbjatZ

ライブラリは世界のどこかにいるエキスパートが書いたと考えれば

(1)ライブラリの有無
(2)チーム内のエキスパートの有無
(3)その他

くらいの優先順位かもな

0888デフォルトの名無しさん

2016/09/19(月) 15:34:15.95ID:1wTu3u7g

エキスパートが出来る言語でと言うのは大間違い。
そういう考えだとエキスパートに負荷がかかって破綻する。
皆が最も慣れてる言語以外あり得ない。

0889デフォルトの名無しさん

2016/09/19(月) 15:44:55.48ID:nrpDbgrS

>>884
すぐには言い過ぎだけど差はある
例えばRubyだとステップ実行が手軽にできないからJavaなら簡単に見つけられるバグでも時間がかかったりする
あと動的なものを多用する文化があるからソースを追いかけるのに苦労する

>>885
特に理由がなければ人を選ばない言語にしておくほうがよいと思われる

0890デフォルトの名無しさん

2016/09/19(月) 15:51:03.31ID:fIqWe4kn

>>889
http://railsguides.jp/debugging_rails_applications.html#byebug-gem%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%A6%E3%83%87%E3%83%90%E3%83%83%E3%82%B0%E3%81%99%E3%82%8B

> byebug gemを使用すると、Railsコードにブレークポイントを設定してステップ実行できます。
> 次を実行するだけでインストールできます。
>
> $ gem install byebug
> 後はRailsアプリケーション内でbyebugメソッドを呼び出せばいつでもデバッガーを起動できます。
>
> 以下に例を示します。
>
> class PeopleController < ApplicationController
> 　def new
> 　　byebug
> 　　@person = Person.new
> 　end
> end

> 3.6 ステップ実行
> これで、トレース実行中に現在の実行位置を確認し、利用可能な変数をいつでも確認できるようになりました。
> アプリケーションの実行について引き続き学んでみましょう。
>
> stepコマンド (短縮形はs) を使用すると、プログラムの実行を継続し、
> 次の論理的な停止行まで進んだらデバッガーに制御を返します。

> 3.7 ブレークポイント
> ブレークポイントとは、アプリケーションの実行がプログラムの特定の場所に達した時に停止する位置を指します。
> そしてその場所でデバッガーシェルが起動します。
>
> break (またはb) コマンドを使用してブレークポイントを動的に追加できます。
> 手動でブレークポイントを追加する方法は次の 3 とおりです。

0891デフォルトの名無しさん

2016/09/19(月) 15:53:08.97ID:fIqWe4kn

>>889
> 例えばRubyだとステップ実行が手軽にできないから

あんたが言ってる「手軽にできないから」っていうのは
「マウスやファンクションキーが使えないから」という言葉に
置き換えたほうが良いよｗ

↓置き換え例

例えばRubyだとステップ実行がマウスやファンクションキーで実行できないから
Javaなら簡単に見つけられるバグでも時間がかかったりする

な、すごく、どうでもいいこと（差は出ないこと）だって気づくだろう？ｗ

0892デフォルトの名無しさん

2016/09/19(月) 16:22:48.20ID:nrpDbgrS

>>891
ブレークポイント追加するためにわざわざメソッド名をタイプして
変数の内容を確認するのにわざわざ変数名をタイプして
デバッグ終わったらブレークポイントを全部探して削除する
こんなめんどくさいことよくやる気になるな
しかもここまでしておいてIDEと比べて何かメリットがあるわけでもない

マウスやファンクションキーで手軽に出来るならそれでいいじゃないか
こんなことして何が嬉しいの？
これで開発効率が下がらないなら元々作業が遅いだけなんじゃないの？

0893デフォルトの名無しさん

2016/09/19(月) 16:25:04.31ID:fIqWe4kn

> デバッグ終わったらブレークポイントを全部探して削除する
git stashかgit reset --hardすればいいだけ

> こんなめんどくさいことよくやる気になるな

どれだけタイプ速度遅いんだよｗ

結局の所タイプ速度程度の問題になるってわけさ。

0894デフォルトの名無しさん

2016/09/19(月) 16:27:22.67ID:IGL8kRas

RubyのGUIデバッガ

http://dev.classmethod.jp/tool/visual-studio-code-ruby-debug/

0895デフォルトの名無しさん

2016/09/19(月) 16:28:39.23ID:fIqWe4kn

>>892
俺が言いたいのはね、ステップ実行がどうとかいいなさんなってこと。

マウスポチポチのほうが早い、キーボードタイプするのめんどい。
だから開発効率はマウスでできる方がいい！
っていう言い方にしなさいってこと。

下手に技術的な話にしようとしなくていいよ。
所詮あんたが言ってるのは、程度の低い
マウス vs キーボードなんだからさ。

0896デフォルトの名無しさん

2016/09/19(月) 16:46:47.60ID:EdcTl4fm

>>881
同じ品質で同じスケジュールで作れ、となったら差は出にくいね
LL使って品質は多少落ちてもいいからスピード命で、なら差は出せるかな

0897デフォルトの名無しさん

2016/09/19(月) 17:00:33.32ID:nrpDbgrS

>>895
ステップ実行が技術的な話ってちょっと大げさすぎない？
単純にデバッグ環境がショボいと効率が落ちるという話をしてただけなんだけどね
ちょっとマウスの話しただけでマウス vs キーボードとか意味不明すぎる

まあ、この話はもういいよ
たかがステップ実行するのにgitが出てくることに疑問を持たない時点で価値観が違いすぎる
あなたにとってはあんなものでも使いやすいんだろう

0898デフォルトの名無しさん

2016/09/19(月) 17:05:27.59ID:fIqWe4kn

>>897
だからデバッグ環境とかいうなって、

マウス vs キーボードじゃん。
しょぼいって他に何があるんだよｗ

0899デフォルトの名無しさん

2016/09/19(月) 17:06:28.41ID:fIqWe4kn

> たかがステップ実行するのにgitが出てくることに

意味不明。出てきたらなにか悪いのか？
開発効率の話であって、同じやり方でやれって話じゃないだろ。

やり方が違うってだけで、開発効率に大きな差はない。

0900デフォルトの名無しさん

2016/09/19(月) 18:26:23.68ID:KnX9vMV5

>>893
> git stashかgit reset --hardすればいいだけ

素朴な疑問なんだけど、全部巻き戻しちゃったらデバッグで修正した部分はどうなるの？

0901デフォルトの名無しさん

2016/09/19(月) 18:27:54.33ID:eq5kiSUF

>>894で終了してるのにまだそのネタ引っ張るのか

0902デフォルトの名無しさん

2016/09/19(月) 18:53:18.73ID:KnX9vMV5

引っ張るも何も直前の>>899までその関連のネタ（gitでデバッグ支援）が続いてるんだけど

0903デフォルトの名無しさん

2016/09/19(月) 18:57:19.26ID:eq5kiSUF

GUIデバッガが有るのが分かってるのに？
マウスでやりたきゃ勝手にやれば良いだろ

0904デフォルトの名無しさん

2016/09/19(月) 19:07:11.14ID:KnX9vMV5

なにをムキになっているのか…
それともgitでbyebug支援というのは、「こうやればできるだろう」って想像にすぎなくて
実際はそんな運用はないのに“言語で差は出ない”君が想像で主張しているだけって話？

0905デフォルトの名無しさん

2016/09/19(月) 19:12:32.43ID:eq5kiSUF

ちょっとググりゃ分かる程度の事も調べられない低脳が
さも仕事で使ってるかのように開発効率を語ってるのが
滑稽ってだけだよ

0906デフォルトの名無しさん

2016/09/19(月) 19:40:28.94ID:nrpDbgrS

彼がそれを用いた話をする気がないのだからGUIデバッガの有無なんて関係ないでしょ

0907デフォルトの名無しさん

2016/09/19(月) 19:51:07.68ID:KnX9vMV5

>>905
すまん。おれ低脳だからホントわかんない。
そのググれば出てくるページ、教えてください。お願いします。

0908デフォルトの名無しさん

2016/09/19(月) 20:03:22.97ID:eq5kiSUF

>>907
Rubymine
http://qiita.com/masa-iwasaki/items/8b3e49e3b34f8b1f3c78

Visual studio code
http://qiita.com/chimame/items/56e48ab3145312ff1786

てかVisual studio codeは>>894で既出だろ
直近のスレも読めねーのか
本当に907はゴミだな

0909デフォルトの名無しさん

2016/09/19(月) 20:08:24.36ID:eq5kiSUF

第一Rubyでデバッガ欲しいってだけでゴミなのに
欲しがってる物も探せないとかゴミごみアンドゴミだな

0910デフォルトの名無しさん

2016/09/19(月) 20:12:48.76ID:KnX9vMV5

>>908
いや、さすがにRubyにGUIツールがあるのは分かっている。

そうじゃなくて、>>893のgitでbyebugのブレークポイントを巻き戻して消すって話で、
その場合、デバッグ結果の変更はどうするのかという>>900の疑問の答えが知りたい

0911デフォルトの名無しさん

2016/09/19(月) 20:26:43.55ID:eq5kiSUF

知るか。byebug仕込んだファイルと修正するファイルが同じなら
それぞれを別コミットにしてgit rebaseで一方だけ消しゃいいだろ
てか byebug foo.rb でも使えるがな

0912デフォルトの名無しさん

2016/09/19(月) 20:44:28.65ID:eq5kiSUF

どの言語でも開発効率一緒とか言ってる奴に聞いてるなら、
実際に手を動かしてるわけないんだから聞くだけ無駄
たぶん自分のPCにgitコマンドすら入ってないぞ

0913デフォルトの名無しさん

2016/09/19(月) 20:48:36.46ID:tSJ/bOM5

別人への質問に割り込んで、さんざんゴミ呼ばわりした挙げ句、まともな回答も思いつかない
安価もまともに追えねー真のゴミはID:eq5kiSUF自身だったというオチか

0914デフォルトの名無しさん

2016/09/19(月) 20:49:44.92ID:nwIwSQT5

毎日せっせとリポジトリの栽培に没頭するプログラマー達

0915デフォルトの名無しさん

2016/09/19(月) 21:11:44.13ID:eq5kiSUF

>>913
お前のそのレスの何処に有用な情報があるんだよ
鏡見ろカス

>>892はマウスでポチポチやれなきゃとダダこねるゴミの上に
>>894でGUIが有ると判明しても>>897でまだgitが云々言ってる真性のカスだろが
しかも無知の素人のくせに最初>>871で大規模開発した事あるとか騙ってんだぜ
マジでゴミ

0916デフォルトの名無しさん

2016/09/19(月) 21:14:07.72ID:KnX9vMV5

>>911
> それぞれを別コミットにしてgit rebaseで一方だけ消しゃいい

それだと複数のbyebugの仕込みと修正を前後しつつ連続して行なうといずれ破綻するように思うのですが…

百歩譲ってそれが正解だとしても「git stashかgit reset --hardすればいいだけ」という表現からはほど遠いですよね

あと
>>909
> Rubyでデバッガ欲しいってだけでゴミ

これは「Rubyにはデバッガは原則不要」とも読めるのですが、そうだとして何故そう思われるのですか？
実際、開発ではデバッガを使わずに済ませているのですか？

0917デフォルトの名無しさん

2016/09/19(月) 21:17:45.01ID:KnX9vMV5

>>915
私はID:nrpDbgrSではないので、なにか人違いをしていませんか？^^;

0918デフォルトの名無しさん

2016/09/19(月) 21:23:49.65ID:eq5kiSUF

>>916
rebaseでコミット並べ替えたりsquashも知らないゴミのくせに
知ったような口聞かないでくれる？

デバッグなんて落ちたときのスタックトレースで事足りるから
ぶっちゃけJavaでもいらんよ？cでgdb使うくらい
でもお前の仕事の仕方にケチはつけんから好きにしろよ。こっちもお前の事ゴミと思うだけだから

0919デフォルトの名無しさん

2016/09/19(月) 21:30:36.87ID:nrpDbgrS

>>915
勘違いで恥かいたからって矛先変えて八つ当たりするのはNG

Rubymineのことは知ってた
ただこれは有償だしJavaにおけるIDEほどスタンダードじゃないはずだから無視しただけ
あとID:fIqWe4kと話をしていたのであって、あなたには聞いていない
だから判明したと言われても関係ない

0920デフォルトの名無しさん

2016/09/19(月) 21:35:09.10ID:eq5kiSUF

無視しただけw
もっとマシな言い訳考えろアホ

八つ当たりも何もお前らどっちも無知のアホのくせに
知ったような事書くゴミじゃん
同類だよ

0921デフォルトの名無しさん

2016/09/19(月) 22:01:50.84ID:fIqWe4kn

なんか俺がいない間にアホな争いやってんなｗ

git reset --hardじゃ全部リセットされるって？
リセット前に必要な部分だけコミットすりゃいいじゃんｗ
git addでもgit add -pでもつかってさ。

0922デフォルトの名無しさん

2016/09/19(月) 22:04:01.73ID:fIqWe4kn

>>912
> たぶん自分のPCにgitコマンドすら入ってないぞ
入れ方知りたいなら素直にいいなよｗ

brew install git と入力するだけで
簡単に入るぞｗ

0923デフォルトの名無しさん

2016/09/19(月) 22:09:48.94ID:fIqWe4kn

>>904
> それともgitでbyebug支援というのは、「こうやればできるだろう」って想像にすぎなくて
意味不明。gitでbyebug支援なんて話はしてない。
俺が言ってるのはbyebug使うのが終わった後の後片付けの話だ。

そんなもん、一連の修正の中から必要な部分だけを
コミットするというgitの普通の使い方じゃんかって話。
必要な部分だけをコミットし、必要ないブレークポイントはgit reset --hardで戻す。

いつもどうやってコミット作ってんだよ。コミットはセーブポイントじゃねーぞ？
意味がある単位でコミットを作るんだから、一連の修正の中から必要なものだけを～って
いうのはデバッグとは関係なく、日常的にしているはずの内容だ。
普段お前がまともな開発してないのがまるわかりだな。

0924デフォルトの名無しさん

2016/09/19(月) 22:22:28.53ID:fIqWe4kn

で気づいている人はいると思うが、あいつ（ID把握しとらんｗ）が
話しているのって言語の違いじゃなくて、ツールの違いなんだわｗ
俺が言ってるのは言語の違いで開発効率に大きな差はでないって話

そこに「ツールを使った場合 vs ツールを使わない場合」で比較しようとしてる。
そしてGUIのIDEだけがツールだと思っちゃってんのよねｗ
CLIでもデバッガあるしデバッガがない言語なんてまずないし。

CLIのツールを知らないから「ツールを使った場合 vs ツールを使わない場合」で比較するのが
当然みたいに思ってるようだが、やり方が違うだけでCLIでもツールが有る。
だからせめて「GUIツールを使った場合 vs CLIツールを使う場合」という話をしなければならなかった。

なのにまるでRubyじゃステップ実行ができないような事を言ってるし、
一部だけコミットする方法も知らないし、それはお前がIDEの使い方に慣れていて
CLIでの開発に慣れてないだけじゃんか。で終わりなわけよ。

だから今までの一連の内容は、言語で開発効率に差がつくという根拠になってない。

0925デフォルトの名無しさん

2016/09/20(火) 04:47:08.42ID:7K6mEzO9

そのまともな開発とやらでは実際にそんな運用してんの？
git前提ならgitが使えない環境ならどうするの？
話に全然現実味がない

環境の差すら含めないのであればここで言う言語の違いとやらはかなり狭い範囲を指すんだろうね
それなら開発効率に差が出ないとうのも正しいかもな

0926デフォルトの名無しさん

2016/09/20(火) 07:30:39.51ID:F3/sc2Y5

>>925
まともな開発でgit使えない環境とかマジありえないんだけど

0927デフォルトの名無しさん

2016/09/20(火) 07:35:29.24ID:+3HpdUPY

git好きはほんまに使えんやつばかりやでw

0928デフォルトの名無しさん

2016/09/20(火) 07:57:39.87ID:7K6mEzO9

>>926
せやな
で、その環境では上で話にあがってるような運用が本当に行われてるの？

0929デフォルトの名無しさん

2016/09/20(火) 09:37:49.78ID:fS5Ni7aU

>>928
開発方法なんて自分が好きな方法でやればいいだろｗ
論点はそこじゃねーよ。

Javaならステップ実行できます。Rubyはできません。
これが言語による開発効率の差です。って
言うアホがいたって話だろ。

0930デフォルトの名無しさん

2016/09/20(火) 11:04:03.39ID:8Qhl2IdX

gitすら「全然現実味がない」とのたまうクソ底辺が
言語について自論を語ってんよかよw

0931デフォルトの名無しさん

2016/09/20(火) 19:52:08.42ID:+3HpdUPY

よかよかw

0932デフォルトの名無しさん

2016/09/20(火) 21:00:48.67ID:fS5Ni7aU

>>930
なんか勘違いされそうだから念の為に言っておくと、

言語によって開発効率に大差なんてでねーよ。
開発効率はフレームワークやライブラリで決まる。
って言ってる俺が、gitぐらい使えよｗって言ってる方な。

0933デフォルトの名無しさん

2016/09/21(水) 01:08:08.51ID:LyIIWP0R

>>924
ただライブラリやフレームワークは言語に依存するからなぁ。
言語のコア機能のみで開発なんて案件は殆どないだろ？

0934デフォルトの名無しさん

2016/09/21(水) 01:09:11.66ID:LyIIWP0R

>>926
まだsvnのとこもある。

0935デフォルトの名無しさん

2016/09/21(水) 01:30:12.68ID:NGNffyIV

>>933
依存した所で開発効率には影響しない

0936デフォルトの名無しさん

2016/09/21(水) 05:58:27.81ID:AvKsbed6

開発効率君ってもしWebアプリを作るとしたら何をどんな理由で選ぶの？

0937デフォルトの名無しさん

2016/09/21(水) 07:00:20.32ID:wW2qFR9f

選ぶこと自体が効率を下げる
目の前に既にあるもので一刻も早く無心に作り始めるのが最も効率的
出来上がったものの質には興味ない

0938デフォルトの名無しさん

2016/09/21(水) 07:41:46.05ID:lN+U+lYo

> 出来上がったものの質には興味ない
え？プロがこれ言っちゃだめな気がする…

0939デフォルトの名無しさん

2016/09/21(水) 08:01:00.98ID:wW2qFR9f

いいやプロだからこそだよ
コストをかけて質の良い物を作っても名声くらいしか得られない
コストをかけずに質の悪いものを作れば次の仕事ができる
自社には回ってこないかもしれないが数社と情報提携して
作戦を共有すれば結果的に自社に回ってくるのと同じこと

0940デフォルトの名無しさん

2016/09/21(水) 08:34:40.04ID:Axlh78Lz

自演くせえw

0941デフォルトの名無しさん

2016/09/21(水) 10:20:44.78ID:HxHNWhWH

言語によって開発効率が変わると思ってる
言語にこだわりあって職人っぽそうな方が
そうじゃない方よりも
技術力も低く頭も悪そうってところが哀しいね

0942デフォルトの名無しさん

2016/09/21(水) 16:02:09.31ID:Fil1hk+D

Haxe(ヘックス)はOSSで、JSに型チェックを付けたような言語で(altJS)、
JS, Flash, PHP, C++, Java, C#, Python に書き出せる。
Windows8.1対応

IDEは、FlashDevelop

このサイトで、ブラウザでプログラミングして、実行できる
Try Haxe !
try.haxe.org/

Haxeプログラミング入門、尾野政樹、2015

0943デフォルトの名無しさん

2016/09/21(水) 21:06:22.77ID:wW2qFR9f

HaxeはES4+
TypeScriptはES7+
どっちが良いかは良い子の皆ならすぐ分かるよね！

0944デフォルトの名無しさん

2016/09/21(水) 21:15:02.32ID:mmbzRdpk

TypeScript(javascript)は、C言語に変換できるのか?
ありげでみつからん。

0945デフォルトの名無しさん

2016/09/21(水) 21:27:11.99ID:wW2qFR9f

スクリプト言語は分かるが、C言語に変換出来る必要はない
どのみち他のC言語のライブラリと上手く組み合うように書こうとしたら大変で
わざわざHaxe使うメリットは無いのだから
実行形式もといLLVMIRで書き出せれば必要十分

0946デフォルトの名無しさん

2016/09/21(水) 21:52:46.49ID:mmbzRdpk

TypeScript(javascript)　⇔　LLVM　は相互変換できるの?

0947デフォルトの名無しさん

2016/09/22(木) 06:36:35.21ID:esuUIiS6

大規模開発なら圧倒的に、Haxe

Haxeには、ブロックスコープ { } がある。
this も正常に、インスタンスを指す

ソースコードを文字列化して送っても、型が消えない。
全く同じ処理を、複数言語で作らなくていい

引数付き Enum
Scalaのようなパターンマッチありの、switch

TypeScriptは、JSと互換性が高いから、クソ

0948デフォルトの名無しさん

2016/09/22(木) 06:54:23.96ID:P28LZX5F

頭悪そう

0949デフォルトの名無しさん

2016/09/22(木) 07:30:18.44ID:M6/5uB5L

＞TypeScriptは、JSと互換性が高い

AltJSなんだから当たり前だろ……
まあJS自体が嫌いなんだろうけど

0950デフォルトの名無しさん

2016/09/22(木) 10:55:07.40ID:0BMaKoR3

そんなシンタックスの違いなんて開発効率に影響しない

0951デフォルトの名無しさん

2016/09/22(木) 15:44:31.18ID:iQ00+ali

しかしJavaScriptは相当特殊なパラダイムが影響しそうな気がする

0952デフォルトの名無しさん

2016/09/22(木) 19:32:50.35ID:M6/5uB5L

たしかにLispは「相当特殊なパラダイム」だな

0953デフォルトの名無しさん

2016/09/22(木) 20:07:57.60ID:XjtOZmEL

>>949
TypeScript は確か JavaScript のスーパーセットだよね？
似るも似ないもないよね、まんま JavaScript が通るんだから

0954デフォルトの名無しさん

2016/09/22(木) 20:11:34.14ID:XjtOZmEL

でも TypeScript の成功は面白いよね
静的型付き言語のメリットのひとつとして高速化があげられるのに、TypeScript にはそんなものは
ないんだからね（もともと JavaScript が動的型付き言語としては速い方だってのもあるけど）
それでも成功するということは、高速化のメリットは実は静的型付き言語の決め手ではなかった
ということだもんね

0955デフォルトの名無しさん

2016/09/22(木) 20:38:07.35ID:M6/5uB5L

静的型付けのメリットに保守性があるから

0956デフォルトの名無しさん

2016/09/22(木) 20:48:02.51ID:P28LZX5F

TypeScriptの意義はつまるところコーディングスタイルの統一だろ
jsを書いているとき多くの人が暗に想定している型、クラス、モジュールという概念を明示的かつ画一的にコードで表現できるようにした
型検査は副次的なもので、それほど重要ではない

0957デフォルトの名無しさん

2016/09/22(木) 22:05:16.95ID:XjtOZmEL

>>955
それは分かるんだけど、高速化だって重要だと思われてたはずだよ
でもそれが幻想だったことを白日の下にさらけ出した点が面白いんだよね

0958デフォルトの名無しさん

2016/09/22(木) 23:01:40.07ID:zXBENXMk

重要なのは開発速度であって実行速度じゃないっていうのは
随分前からの常識じゃないかｗ

0959デフォルトの名無しさん

2016/09/23(金) 00:09:27.26ID:+O1BWqPV

実行を高速化するとソースは汚くなるだろ
でも汚くても頑張って読むから大丈夫って言える奴はどんな言語でも読める才能がある
そういう奴は静的型付けがあろうがなかろうが成功する

0960デフォルトの名無しさん

2016/09/23(金) 01:05:52.67ID:95klKBHQ

「汚く」なるのは未熟な言語及び実行環境
フランクで普通じゃなくなるのは当然だが、必ずしも「汚く」なるものでもない

0961デフォルトの名無しさん

2016/09/23(金) 01:34:05.83ID:MCHe7LJO

> 実行を高速化するとソースは汚くなるだろ
ならない。
例えばforループを高速化してみ？

0962デフォルトの名無しさん

2016/09/23(金) 02:08:52.30ID:gILSPpVJ

>>961
は？
ループ展開したほうが綺麗なコードとでも言うのか？

0963デフォルトの名無しさん

2016/09/23(金) 08:00:17.71ID:7qISPcxF

実行速度のために色々と捧げたソース見たことないんでしょ、彼は。

0964デフォルトの名無しさん

2016/09/23(金) 08:05:07.19ID:+O1BWqPV

静的型付けの本来の目的は未熟な弱者を救済することだから
勝ち馬に乗って成功するみたいな話ではない

0965デフォルトの名無しさん

2016/09/23(金) 08:53:20.76ID:95klKBHQ

>>963
静的型付け言語はまた別だけど、
動的なスクリプト言語において実行を高速化するとは

型情報などのヒントをより多くエンジンに与えて、
曖昧な書き方をしないってことでしょ
それを突き詰めたところにCythonやmrubyやasm.jsみたいになるけれど汚いとは思えない

一方対極に動的の特徴であるevalを使った最適化もあるけれど、
これもその部分だけはやや不自然だが、ロジックの短縮にもなるし
全体的な見通しをみれば汚くならない

他にもある特定のケース向けの最適化を沢山入れていくとシンプルじゃなくなるが
これもパレートの法則に則って見極めていけば良い
言語エンジンのソースコードは汚いか？という話と同じ
個人的にはギリギリセーフ

0966デフォルトの名無しさん

2016/09/23(金) 08:57:27.74ID:AqTRNsCZ

>>964
未熟な弱者を束ねて成功する勝者だろ

0967デフォルトの名無しさん

2016/09/23(金) 08:59:43.94ID:Pu19XfH5

>>965
それだけだとちと心許ないかな。
JITかかったときに、中身がきちんとL2までに乗り切るかとか、その辺も把握したい。
となると、ある変数群を、キャッシュに乗り切る型付き配列に突っ込んでおくとか、そういう感じで、実装者側から見るととても汚いソースに見える事はあるよ。

0968デフォルトの名無しさん

2016/09/23(金) 09:36:33.50ID:95klKBHQ

>>967
強い将棋エンジン作ったときはそこまで考える必要があって
型付き配列とかだいぶ駆使しまくったけど汚いとは思わないよ

俺が汚いと思うのはむしろその時で言うと、
新しめの構文の最適化が十分に進んでなかったので
歪に書かざるを得なかったこと
そういうエンジン側の未熟な点を考え過ぎるのは汚いと思う

まあエンジンに期待してることの違いで、
ハードを考えすぎにといけないというのも同じく
高級言語として汚いということになるのだろう

0969デフォルトの名無しさん

2016/09/24(土) 10:24:13.27ID:l0zRcYbu

>>955
最適化マニアが集まってくる言語に保守性はない

0970デフォルトの名無しさん

2016/09/24(土) 10:53:58.64ID:aq+wtFaS

最適化なんて、ボトルネックだけCで書いてRubyでラップするのが最強すぎて
他の言語がなんで真似しないのか分からない

0971デフォルトの名無しさん

2016/09/24(土) 11:46:41.03ID:LQVhf+ds

それはJSもといV8が最適。
ネイティブとのバインディングが最も優れてる。

ただネイティブでボトルネックをと言っても
実際はオーバーヘッドや言語を跨いだ最適化問題があるが、
V8はマクロでの魔改造C++やいくつかの抽象機械語レイヤーを提供して
問題を解決している。

ただ仕様変更が激しいのが欠点。

0972デフォルトの名無しさん

2016/09/24(土) 13:59:17.07ID:e4J3FKju

>>970
> 最適化なんて、ボトルネックだけCで書いてRubyでラップするのが最強すぎて

その通り昔の.NETではないVBとVC++の関係もそれと同じだったね。
VBを使って主にインターフェース部分をRADで簡単に作成する。
パフォーマンスが必要な部分はVC++でDLLを作ってVBから呼び出す。
全部一つの言語で作る必要はないんだよ。

ただしブラウザ動くJavaScriptの場合は難しいけど。
ちょっと前ならFlashやJavaやActiveXと併用するって手もあったけど
今はJavaScript（もしくはAltJS）だけで作ることが推奨されてるからね。

0973デフォルトの名無しさん

2016/09/24(土) 14:40:43.39ID:sz8E8CVl

asm.jsが今んとこその役割を果たしてるんじゃないの
わざわざjavascriptで書く猛者も居るかも知れんけど

0974デフォルトの名無しさん

2016/09/24(土) 15:24:34.30ID:fvqTVwn4

WebAssembly は着々と各ブラウザベンダーが進めてはいるようだけどね
ブレイクするにはまだ２年ぐらいは必要かな

0975デフォルトの名無しさん

2016/09/24(土) 18:58:40.35ID:jSgJTuJa

>>970
Web系ならそんなデリケートな仕組み使うよりWebAPI作って分離しちまおうぜという発想になるから

0976デフォルトの名無しさん

2016/09/24(土) 21:27:49.78ID:6IMs83+U

>>975
そのWebAPIはC言語で書かれているのですが？

0977デフォルトの名無しさん

2016/09/24(土) 22:05:38.10ID:NNPY09Zb

そりゃもちろんnodeでES6だ

0978デフォルトの名無しさん

2016/09/25(日) 05:08:02.11ID:y4/VuarS

RESTなんかをWebAPIと呼ぶのは辞めた方がいい。
少なくとも言語板では今はDOMAPI＋αのことをそう呼ぶべきだ。

0979デフォルトの名無しさん

2016/09/26(月) 23:07:43.65ID:TcvLJVNN

結局このスレでも最強の言語は決まらなかったな

0980デフォルトの名無しさん

2016/09/27(火) 09:04:36.13ID:lbwP9zfe

もう必要最低限のラインは揃って言語間の差が小さくなってきたし

0981デフォルトの名無しさん

2016/09/27(火) 18:50:03.17ID:wQJpTuVv

アプリがリスコフになったんだが

0982デフォルトの名無しさん

2016/09/27(火) 22:37:01.88ID:0PlH9Ckj

いつになったらJavascriptはバイトコードになるのか
今のソース丸見え状態じゃ技術がダダ漏れだ

0983デフォルトの名無しさん

2016/09/28(水) 00:00:54.13ID:4rH6H9ji

JSはこれ以上はもう無理だと結論出てる

0984デフォルトの名無しさん

2016/09/28(水) 07:24:29.50ID:DCJCy4yl

JavaScriptのバイトコード
それWASMじゃん

0985デフォルトの名無しさん

2016/10/01(土) 18:34:01.93ID:REOAHOZ9

機械学習はpythonが強すぎる

0986デフォルトの名無しさん

2016/10/01(土) 19:09:56.24ID:ZWQ5J0j0

それはライブラリが多いから？

0987デフォルトの名無しさん

2016/10/01(土) 20:29:41.22ID:VMBRmgxd

pythonの言語力ではなく、C言語性のを使えるようにされてるからだ。

0988デフォルトの名無しさん

2016/10/01(土) 20:55:23.06ID:ZWQ5J0j0

具体的にはどういうこと？

0989デフォルトの名無しさん

2016/10/01(土) 21:04:39.09ID:VMBRmgxd

たとえばこれ。すでにC言語であったものをあとからPythonで使えるようにした。
言語自体として機械学習むけというわけでなくあとづけで機械学習向いてきた。

NumPy - Wikipedia

NumPyは、プログラミング言語Pythonにおいて数値計算を効率的に行うための拡張モジュールである。
NumPyの内部はC言語（やFortran）によって実装されているため非常に高速に動作する。
したがって、目的の処理を、大きな多次元配列に対する演算として記述できれば（ベクトル化できれば）、
計算時間の大半はPythonではなくC言語によるネイティブコードで実行されるようになり大幅に高速化する。
さらに、NumPyは BLAS を実装した行列演算ライブラリ（OpenBLAS、ATLAS、Intel Math Kernel Library など）を使用して線形代数演算を行うため、
これは単純に書かれたC言語によるコードよりも高速に実行する（速度が落ちるが BLAS ライブラリを使用しないコンパイルも可能）。

0990デフォルトの名無しさん

2016/10/01(土) 21:22:46.97ID:ZWQ5J0j0

>>989
それってPythonが機械学習に強いんじゃなくて
機械学習に強いライブラリが有ったってだけだよね？

0991デフォルトの名無しさん

2016/10/01(土) 21:24:03.81ID:ZWQ5J0j0

機械語には速度が重要だから、NumPyはC言語で作られている。
ならば機械語に強いのはC言語ということでは？

0992デフォルトの名無しさん

2016/10/01(土) 21:59:15.05ID:63LCCJou

うんそうだけど何か問題でも？
まっRubyでは使えないからね

0993デフォルトの名無しさん

2016/10/01(土) 22:00:36.77ID:ZWQ5J0j0

いやだからライブラリが有っただけで
別にPythonなのはたまたまだよって話だよ。

0994デフォルトの名無しさん

2016/10/01(土) 22:01:14.85ID:uWwerbQv

人のふんどしで相撲をとるのはズルいと思います

0995デフォルトの名無しさん

2016/10/01(土) 22:05:23.94ID:ZWQ5J0j0

つまりPythonを過大評価しなさんなってこと。

これは別にPythonだけに限った話ではなく、
Rubyがウェブに強いのも単にRailsがあったからで、
JavaScriptがクライアントサイドウェブアプリに強いのも
たまたまブラウザ用に作られたから。

言語の違いなんてそんなもんさ。わずかな違いはあっても大差はない。
何かに普及するのは言語そのものではなくて、それの置かれた環境や
フレームワークやライブラリの力によりものだよ。

フレームワークやライブラリに比べれば言語による開発効率なんて
微々たる差しか生まれない。

0996デフォルトの名無しさん

2016/10/01(土) 23:33:42.43ID:rAdXsmVI

PythonにNumPyがあるのはそもそもそれ以前から科学技術計算にPythonが補助として用いられていたからで、
元を辿ればスクリプトの中では数値の扱いに一貫性があって数値計算に適していて、
シンプルで教科書の疑似コードに近いシンタックスのため情報科学を専門としない理系には馴染みやすいという
Pythonの性質に行き着く。
同様にRailsがRubyを選んだのも、自由度の高さやコールバックの記述のし易さ、
メタプログラミングといった性質がWebフレームワークのためのDSLとして適しているように思われたからだ。
確かに実用的には言語自体にそれほど大きな差はないかもしれないが、
コミュニティやエコシステムが発展していく上で人々の「好み」というのが非常に重要である以上、
言語の差には大きな影響力があるんだよ。

0997デフォルトの名無しさん

2016/10/01(土) 23:34:30.82ID:sU5CeuPC

>>990
SEなら理由は一つだけじゃない事に気づくだろうけどね。

0998デフォルトの名無しさん

2016/10/01(土) 23:42:52.22ID:FvOeAcfn

次スレ

【JavaScript】ｽｸﾘﾌﾟﾄﾊﾞﾄﾙﾛﾜｲﾔﾙ55【php,py,pl,rb】
http://echo.2ch.net/test/read.cgi/tech/1475332848/

0999デフォルトの名無しさん

2016/10/02(日) 00:09:17.49ID:TwHgj9yg

ていうかもっとそもそも論を言えば python のコードは英文に近くて読み易い。
同じことが Java にも言えるがこの点において python には敵わない。
python の半ば強引なアンダースコア(英文の空白など区切り文字全般に該当する)だらけのコードは時に英文そのものになっている場合がある。

1000デフォルトの名無しさん

2016/10/02(日) 00:16:47.63ID:kPn//wmb

今回はperlの勝ちでした

10011001

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 189日 13時間 52分 28秒

10021002

Over 1000Thread

２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。

───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
http://premium.2ch.net/
http://pink-chan-store.myshopify.com/

レス数が1000を超えています。これ以上書き込みはできません。

【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ54【php,py,pl,rb】 [無断転載禁止]©5ch.io

【JavaScript】ｽｸﾘﾌﾟﾄﾊﾞﾄﾙﾛﾜｲﾔﾙ54【php,py,pl,rb】 [無断転載禁止]©5ch.io