◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ55【php,py,pl,rb】 [無断転載禁止]©2ch.net YouTube動画>3本 ->画像>3枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1475332848/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
スクリプト言語とスクリプトではない言語を分ける定義ってあるのかな
前スレ
>>996 > 確かに実用的には言語自体にそれほど大きな差はないかもしれないが、
だからそう言ってるじゃん。
> コミュニティやエコシステムが発展していく上で人々の「好み」というのが非常に重要である以上、
> 言語の差には大きな影響力があるんだよ。
だからそれは生産性の差じゃない。好みの差。利用者の多さとかそういうもの
前スレ
>>999 > ていうかもっとそもそも論を言えば python のコードは英文に近くて読み易い。
どこが？ 理系に馴染みやすい数式に近いものが英文になるわけないよｗ
> python の半ば強引なアンダースコア(英文の空白など区切り文字全般に該当する)だらけのコードは時に英文そのものになっている場合がある。
this_is_a_pen みたいな？ｗ
それは変数名をそうつければ、どの言語でも同じことだろ。
ていうか英文そのものというのはCOBOLみたいなものを指すんだが。
冗長で読みにくい。
言語で生産性に差は生じないクン
いいじゃんそれで
これからはAIがプログラミングし改善し続けるからプログラマーがオワコンなのは確定してる
>>5 はい。言語によって生産性はないという
当たり前のことを言っていますよ？
理由はあんたが言うように、フレームワークやライブラリによって
差を生じさせる要素が排除されてるからです。
差はないわけはないが、それよりは好き嫌いとあモチベによる差の方がはるかに大きいよね
言語に差があるからそこに集まるフレームワークやライブラリに差ができるんだけど
>>10 だから今は、そのフレームワークやライブラリの有り無しで生産性が変わるのだから、
フレームワークやライブラリのある無しで使う言語を決めるべきって話。
言語を先に考える時代は終わった。生産性の要である
フレームワークやライブラリで選ぶべき。言語はどれでもよい。
>>11 どれでもよいはかなり語弊があるな
生産性ではなく、他の要素で選ぶべきぐらいじゃないとね
>>12 言語では大きな差は出ないって答えなら
どっちでもいいよｗ
じゃあドカタ仕事じゃないものの例を言ってみなさいよｗ
>>13 どっちでもはよくない
「なんでもいい」と「別に選ぶ基準がある」はまったく違うから
なんでもいいだとそれこそ無能経営者の発言になってしまう
>>16 日本語が間違ってるぞｗ
「なんでもいい」っていうのは言語の話で
「どっちでもいい」は、他の要素で選んでも構わない
（「言語によって差はない」には反してないから）
っていう話だ。
>>17 「どっちでもいい」じゃなくて「どれでもいい」だろ
人の言葉尻を捉えてとやかく言うなら自分の発言した内容ぐらいちゃんとコピーしろよ
ドカタは関数型言語とか難しくて使いこなせないじゃん？バカだから
>>18 だから言語はどれでも良いって言ったけど？
>>20 >>17 では「どっちでもいい」って書いてるけど？
>>21 どっちでもいいって言ったのは言語じゃなくて
選ぶ理由だけど？
（言語に差がないからどれでもいい。言語以外を選ぶ理由にするなら）
どっちでもいい。
>>22 差がないのは生産性だけで、他にも選択に必要な要素は山ほどあるよね？
それを「生産性」という言葉をすっぽり抜かしてしまったら、伝わるものも伝わらないよね？
>>23 だから俺は言語によって生産性に大きな差はないって
言ってるだけだけど？
誰も
とあるフレームワークがあるから○○言語を選ぶ
とあるライブラリがあるから○○言語を選ぶ
人を集めやすいから○○言語を選ぶ
のを否定したりしてませんってｗｗｗ
否定しているのはただ一つ
「○○言語は生産性が高いから○○言語を選ぶ」だけ
言語によって大きな差は生まれないのでこれはありえない。
>>24 だったら「生産性」という言葉はあらゆるレスで抜かしてはいけないはずなんだが
「生産性」というごく狭い部分にフォーカスした発言ですよ、ってのは君の論理の
最重要な前提だよね
>>25 あらゆるレスって「日本語間違ってるぞお前」みたいな
ものにはいらんだろｗｗｗ
で、どのレスに入れてほしかったのさ？
大抵入ってるはずだが？
>>24 代数的データ型があるからOCaml（関数型言語）を選ぶ
っていうのが実際に金融業界ではあるんですよ
ちゃんと言語で選んでますよ？
http://d.hatena.ne.jp/camlspotter/touch/20131209/1386582276 なぜ言語間に差がない等という明らかに現実を無視した主張をするのか
>>28 なら君、PHPで○○ヶ月掛かる仕事を
その半分でやってみせますとか言ってみたら？
半分が多すぎるなら減らしてもいいけど、
君ならどんくらい減らす？
>>31 その質問に意味があると思ってるところがペチパーの怖ろしさ
>>32 やっぱり言語を変えるだけでは減らせないのね？ｗ
>>33 何がやっぱりなんだよ俺は「その質問に意味はない」と言ってるのだが
どこからその結論を読みとってきたんだお前
意味がない理由を書いてない時点で、
>>35 理由を言わない→どう取られても構わない
なぜこうなるのか？
ペチパーには論理的な思考の推移というものが存在しないのか？
>>37 は？何を？
思考が飛躍しすぎでお前とは普通の会話ができん
ここまでのレス数39のうち、書き込んだ人間は何人なんだろう
>>38 なんで意味が無いのかだよ。
>>32 でお前言ったろ？ その質問には意味がない（ドーン！）って
えとね、反論するときはちゃんと理由をいわないと意味がないの。
誰かが何か意見を言った時、
「それは違う（ドーン！）」って言うだけじゃ違うって認められないんだよ。
そんなんで反論として認められるならば、
なんでも通用するわｗ
「これだけの証拠が有るからあなたが犯人です」
「それは違う（ドーン！）」
この一言で覆るかよｗ
似たようなフレームワークで解決する案件に限定して
>>42 その状況っていうのは、
「その問題領域を効率よく記述可能な言語」ではなく
「その問題領域を効率よく記述可能なライブラリ」があるかないかで
決まることだろ？
その問題領域を効率よく記述可能なライブラリを書けるのが
その問題領域ってなによ？
>>46 それはライブラリを使うことを前提として
開発工数に差が出るほどのものではない。
>>47 差がない理由を言ってないから全く意味のないレスだな
>>27 のリンク先は実際に仕事で使ってる人間が
具体的な理由付きで言語で選んるって言ってんだから
全く勝負にならない
ID:A7Nl1eL6 はとりあえず
>>27 を見ろよ
>>48 よし、差がない理由を言ったから反論待ちだなｗ
多分、フレームワークやライブラリで片がつく程度の仕事しかしてこなかったんだろうな
でなければ
>>27 にちゃんと反論するもんな
そもそも
>>27 にはOCamlによって開発工数が減ったとは
書いてないので、反論する必要もないんだよ。
せやな、例えばここなんかどうだ？ サンプルがあるぞ。
http://www.geocities.jp/m_hiroi/func/ocaml.html この中で（別の場所でも良いけど）OCamlで書いたらこんなに短いけど、
他の言語では長くなるっていう例でも言ってみてくれ。
もちろんフレームワークやライブラリを使うのは有りだ。
（だってそもそもフレームワークやライブラリがあるから
言語による開発工数の差はほとんど無くなると言っているのだからね）
>>53 > 事実、この言語化によるパワー、金融商品の代数的表現を使って LexiFi はデリバティブのモデル化、
> 評価、マネージメントなどの高度なシステムを少人数、短期間で開発し、現在に至っている。
あれ？書いてますけど？
>>55 それは比較じゃない。少人数・短期間で開発というのは
どんなフレームワークでも謳い文句にしている。
>>56 選んだということは、比較して決めたということでしょ
比較して選んだ結果、少人数、短期間で開発しと書いてるんだから、開発工数が選んだ理由でしょ
まさかhello world書いて言語の生産性に差が無いと言い出すとは
じゃあ、それ以外のネタいいなよ。
でも数ヶ月の差がでるような極端な例じゃないと差があるとは認めないんでしょう？
生産性に差がないクンは、たんにHelloWorldに差がないという主張だったというオチか
都合の悪い部分は無視か屁理屈だもんな
といって差が出る例を言わないのを
HelloWorldでお金もらえるのか
<div id="Aid" class="Bclass">XXXXX</div>
というのがあったとき、
document.getElementById("Aid").innerHTML = "";
とすると、
<div id="Aid" class="Bclass"></div>
となりますが、このclass="Bclass"というのも削除して
<div id="Aid"></div>
だけには出来ませんか
greasemonkeyを使っていて、これが残っていると枠が残ってしまいます
ちなみに、classList.removeを使うと、classは削除されますが、
<div id="Aid" class=""></div>
となります。class=""は取れませんか
ここはHelloWorldの生産性を議論するスレです
>69
そもそもclass=""を消したいのは何故？
それで何か変化あるのかな…？
無理矢理消すなら
<div id="Aparent"><div id="Aid" class="Bclass">xxxx</div></div>
にしちゃって、AparentのinnerHTMLを変更するのじゃダメかい？
HelloWorldって馬鹿にされて恥かいたからって
まあ実際ペチパーの仕事はHello, worldと大差ないのばかりだからなw
いい加減出てこいよ。
ちっHello Wolrd野郎は逃げたか。
お前ら、あんまり Hello World を馬鹿にすんな
世の中には、バージョンアップしただけで Hello World が
動かなくなる後方互換性を完全無視したスクリプト言語もあるんだぞ
http://echo.2ch.net/test/read.cgi/tech/1413113999/128/ >>69 removeAttribute じゃだめかい？
つかもうスクリプトの時代は終わったよね
>>54 問題領域に対する有用なフレームワークやライブラリが特定の言語でしか整備されていなければ開発工数の差になると思うわけだが。
ディープラーニングやろうってときにスレタイの言語の中で Python 以外を選ぶ馬鹿はいないだろ。
ところで
>>50 の意味がわからないのだが。ウェブページとして Hello world を表示するだけなら ruby でもフレームワーク無しでこれでよいのでは？
#!/usr/bin/ruby
print "Content-Type: text/html\n\n"
print "Hello, world!"
少なくとも俺の Apache の環境では mod_cgi を有効にしてこれで動いた。
>>80 自分はJSでやってる。
ディープラーニングって手段であって、
することに合わせた細かい調整やノウハウが重要
まだ発展途上でどの言語でも整備されてるとは言えないので言語は関係ない。
よくあるライブラリは結局皆がもう何度も試したようなことにしか使えない。
自分は２年目から素フレームワークと自作ライブラリに切り替えた。
エンコーダとかだとビジュアルも重要だし、モバイルから進捗を見るのなどにもWebが便利だしね。
>>82 back propagationとかどうしてんの？自動微分のライブラリも自作してんの？
まさかシコシコ自分で偏微分をコーディングしてるとか無いよね？
ど素人が知ったかぶりした挙句に
素人の間では、AIはデータが命でありプログラムの時代は終わったとされている
なんでJSでディープラーニングやってるなんて嘘つくんだろう
色々な説がある
JSerが無知でバカで嘘つきってことは周知の事実だから
>>83 自分は所謂日曜プログラマ。仕事は一切関係ない。
なのでDLは手段と書いたがシコシコする事自体が目的というのも半分。
技術自体に興味があるし、論文読んで自分なりに取り入れてみたりする行為が一番好き。
他にも例えば最近JSに入ったSABやSIMDを使うライブラリは無い（無かった）
そういう最新の技術を使いたいという興味目的もあるし、
実際パフォーマンスを突き詰めたいのでそれに沿うように作り直すことになる。
あとゲームの評価関数等だと終わりが無い、最適解への道のりが遠いから
ずっと調整し続けないといけない。
>>89 趣味なら好きにしたらいいけど
ただ自動微分もSIMDもCUDAもサポートしてるPythonのDLライブラリを使わず、
ちょっとネットワークの構造や深さや発火関数を変えるだけで
偏微分をシコシコ書き直してデバッグしてるのって
側から見るとバカみたいだから気を付けた方が良いよ
いやまあ、Pythonじゃなくてもいいや、何か適当なライブラリは使った方が絶対良い
まぁまぁ、日曜プログラマ程度なら使い慣れてる言語でちょこちょこ楽しむってのも
>>80 > 問題領域に対する有用なフレームワークやライブラリが特定の言語でしか整備されていなければ開発工数の差になると思うわけだが。
フレームワークやライブラリが特定の言語でしか整備されていなければでしょｗ
特定の言語でしか整備できなければ、言語の差になるが、
特定の言語じゃなくても整備できるだろうね。
だからそれは言語の差ではなくて、フレームワークやライブラリの差
>>81 それはHello World専用じゃんｗ
なんでお前Hello Wolrd専用の話をしてるの？
ウェブフレームワークはいろいろやることがあるって話をしてるのに、
HelloWorldで生産性を語る君にいわれてもなぁ……
HelloWorldで生産性を語ってるのはあんたでは？
どうせhello would以外何も書けないくせにw
相変わらず前提がおかしいっていうか想像力が乏しいねぇ…苦笑
>>79 C#ってどんなの？ 特徴教えて
C++とは大分違うの？
C#はC++とはまるで違う
>>99 それで代数的データ型による差はどれくらいあんの？ｗ
>>103 それすら知らんで「差はない」とか言ってたの？
差はないと言い切るからには当然知ってるはずだよね
>>102 > 惜しむらくはWindowsでしかまともに動かないこと
iPhoneでC#アプリが審査に通るワケ
http://www.atmarkit.co.jp/news/200901/29/mono.html > iPhone向けにC#で書かれたゲームが40本以上存在する――
もう7年も前からこんな状態なのに今頃何をいってんの？
あんたが言ってるまともに動かないっていうのはC#という言語じゃなくて
Windows向けのライブラリでしょ。
iPhone、Androidで動くゲームの多くがUnityを使って作られているがその言語はC#
そしてもう一つのクロスプラットフォームの開発環境のXamarinもC#
今の時代クロスプラットフォームで開発しようと思ったら、
JavaScriptかC#なんだが。
>>104 無いものを証明しろといわれても困るんだがｗ
差なんてどこを見てもないんだから
何も言えるわけがない。
これは悪魔の証明といわれている類の問題でね。
無いのに比べて有るほうを証明するのが簡単なんだから
有るということを証明しましょうって話。
>>106 そもそもお前、代数的データ型が何か説明出来んの？って話よ
これは別に悪魔の証明じゃないぞw
なんでわざわざ遠回りしてるんだ？
>>108 知らなかったら差がないことも知らないだろ？
知ってるからこそ差がないことが言えるのに
>>105 40本って…そんな誤差レベルの本数の話されてもね
>>108 プログラマは、自分が基本的な知識と思ってる事すら知らない奴の言うことはハナっから信用しない
いくら言葉を重ねてもね
残念ながらそんなもんです
>>109 お前、議論ってものが分かってないのか？
反論っていうのは、相手が知らない点、見落としている点を突くことなんだよ。
だから、穴があると思ったらそこを突っつけばいいじゃん？
なんで遠回りしてるんだ？って聞いたのは、
穴を見つけたはずなのに、それは穴ですか？って俺に聞いてるからだよ。
俺が穴ではありませんって言ったらお前諦めるわけ？
俺が穴ですっていったら、お前はそこで満足して諦めるわけ？
どっちにしろ、お前はその穴を突っつく。
つまり開発効率に差があることを指摘しないといけないんだから
さっさと指摘しろって言ってるわけ
>>110 > 40本って…そんな誤差レベルの本数の話されてもね
7年前の話だぞｗ
今はゲーム開発で独占的な地位を築いている
>>112 簡単じゃん
お前はHello World以外のあらゆるシステムで開発効率に差が出ないと言ってるんだから
そうじゃない例もちゃんと知ってるんだよな？という確認をしてるだけじゃん
そうじゃなかったら「あらゆるシステム」の部分は誤りで、「俺の知ってる狭い範囲のシステムでは」
と言い換えなければいけない
な？簡単だろ？
> そうじゃなかったら「あらゆるシステム」の部分は誤りで、「俺の知ってる狭い範囲のシステムでは」
俺だったら、相手が知ってるかどうか確認せずに知らないと決めつけて、
>>115 まーだ分かってないんだな
「お前の知らない範囲のシステム」については「お前は開発効率が変わらないことを知らないだろ？」
と言ってるんだよ
「俺の知らない範囲でもあらゆる範囲で俺の法則が適用できるんだ」なんて理論が通じるとでも思ってんの？
>>117 俺が知らないっていうのなら、俺が知らないことを
言ってみなさいよｗ
俺が知らないことを指摘することは、
俺が間違っているということにはならのだよ？
>>107 でそうお前も認めたしな。
> そもそもお前、代数的データ型が何か説明出来んの？って話よ
> これは別に悪魔の証明じゃないぞw
質問が「代数的データ型が何か説明出来んの？」に変わってる。
この質問は言語の違いで開発効率に差があるかどうかの話ではない。
だからどう答えても俺の主張に影響はない
>>118 代数型データを知らない以上、開発効率に差がでないなんて一言も言い切れないよな
つまり、お前の理論は間違い、それだけ
お前が代数型データを知っていて、それを使う範囲でも開発効率が変わらないと説明できるなら
お前の理論はその範囲では合ってると証明できる
つまり、証明義務はお前の方にあるんだよ
>>102 なにいってるんだ？MicrosoftとかC#は後方互換を常に重視してるだろ
さすがに互換性のために利便性を捨てるJavaほどではないが、過去のソースやバイナリはほとんどの場合うごく
あれで後方互換無視って言ったら数えるほどしか言語残らんぞ
マルチプラットフォームもUnityに限ればかなりすごいぞ
パソコンから任天堂/ソニーゲーム機、スマホまでなんでも動く
ポケモンGoとかもそうだ
>>120 ＞ C#は後方互換
じゃあ、C++のコードは動くの？ 開発言語の後方互換ってそういうことだよね
C#の前はJavaなのか。 なら、Javaは動く？
>じゃあ、C++のコードは動くの？ 開発言語の後方互換ってそういうことだよね
>>93 >フレームワークやライブラリが特定の言語でしか整備されていなければでしょｗ
現実に、今は特定の言語でしか整備されていない。
現在の状況における現実的な議論としては、言語の差かフレームワークの差かはともかく、言語選択によって開発工数に差が出ることは事実。
>特定の言語でしか整備できなければ、言語の差になるが、
>特定の言語じゃなくても整備できるだろうね。
>だからそれは言語の差ではなくて、フレームワークやライブラリの差
「整備できるだろう」という憶測だけで理由が一切示されないまま、直後に「だから」と繋げて結論を断定して終わる論理展開はおかしい。
特定の言語でしか整備されていないフレームワーク目当てで
そのフレームワークを書いた人間は言語で選んでるんですけど
ある種のフレームワークを書こうと思った時、特定の言語機能（例: 代数的データ型）があるかどうかで
>>121 ネタか釣りだと思うが、初心者が間違えるとかわいそうなのでマジレスするとそれは後方互換じゃない
後方互換は同じ言語の前のバージョンと互換性のあること
C#はいくつかの言語を参考にしているが、まったくの新規の言語なのでC#の前は存在しない
>>125 > そのフレームワークを書いた人間は言語で選んでるんですけど
それは言語を選んでいるのであって、開発効率に差があるということではないよ
言語を選ぶ理由はいくつか有る。自分がたまたま詳しかった言語とか
フレームワークを作るのに便利なライブラリが有ったとか、
対応しなければならない環境が使える言語がそれしかなかったとかね。
>>126 > ある種のフレームワークを書こうと思った時、特定の言語機能（例: 代数的データ型）があるかどうかで
> 書きやすさが全然違うんだよね
だからそう思うならば、その理由を書けばいいだけの話。
> それは言語を選んでいるのであって、開発効率に差があるということではないよ
>128
>>131 > 差がないことを言いたいのであれば、それを証明する義務はお前にある
上の方に書いた。当たり前だが俺が知っている範囲でだ。（知らないことを書けるわけがない）
で、お前は俺より詳しくて知ってるんだろう？なら知ってることを書けよ。
俺が証明するとしたら差がないという答えにしかならないんだが分かってるかい？
お前のために差があることを俺が証明するわけがないだろうｗ
差がないと証明する義務はすでに果たした。あとはお前が俺の知らないものを持ってきて
差があると証明してくれるんだろう？早くしろよ。
知らないことを知ることができるとワクワクしながら待ってるんだからさｗ
http://dic.nico video.jp/a/%E7%84%A1%E7%9F%A5%E3%81%AB%E8%A8%B4%E3%81%88%E3%82%8B%E8%AB%96%E8%A8%BC
無知に訴える論証（argument from ignorance）、あるいは無知論証とは、
「Aだという根拠がない。だからAではない」または「Aでないという根拠がない。だからAだ」
というパターンの、「根拠が無いこと」だけを根拠にして何らかの結論を導いてしまう、間違った論理のこと。
なお後述するが、「新しい根拠が無ければ新しい説は言えない」と考えても良い。このほうが、実践的には分かりやすく間違いが少ないだろう。
>>133 > 俺が証明するとしたら差がないという答えにしかならないんだが分かってるかい？
証明できるんならそれでいいんじゃない？
> 差がないと証明する義務はすでに果たした
まったく果たされていない
お前の知らない範囲については以前として「不明のまま」だ
つまり、お前の理論は現時点では、「HelloWorld などの俺の知ってる狭い範囲では言語によって
開発効率に差は出ない」ということしか証明されていない
>>135 で、開発効率に差がないという証明は？
お前が言ってるのはAだという根拠がないといってるだけ。
>>136 根拠がない以上、「どちらか分からない」が正解になる
「Aである」の根拠がないことを言った結果、「Aではない」になるわけではない
「Aであるかもしれないし、Aでないかもしれない。まだ証明されていない」という状態になるだけ
そこから「Aである」ことを主張したいなら、それを証明する義務は「Aである」と言った人間にある
俺がわかってる範囲・・・「差がない」
>>138 それでいい
お前の言ってる範囲はごく狭いことだけ認識してくれて、今後その主張をするときは
「HelloWorld周辺の俺が知ってる範囲では」という前提条件を忘れないようにな
人は卵から生まれることはないのか？
>>139 じゃあ、
俺の知ってる範囲では、差がないというのが事実だし、
俺の知らない範囲で差があるという証拠は一つも出ていない。
ということにするよｗ
>>140 証明されていない分野については、感覚的におかしかろうとそれが論理というものだ
お前はお前の感覚で全分野でお前の論理が成立すると思い込んでるようだが、それは論理ではない
論理は「お前の知ってる範囲だけ」で成立するものだ
>>141 > 俺の知らない範囲で差があるという証拠は一つも出ていない。
差がないかどうかも俺は知らない、という言葉をつけておこうな
お前「お前の知り合いという狭い範囲で悪魔がいないからといって
>>144 うん、それでいいと思うよ
科学者ほど神を信じてるというしな
結局、悪魔の証明を言ってるだけか。
>>146 お前は悪魔の証明の使い方を間違ってる
悪魔の証明は知ろうとしたら知ることができる範囲の証明ができないことは一切言っていない
お前は代数的データ型について知ろうとすればできるのにその証明をしようともしていない
これは悪魔の証明ではない
だから代数データ型を知った上で差がないと言ってる。
>>148 知った上で差がないという説明のレスはどこにあるの？
たとえば、代数的データ型のHelloWorldとも言える木構造データを
>>150 やっぱりHelloWorldでしか比べてないじゃんというｗｗ
そりゃ、簡単なプログラムで差が出るわけないよなー
>>124 ポイントをずらした反論で逃げているね。
・言語（＋フレームワーク）の選択によって開発効率に差が出る
・「特定の言語じゃなくても（フレームワークを）整備できる」という主張には何の根拠もない
については特に反論しないということでOKかな
>>151 > 差が出るわけない
いや、逆だろ
HelloWorldレベルでも歴然とした差が出るんだな これが
Rubyじゃ、どうひっくり返ったってシンプルには書けない 書けたっぽくても欠陥だらけ
代数データ型を理解してないとわからんかもしれんけど
HelloWorld氏は代数的データ型どころか木構造も分かってなくて、
>>150 を怪しい機能を使ってHelloWorldを書けって要求だと誤解してる予感
もうそろそろ代数的データ型で差が出るという
>>150 > 書いてみてもらえば差があるかないかはっきりすると思うよ
ならあんたが書けば良いんだよｗ
俺の勝利条件：言語の違いでは開発効率に差がないという結論にすること
横レスするけど、なんだかここ数日、変な流れになっているなあ... >>154 ,153,150,147,119,107,99,63,27)、 http://ci.nii.ac.jp/naid/110002720151/ https://www.amazon.co.jp/dp/4817160160 >>154 )、当然、その原典である >>158 代数的データ型を関数型言語（元ネタはOCaml）で書くと効率いいですよ、ってのが
>>27 の意見
なんだけど、HelloWorld君はそもそも代数的データ型を知らないので、この分野に関して開発効率の
話はなにひとつ言えないはずなんだよね
言えない以上、開発効率が言語によって変わらないという主張はできないはずなのに、それを
声高に主張しつづけるという論理的に明らかにおかしい状態になっちゃったので、周りのみんなが
面白がって「代数的データ型は？ねえ？どうなの？」ってからかってるのが現状かと
HelloWorld君は「言えないけど、差があるという事実がないので差がないことが正しいんだ」という
これまたわけの分からない主張を一切変えないのでまったくかみあってないというｗ
効率いいですよっていうだけで、
>>161 変わらない理由も言ってないよね
そりゃ、分からない範囲のことは言えないのが当然の話
まずはそこを認めるところから始めないと議論にならないよ
absence of evidence is not evidence of absence (証拠の量と結果は比例しません)
>>162 変わらない理由は上の方で言ってるよ。
それに対して、代数的データ型がある場合は違うって
言ってきてるんだから、なぜその場合だけ違うかを
説明しないとだめ。
>>164 君の説明から分かることは「あぁ、HelloWorld君は代数的データ型を知らないんだね」ということ
だけだよ
まずこの事実を認めよう
そこからじゃないと議論は始まらない
>>164 「ほら、HelloWorldじゃ言語の差は出ない！証明完了！」って言ってるだけじゃんw
なおHelloWorldより難しいプログラムは分からない模様
>>165 > HelloWorld君は代数的データ型を知らない
もうそこは自明でいいんじゃないかなと思う
本人も
>>157 で「頑張って調べ」ないと代数的データ型すらわからないと暗にギブアップ宣言しているし
「敗北する努力をする訳がない」と、代数的データ型を前提とすることで敗北が確定することを
自ら予見できているわけだから
なんでこう頑なに代数データ型で差がある事を
もしかして代数データ型君は代数データ型って言葉を
HelloWorld君にとってはHelloWorldが本質なんだねw
ここにhogeという（関数型ではごく普通の）言語機能がある
これはネットでよく見かける
>>172 しゃあねぇなあ
じゃあ、ここにある評価器とconnection_infoを書いてみてよ
http://ymotongpoo.hatenablog.com/entry/20111105/1320506449 >>27 みたいな仕事はこういった（もちろん。もっと複雑な）評価器を1から書く必要があるからね
あとconnection_infoはリンク先の実装と同じく不正な使い方を出来ないようにしてね
>>170 > HelloWorld君にとってはHelloWorldが本質なんだねw
HelloWorldの"部分"が本質なんだよ。
この部分が本質だから、他は変えずに
この部分（HelloWorldの部分）だけを変えれば良い。
そしてこの本質的なコードはどの言語でも大差ない。
だから言語によって開発効率に差がないというわけ。
HelloWorldみたいなちっちゃいものではちっちゃい差しか見えないもんね
>>176 じゃあ、HwlloWorldをオブジェクト指向で作ってみて下さい
>>175 じゃあ
>>173 の本質的な部分のコードを書いて
言語で差がないことを示してよ
>>169 フレームワークを用意しなきゃいけない言語とフレームワーク相当の機能がコアに組み込まれてる言語があるから、
フレームワークを用意しなきゃいけない言語はフレームワークを作るコストが上乗せになるよね
ってだけの話なのに、君はどうやら、ありとあらゆる問題に対して既に素晴らしいフレームワークが提供されている理想郷に生きているようだ。
仙人か。
言語で生産性に差があるって事で決着がついたので、
>>179 そもそもコード書けるかどうかも怪しいレベルだね。ちょっと本職が突けばこの通り
Javaなんて10年以上前に捨てました。ファウラーとかが、主婦が家事のウンチク垂れるのと本質的に同じレベルで、無意味な能書き垂れてた頃ね。コードを1文字書くまでに膨大な思案を要求されるようになった。芸術作品じゃないんだから、そんなもん、オワコンでしょ。
Javaというか、多くの昔からある静的な言語が
>>185 > だって、何も読まずにいきなり作れる自信があるからね。
使い捨てのスクリプトならそうだろうけど
ちゃんとしたものを作ろうとしたら大変だよ？（JavaScriptに限らない）
まずビルド環境を整えないといけない。
そうしないとテストやカバレッジ測定すらできないから。
ある程度の規模になればフレームワークは必須だけど、
Reactを使うならばBabel（ECMAScript2015〜 + JSX）の導入がほぼ必須。
Angular2を使うならばTypeScript（JavaScriptの上位互換）の導入がほぼ必須
ちなみにECMAScript も TypeScriptもIE6ぐらいの時代のJavaScriptとはぜんぜん違う。
文法はPythonに劣らないどころか超えてると言ってもいいぐらいに改良された。
もちろんその反面、文法だけみると覚えることはPythonよりも多いがｗ
そういった環境でモジュールを使うならばビルド環境に合わせたモジュール管理の仕組みを使う。
簡単に使えるが、環境を整えるまでが大変。
パフォーマンスを上げるために複数のファイルを結合したら圧縮したりするが
これまたビルド環境を整えろという話につながる。
大変だがちゃんと整えれば静的解析でリアルタイムにエラーを教えてくれるようにもなる。
atom + eslint で構文エラーやスペルミスをリアルタイムに教えてくれるのは便利。
ここまでやったことないでしょ？
つまりあんたが何も読まずに作れるっていってるのは、何も読まずに作れる範囲のことしかしてないからなだけ。
>>187 HelloWorldより難しいプログラムを作れるようになったか？
文法ねぇ
>>189 それもまた「何も見ないで作れる」っていうのが
簡単なことしかやってないだろうなってわかるよねｗ
>>189 負の遺産ではなくて、言語の仕様に対して実装が多すぎて、仕様を大きく変えても実装がどうせ
追いついてこないという実情があるんだろうね
とはいえ Microsoft が古い IE をばっさり切ったのでその辺の事情も変わってくるかもしれない
とか言ってるとスマホ全盛時代になって古いスマホブラウザに引っ張られるというこれまた新たな
ネックが生じてしまう時代になってしまったのは皮肉というべきか
と言っても仕様を決めてるTC39メンバーにはハードベンダーや研究者も居るけど
WEB+DB vol.94 が出た
>>173 結局、
>>172 が指摘してるように「主張はすれど根拠は示さない」し
「根拠を不思議と出し渋る」しかないみたいだね
おそらく代数的データ型君は「自分の言葉では根拠を述べることができない」んだろな
だから、他人の書いた文書のリンク先しか書けない
代数的データ型を分かった気でいるけど実は無知であることを
代数的データ型君本人が自覚できていないんじゃあ、しゃあないわ
> じゃあ、ここにある評価器とconnection_infoを書いてみてよ
しゃあねえからRubyで書いてあげた
https://ideone.com/WpazqE 当然、「connection_infoはリンク先の実装と同じく不正な使い方を出来ない」よ
評価器については、
>>173 のリンク先文書にJavaのコードがあるから省略しとく
>>194 そのconnection_infoは実行しなくても静的にエラーを弾けるの？静的検査できないなら同等じゃないよ
それと、あのJavaの評価器でOCamlと同じ生産性だと思えるなら話にならない。冗長で書きにくいし可読性も最悪じゃん
つーか、ConnectionInfoのconnection_stateに何でも値入れ放題じゃん
>>195 ,196
おいおい代数的データ型君達よ、論点を都合良くずらすなよ
今ここで議論しているのは「代数的データ型が生産性に与える影響」だろ？
静的型付けの利点、そしてML/Haskellといったモダンな関数型言語が提供する
完全な型システムとそれがもたらす型推論による簡潔なコードという利点なんて、
とっくの昔から何度もこの板では議論されている訳で、何を今更の話をしてんのよ
結局、代数的データ型君達は、型システムの概念と代数的データ型の概念を
ごっちゃに理解して分かった気になっているだけだろ
だから代数的データ型の利点に関する根拠として、
>>173 のリンク先文書を示して
何の疑問も持たず平然としているんだよ
>>196 >つーか、ConnectionInfoのconnection_stateに何でも値入れ放題じゃん
動的型付け言語であっても実行時に型検査はできるよ
https://ideone.com/IUv2v2 そして繰り返すけど、型システムの概念と代数的データ型の概念はごっちゃにすべきではない
たとえば代数的データ型を備えた動的型付け言語や、型推論の無い静的型付け関数型言語を想像してごらん
そういった想定の元であっても明解さを失わない代数的データ型の利点とその根拠を示せと言ってる訳
つーかさ、いいかげん代数的データ型の定義とその利点/根拠を自分の言葉で語ってみろや
え？ 普段の仕事で代数的データ型（っぽいこと）を
>>198 ＞しゃあねえからRubyで書いてあげた
＞
https://ideone.com/WpazqE ＞当然、「connection_infoはリンク先の実装と同じく不正な使い方を出来ない」よ
>>173 で自信満々にこう書いておいて、指摘されたら慌ててアサーション入れまくるのクソワロタw
>>200 あ、間違えた
>>173 じゃなくて
>>194 だった
>>198 > 多くの必要な不変条件を型の中に埋め込みました。いまや不変条件は型の一部なのです。コンパイラはこれらの不変条件を破るコードを見つけ、拒否することができます。これは手作業で行う仕事を減らし、手で管理するよりも信頼できます。
ごめん。引用しちゃったw
君の手作業でアサーション入れまくりのコード（いわゆるテストの一種）より静的型検査の方が手間が少なく間違いにくいのは自明ですよ
どこかの理想の世界ではそうかもしれないけれど
>>198 ConnectionInfo.class_eval do
def foobar(s)
@connection_state = s
end
end
c.foobar("Hello World!")
>>203 勿論そうだけど、不正な使い方できるコードを自信満々でアップしちゃうくらいには
手動は間違いやすいって事だよ
なんでいまさらタイプセーフありがてぇ
論よりコードっていうけど、ほんとコードの提示って怖いね
altJSでは、大規模開発では静的な、Haxe(ヘックス)。
静的は静的で、ライブラリをアップデートすると壊れる、
静的型の信者じゃないけど、これじゃ同等とは言えないだろ
>>209 だから、作るものによって静的が向いてるものもあれば
動的が向いてるものもあるよな？って単純な話なんだけど
HelloWorldおじさんは違う意見みたい
そうだよね。作るものによってというのが重要。
>>212 お前が差が出ないのを示せたのはHelloWorldだけだろw
>>202 >>173 のリンク先文書の中から >>173 文書の type connection_state = | Connecting | Connected … で始まるコード)、 >>202 が引用したパラグラフで >>173 リンク先文書の著者が読者に伝えたかった主旨であって、静的型付けとは無関係なのよ >>202 の代数的データ型君よ、これで代数的データ型の利点は理解できたかね？ >>214 それは代数的データ型の利点じゃないな。
代数的データ型を使うという手段が目的となっていて
その手段を使おうとすると問題が発生する。
自ら苦行の道を進んで、苦しいのが解決したという
つまりマイナスがゼロになっただけなのに、
（マイナスの状態から）増えたという変化の一部しか見てない。
>>206 >>198 で書いたけど、代数的データ型君は代数的データ型に関して
無知だということに気付いたけど、その事実を認めたくないんだろね
だから
>>211 みたいに、代数的データ型の議論を「静的 vs. 動的」という
対決構図へすり替えようと必死なんだと思われ
そもそもこいつは、フレームワーク無しの素のRubyでHelloWorld書くのと、同じように素のPHPでHelloWorld書くのでPHPの方が楽だって認めてるんだろ
>>217 吸収してしまって、その違いが些細なものとなってしまったわけですよね？
>>188 そのアンカーは>186のが相応しそうだが
>>214 そんなゴタクはいいから、さっさと
>>210 みたいなコードが書けないrubyの例を見せて下さいよ
それともC1カバレッジのテストでもやるの？
コード書くとボロが出ちゃうから、またコード書かずに長文書く書くマンに逆戻りかな？w
>>220 ,221(ID: kMzukS4D)
>>216 でも書いたけど、ホントに代数的データ君は議論の焦点を
代数的データ型から静的/動的へすり替えようと必死だねえ
ねえ、どうしてそんなに必死なの？
>>210 氏の指摘は代数的データ型に関するものではなくて、
型付けが静的/動的という違いに起因するもの
動的型付け言語であり、言い換えると型システムを持たないRubyでは、
パターンマッチの網羅性に相当する型エラーをコンパイル時には検出できない
繰り返すけど、こんな静的/動的の話はこのスレの住人であれば当たり前だよな？
ただし実行中であれば動的に型検査できる
特にRubyであれば簡潔にコードとして表現できる
コードは代数的データ型の議論が終結したら示すよ
で、代数的データ型君は代数的データ型について理解できたのかな？
＞特にRubyであれば簡潔にコードとして表現できる
OCamlがスッキリ書けるのは
簡潔じゃないものを簡潔だと言ってるから違うと言っただけだけど？
>>218 服を着るようになったから人間に肌の色の違いはない
って言ってる？馬鹿なの？
>>224 >>27 みたいな仕事はお前から見たら特殊な用途だと思うけど、
それでも生産性に差は無いんじゃなかったっけ？
それとも用途によっては差が出るに意見を変えたの？
>>228 俺は差が0とは言ってないよ。殆どないと言ってる。
殆ど無いという理由は、大きな全体があってその一部だけしか差がないから。
ベンチマークの話に例えよう。俺が使っているクラスライブラリがバージョンアップして
「○○クラスのオブジェクトのインスタンス生成が100倍速くなりました。」と書いてあったとしよう。
これで俺のアプリが100倍速くなる！・・・なんてことはいわない。
当たり前だよな。○○クラスのオブジェウトのインスタンスを何個生成するかによって変わるんだから。
一回のインスタンス生成にかかる時間が100マイクロ秒から1マイクロ秒に速くなった。
たしかに100倍だがそのオブジェクトを1000個しか作らないなら100ミリ秒が1ミリ秒になるだけ。
生産性もそれと同じ。特殊な用途であることは誰も否定しないだろう。
（先に俺が言った「嘘だと思うのなら、今までの人生で勉強以外でOCamlで
書いたコードを言ってみたら良いよ」に答えてないのがその証拠）
特殊な用途というのは使われる機会が少ない。プロジェクト全体のごくわずか。
だからそんなものは生産性に大きな差を与えるものにはならない。
「特殊な用途」がプロジェクトの殆どを占めることだってあるかもしれないだろ
みたいな話はいらんからね。そんな言い訳する代わりに「今までの人生で（略）」に
答えればいいだけなのに答えないって、こ・と・はぁ〜って思うだけだから。
HelloWorldが仕事の大部分を占めればそうなるわな
普通の人に仕事の大半がそうだろうなｗ
>>227 どんな言語でもフレームワークを使えば同じように書けるから言語による差はない
って言ってる？馬鹿なの？
前提も頭も狂ってるから結論もおかしくなってることに気づかないバカ
>>232 差がないのは言語による開発効率ね。
言語に違いは有っても開発効率に大きな差はない。
>>229 コード書けないHelloWorld長文おじさん
>>234 不正解
理論上は開発効率に大きな差があるが
現実は下請けに回ってきた時点で言語や環境が決められているか
既に決まってスタートしているので考える余地がない
が正解
下請けの反対は元諸けと思うが
このドカタには内製って発想がないのかな？
>>27 を読んでフツー多重下請けの話だと思うか？
>>237 上流になるほど「安い人を大量に集められる言語」って基準で選ぶんだよ
そこに開発効率なんて言葉はない
あと、上流は１つだけの下請けに出すわけじゃないからね
かつての日本は研修以外ではコード書かなくてもSEとかなれましたから。
>>241 今もそうだよ
ただ、SI一辺倒だった時代ではなくなってきてるので、比率は下がってきてるけどね
SEなんて属人化をひたすら廃することでリスクマネジメントができてるとか勘違いしてる連中だからな
コードを書かない人間をクビにする作業が忙しくてコードを書けないんだろ
>>239 俺は元請けは言語使わないって言ってるんだよ。
その俺に元請けは安い人を探すっていわれたって、
えぇ、だから言語使わないでしょ？としか言うことがない。
>>245 使わないだろうけど決定はする
そこに開発効率なんて基準は入らない
奴隷がいかに集められるか、ということだけが基準となる
だからなんで俺にそれをレスするんだよ？
>>247 下請けには言語の決定権なんてない、という
>>236 の意見に賛同している
下請けに決定権がないのが、言語の違いで開発効率に差があることの根拠？
>>249 言語による開発効率なんて意味がないということ
所詮は開発効率なんて何も考えてない上流が決めることなんだから
大事なのは奴隷をいかに集められるかということだけ
言語の違いで開発効率に大きな差がない上に、
>>251 そういう人月神話を信奉した結果が現状の日本のSI業界の悲劇的状況なんだけどね
プログラミングは属人性が恐ろしく高い世界だという現実にいつ気づくのだろうか
>>252 知らんがな。言語による開発効率の差はごく僅かって言う話と関係ないし。
日本が嫌なら海外にでも行けば？
海外ならば、ぜんぜん違う言語を使ってるはずだって
夢見るのも悪くないと思うよｗ
あ、ぜんぜん違う言語＝英語とかそういうのはいらないからｗ
>>253 だからそんな話は意味がないって
言語なんて開発者が決める話じゃないんだし
プログラミングは属人性が恐ろしく高い
>>254 それは日本の話だろ？ｗ
海外は開発者が言語を選んでいるんですよ。
言語ランキングはいまさら出さなくてもいいよな？
日本と大差ないし。
>>255 属人性が高いということは言語による差が大きいということだよ
あらゆる言語を操れるスーパーマンなんていないからね
とりあえず職人さんが忌避しがちなPHPとかは真っ先に対象から外すべきだね
> 属人性が高いということは言語による差が大きいということだよ
>>256 日本人が日本の話してるのはごく自然なお話だと思うんですが？
君は日本以外で仕事してるの？
>>258 奴隷ばっか集まる言語なんて意味ないだろ？
属人性の意味間違ってるなーｗ
説明するのがめんどくせーから探してきた
http://d.hatena.ne.jp/Nagise/20090302/1235997646 >
> ソフトウェア開発の属人性の誤解
>
> 属人性の排除が狙うところってのは「その人しかやり方を知らないよ、秘密だよ」って
> 作業をなくす話で、技能的にその人しかできる人がいないって話題じゃないんだ。
> ソフトウェア開発の属人性を語るときにここを勘違いしていると議論にならない。
>>259 > 君は日本以外で仕事してるの？
そうじゃなくて、海外の事例を調べてみろって話。
海外は、日本とは違って、言語をちゃんと選んでるんだろう？
使える人が多いかどうかじゃなくて。
>>261 合ってるよそれで
日本人SEはその「その人しかできない」を拡大解釈して「奴隷でもできなきゃいけない」という脅迫概念にかられてるんだよね
奴隷の開発効率なんて職人の百分の一以下しかないのにね
>>263 海外でも同じだろｗ
なんでいっつも、日本はー、日本はーって言ってるの？
>>264 同じじゃないんだなこれが
海外はプログラマを職人としてきちんとした待遇で受け入れてるからね
（その代わり職人レベルにないプログラマは容赦なく切られるけどね）
言語の違いによる開発効率の差は殆ど無いから当たり前の話であるんだが、
>>265 だから海外ではなんの言語が使われてるのか？って
話をしたんだよ。日本と違うデータが出てくるんだろ？
>>266 出てるよ
海外のJava、PHPの落ち込み方は半端ないからね
それに引き換え日本の求人ときたら…
向こうは一山いくらの開発はどんどんオフショアに投げるし、
カスタマイズは良いけど成果物を公開しないよ、秘密だよってのがガラパゴスなんだろ
じゃ海外でSIの成果物をgithubで公開してる例を教えてくれよw
この文脈でSI限定じゃない方が不自然だと思うが?
お前らはどうせどの言語もまともに使えないんだからどの言語でも大差ないよ
>>268 落ちているやつじゃなくて、何を使ってるかを言えよｗ
秘密が属人的なものであれば公開するという意思決定も簡単にできる
ところで効率や仕事での仕方なし抜きにしたら、おまいらの好きな言語って何？
うーん。生産性と行数がイコールだと思ってる人がいるようだね。
JavaScriptでもアロー関数が使えるようになって、
俺はc++14以降のc++がけっこう好きになってる。
>>284 最終手段としてないよりはあるほうがいいし、技術的にはすごいけど実用的には？だけどね。
考えてみりゃわかるけど、動いているシステムをその場で書き換えられたら困ることのほうが多い。
例えば書き換えるべき対象が一つだけならいいけど、今は何十台といったサーバーでアプリが動いてる。
そのそれぞれにログインしてシステム書き換えますか？って話。
作業をミスすることなく一発で完了できるならまだしも、通常は手元で修正してテストをしてバグを潰す。
書き換えてる途中でその機能を使われたら問題になるので、ブロックする機能も必要。
マーケティングの点からも直ぐに修正反映ではなくて、事前に告知したい。
でなんとなく気づいてかもしれないけど、動いてるシステムをそのまま修正ってのは実際に
ウェブアプリで行われてるんだよ。ただしSmalltalkは言語のレイヤーでこれらのことをやってるが
その他の言語は別のレイヤーで行ってる。
それもそのはずで、SmalltalkはOSの機能そのものまで言語の中に取り込んでるものだから。
だから「動いてるシステムをそのまま修正」っていうのは実はOSを起動したまま
アプリを再起動させるだけで修正できるのと同じことを指してる。
単に言語だけで完結できますよーってだけで、他の言語もOSと連携させて動いてるシステムを
そのまま修正することは可能。
いや、便利で必要な技術だと思うよ。
>>285 > でなんとなく気づいてかもしれないけど、動いてるシステムをそのまま修正ってのは実際に
> ウェブアプリで行われてるんだよ。ただしSmalltalkは言語のレイヤーでこれらのことをやってるが
> その他の言語は別のレイヤーで行ってる。
いや、うん知ってるし。
で、だ、仕事での仕方なし抜きにしたらって言ってる所にトウトウと実用ではどうのこうの語られても「そうだね」という感想しか持てないわ。ごめんね。
そんなことよりお前の好きな言語とそれに惹かれたとこは何さ？
お前らが惹かれた言語はなにでそのどんなところに惹かれたのさ？
やっぱりSmalltalkが最高だったね
>>286 > バグ修正やハックの類だが、そのゲームの最中に修正できるに越したことはない。
今までの人生で、何回、ゲーム最中にゲームを終了すること無く
ゲームの実行コードを修正したいと思ったことある？
もちろんそのゲームの開発者の立場で。（チートする話じゃないってこと）
>>288 > お前らが惹かれた言語はなにでそのどんなところに惹かれたのさ？
言語を使うのが目的じゃなくて、その言語でなんらかの
アプリ、システム、サービスを作るのが目的だからね。
言語だけで惹かれることはない。
特殊なアプリだったら、特殊なライブラリが在るものを選ぶとか
特定の環境（スマホとか）で動かないならば、その環境で一般的なのを
選ぶとか、なんらかのプラグインならば、その大本と同じ言語を選ぶとか。
言語そのもので惹かれるってことはないな。
ある言語で書いていて、あー○○言語だとあれがあって便利なのになーって
思うことはたまにあるけど、それはそれでその問題を自分で解決するほうが楽しい。
>>293 色んな人がいるよね
大事なのは言語愛を否定しないことだね
言語愛を持ってる人に「なんでも一緒だろ」なんて暴言を吐かないことが大事だね
（笑）とか言ってるうちはまだまだだよ
>>292 > 実行コードを修正したいと思ったことある？
効率や仕事での仕方なし抜きにってことならSmalltalkで実行しながら開発してくの楽しいよ
ついでにSmalltalkには仮想イメージっちゅう簡易オブジェクトストア機構がデフォなんで
実行コンテキストもそのまま永続化できるからこれがまた超便利
それ効率悪そう。
>>299 ユニットテストとかsmalltalkから生まれたんじゃないのか
mvc、デザインパターン、これらもみんなsmalltalkから生まれたよね。
>>299 テスト駆動もできるけど（まあxUnitとかTDDなんてそもそもSmalltalkが元祖だしｗ）
それをもう一歩進めた場当たり的ないわゆる“デバッグ駆動開発”がSmalltalkでは気持ちイイ
頭の中にできあがったモデルを仮想イメージ（Smalltalk環境）にどどーって注ぎ込んでくスピード感がたまらない
http://www.slideshare.net/sumim/20120916-rubykaigi-rubyistsqueak-smalltalk/21 俺の今のメインはc++, java
>>300 だからユニットテストつかって実行すれば良いんだから
実行しながら開発とかする必要ないんですよ。
>>302 小学校でプログミングとか話題になったけど、個人的にsqueakって結構合うんじゃないかと思ったりした。
まぁ、先生が使えないだろうけど。
>>302 > 頭の中にできあがったモデルを仮想イメージ（Smalltalk環境）にどどーって注ぎ込んでくスピード感がたまらない
それ意味わからん。
俺は頭の中に出来上がったコードをばーっと書き上げる。
書いてる最中にいちいち実行したりしない。
>>306 んー、説明が難しいな
コードは頭の中にはまだないのよ つーかSmalltalkで組むときはコーディングというのを実はあまり意識しない
漠然としたオブジェクトだけが頭の中にあって、それをSmalltalkに（それこそメッセージを送って）構築してもらう感じ
TDDは仕様を書かされている感じがワンアクション挟まるというかなんか隔靴掻痒感みたいなのがある
smalltalk使ったことが無い俺が想像でいうと、smalltalkでの開発は言語でコードを書くというより、もちっとレイヤーが上の感じだと思う。
>>307 そんなTDDをするにしても、Smalltalkだと件の“デバッグ駆動開発”っぽさは入ってくるので
他言語でやるTDDよりは楽しいんだけどね
VIDEO あと、この動画の後半に出てくる入出力例を入れるとメソッドを探してくれるツールとかは他言語にも欲しい
>>307 もしかしてコードを考えるのに時間がかかる人？
何かしたいことが有って、それを書こうと思ったら複雑なものでもない限り
5秒もあればそれを実現するコードを10行ぐらい頭のなかに出来上がるだろ？
一関数の行数がだいたいこんぐらい。
あとはそれをばーっとかくだけなんだが。
>>308 > 今時の人たちが、コンテナ用意してその中でサービス走らせてイメージ保存してとかやってることを、smalltalkだとその言語・環境で全部できる。
Smalltalkでクラウドを使って複数台のマシンで連携させて
サービスを実現するってことを、言語だけでやる方法を教えてほしい。
まず最初にデプロイはどうするの？
イメージの保存というのは、実行コンテキストの保存ではない。
Smalltalkのいう実行コンテキストを永続化っていうのは
今のコンテナの仕組みとは正反対だからな。
https://ja.wikipedia.org/wiki/Immutable_Infrastructure > Immutable Infrastructure（イミュータブル インフラストラクチャ）は
> 不変なサーバー基盤のこと。具体的には、一度サーバーを構築したらその後は
> サーバーのソフトウェアに変更を加えないことを意味する。
これが今のトレンド。ソフトウェアに変更を加えないから
いつでも破棄して作り直せる。
>>310 うーむ やっぱりコードベースで考えなきゃいけない言語の人とは分かり合えそうもないか
Smalltalkだとどうしてもオブジェクトベースな頭になっちゃうのでいけませんな^^;
>>311 良くも悪くもSmalltalkの生い立ちは「パソコン」環境（アラン・ケイのダイナブックのための暫定OS。為念）なので
そういう使い方は想定されていないんだけど、しいて挙げるならGemStoneというSmalltalk処理系がそれ向けかな
Smalltalkはもとから簡易オブジェクトストアの中に構築された処理系という特殊な実装方法がとられているんだけど
それを一歩進めて、分散OODB内に処理系を構築しちゃった感じのSmalltalkの一種
https://docs.google.com/viewer?a=v& ;pid=sites&srcid=c21hbGx0YWxrLXVzZXJzLmpwfGhvbWV8Z3g6NGJiZDExNjU5ZmIxN2Q4Yg
>>312 実行コンテキストも含めて永続化できるっていうのはデバッグの時にちょっと便利なオマケ機能であって
システムを構成するオブジェクト群をその状態のまま収めた仮想イメージファイルで配布する用途が主なので
今のコンテナの考え方に近いと思うけど違うのかな
コンテナを起動した直後はオブジェクトは存在しない。
> うーむ やっぱりコードベースで考えなきゃいけない言語の人とは分かり合えそうもないか
>>315 > データを別の所に保存していて、コンテナ自体には持たないから
いつでもすぐに停止して破棄することが可能。
うん。だからデータを別の場所に保存するそういった運用も可能ということ
たとえばここに置いてあるzipぞれぞれには
http://wiki.squeak.org/swiki/uploads/10/ComSwiki.3.zip?history=true 当時のモジュールのソースが失われたりして今となっては構成の再現が不可能なとても古いComSwikiという
サーバーの歴代バージョンを構成するオブジェクト群を永続化してファイルに収めた形（仮想イメージ）で
入っているんだけど、各々の仮想イメージさえあれば各バージョンのComSwikiサーバーは動かせるし
Wikiのセッティングやデータは別ファイルで保存されるんで仮想イメージ（サーバー環境）自体は
停止して破棄はもちろん、すげ替えたりもできる…ってあたりがちょっと似ているんじゃないかな、と
>>316 Smalltalkのプログラミングというのは環境内にオブジェクトのネットワークを構築することが目的だから
ソースコードの記述を必ずしも意味しないんだよね
例えば、クラスやメソッド定義のためのコードの記述やそれを評価する行為は、オブジェクトとしてのそれらを
その場で生成するために行うSmalltalk環境とのコミュニケーションの手段の一つに過ぎなくて
他言語のようにソースコードを収めたファイルを書き上げる（あるいは書き下しでいく）作業とはちょっと感覚が違う
たぶん何を言っているのかわからないと思うけど^^;
何回か修正していって、やっぱり3回前の修正だけ
smalltalkって超成果主義なんだよな
>>319 > ソースコードなら、特定のコードを取り除くだけ
Smalltalkの場合、プログラムの修正は「オブジェクトのすげ替え」、
つまり新しく生成して古いものと置き換える作業になるけど、別にソースコードの場合と同じだよ？
たとえばメソッドオブジェクトのすげ替えなら、その履歴はすべて記録・管理されているから、
その不要な「３番目」の修正を無かったことにして元に戻すだけ
> 実行イメージを破棄せずに、イメージから3回前の修正に伴う全ての環境への変化を元に戻せるの？
その「３回目」がたとえばDBからデータを削除してしまうというような不可逆な変化を生じさせる場合
ソースコードベースだってソースをいじったからって元に戻るわけではないよね？
イメージの保存は、smalltalkだけじゃなくlispもできたはず。意味・概念は違うかもだけど。
>>320 > smalltalkって超成果主義なんだよな
プログラマの一挙手一投足が記録に残るから、そういうところはちょっとあるかもね
おもむろにどこかで3+4って式を評価したことも見ればあとからわかる
だから、環境内でどんな試行錯誤やヘマを何時やったかはマネージャーにバレバレ
関係ない小屋やテントなんか遊びで作っていたら、そりゃ叱られるよね
>>322 LISPもたしかにできるけど、Smalltalkのようなイメージベースでの運用形式は通常はとらないよね？
Smalltalk派生の処理系でなければ他は（Smalltalkの亜種に数える人もいるけど）SELF、あとFactorとか
でも秘伝のタレみたいにイメージを何十年にわたって育てていく感じはSmalltalk独特のような気がする
Smalltalkの場合、オブジェクトって言ってるのは
>>323 どうでもいいものを記録にとってどうするよｗ
そういうのはノイズが多いっていうんだよ。
関係ないノイズが多すぎて重要な事が見えなくなってしまってる。
>>325 > Smalltalkの場合、オブジェクトって言ってるのは
> 単にソースコードなだけだよ（笑）
いや、オブジェクトはオブジェクトでしかないし、それを生成するためのソースコードとは別物なんだが…
やはりソースコードベースでしか物を考えられない人とのコミュニケーションはやっかいだな
クラスとインスタンスを会話の中で混同する人みたいだｗ
それはさておき
> 普通の言語ではソースコードとデータは分離されてるから、
> 簡単にデータだけバックアップが取れる。
Smalltalkだってそういう運用（たとえばデータはファイルやDBに追い出すとか）は可能だよ
そのうえで、あえてそういった手段をとらない、つまり仮想イメージ内にデータを保持する場合の話としても
仮想イメージはもちろん複製してバックアップは可能なので、
> あるデータで処理がおかしい場合、データのバックアップをとっておき、
> ソースコードを修正して、同じデータで処理するだけで正しいデータが得られる。
というのも普通にできるよ
（より正確には「ソースコードを修正」は「別の機能性オブジェクトにすげ替えて」だけど）
それなのにSmalltalkで「出来ない」とか「データを変えてしまうとソースコードまで変わってしまう」とか
いうのは仮想イメージの運用にどんなメンタルモデルを持っているのだろうか？
>>327 できないというかやらないんだよ。
Smalltalkの世界ではそんなことしない。
だから特殊で他の世界の常識が使えない。
>>326 > 関係ないノイズが多すぎて重要な事が見えなくなってしまってる。
そこはナンチャッテとはいえオブジェクトストア（ある種のデータベース）なんで、適切なフィルタをかけてやれば
必要な重要な情報は適宜引き出せるようになっているからご心配なく
実際にもそういう細やかなログはトラブル時にその原因の解明や、仮想イメージ（正確にはオブジェクトメモリの状態）
をやむを得ず放棄しなければならい場合の復旧にも役立っているしね
>>328 > Smalltalkの世界ではそんなことしない。
そんなことはないよｗ どんな思い込みだよｗｗｗ
普通にデータを仮想イメージ外に置くためのORMとかOODBとか用意されているし、必要なら使うよ
>>243 残念ながら土方に職人芸は要らない
最初から職人芸を発揮できるところに行けとしか言いようがない
>>331 phpの話してもいいんだぜw
7からだいぶよくなったとか。
実際の案件でもう使ってる人はいる？
>>331 wwwwwwww
ずっと続いてるから無理なんじゃね？wwww
smalltalkは超成果主義なので
Smalltalkの一番の欠点が、ソースコードの管理がしづらいってところだろうな。
>>336 > Smalltalk独自のフォーマット（バイナリ）で保存しなければいけない。
頼むからウソ情報垂れ流すなよ…
Smalltalkには古典的にも任意のオブジェクト（主だってはクラスやメソッドだが）にそのソースをはき出させる
file out という機能があってだな、凝ってもせいぜいXMLで事足りる いったいどこから情報を得てんだよ！ｗ
昔はデータとコードの区別はなく渾然一体としていて、プログラムの自己書き換えのようなテクニックも一般的だったけど、
でもセキュリティホールが多いと言われるphpはたくさんのところで使われている。
ていうか、プログラムの文法の話じゃなく実行環境の優劣を語るなら
話変わるけど、文法というか見た目的なところで、
>>338 ソースコードもデータだよ
ただ圧縮のやり方が動画等とは違う
圧縮することで成果物が劣化するんじゃないかという不安は動画と同じ
>>343 いまの殆どの処理系では実行時の扱いは他のデータとは違う
それは圧縮方式とは全然関係ない
>>292 Web上での拡張機能でのパッチなどを合わせたら
動いている最中に何かをしようとすることなんて
むしろそうじゃないことよりも多いくらいだよ。
昔はjavascriptを無効にしてデータだけ見たり保存したり出来たのに
>>338 今はIDEなどでコードもデータ（AST）として扱われるのが当たり前だし
いずれはインクリメンタルコンパイルやホットスワップもデフォになって
コンパイル時と実行時の区別なんてのも次第になくなっていく
「できることはどんどんやって、性能や技術面で設けられた過去の無用な制約は撤廃する方向に発展する」ってこと
わかるかな？
>>347 いまではサービス稼働中にサービス止めずにシステム入れ替えるとか普通にやってるけど
それはプログラミング言語のレイヤーでやってないし
やる意味もないんだって
本当に素人なんだな
ホットスワップも、できるけどそんな機能いらないとか昔は言われてたもんなｗ
すでにとっくに解決済みの問題なんですが、何盛り上がってんの？って感じなんだよなぁ
盛り上がってる人を引きずり下ろすバトルロワイヤル
要するに基本的な機能に付いてはもう話すことが無くなってきたってこと。
最近のC#の強さは異常だな
>>345 > Web上での拡張機能でのパッチなどを合わせたら
> 動いている最中に何かをしようとすることなんて
> むしろそうじゃないことよりも多いくらいだよ。
いや、動いている最中に、メソッド一個書き換えたりしないよｗ
バージョンアップなどの「修正」っていうのは通常一箇所（一メソッド）の
修正じゃなくて、複数のファイルにまたがる複数のコードを一度に更新する。
書き換えている間、そのメソッドは使えません。そのメソッドに依存するメソッドは
使えません。修正中は一時的に壊れます。じゃだめでしょｗ
そうなると必然的にサーバーをメンテナンスモードにするか止められないシステムなら
サーバーを複数台用意して、そのうち一台をアクセスされないようにして更新、
次にもう一台を更新・・・てなると思わない？
それを最近じゃサーバーを壊して作り直すことで更新するわけだけど
動いている最中にソースコードにパッチを当てるとか信頼性を担保したいならやらないからｗ
>>348 がすでに言っていたか。
>>345 にレスしてないから見逃してしまった。
そうサービス稼働中のシステム入れ替えはプログラミング言語のレイヤーでやることじゃないよね。
トランザクションのように複数のファイル（クラス）にまたがる複数のコードを
アトミックに更新するひつようがある。
もし "プログラミング言語のレイヤー" でやるとしたら、
1. ローカルでソースコードを書き換える。
2. ローカルでテストする。
3. 一連の修正を "プログラミング言語のレイヤーで" 一単位とする（gitでいうブランチとかタグ）
4. 一連の修正を "プログラミング言語のレイヤーで" サーバー側上に反映させる（gitでいうmargeやcheckout、もしくはデプロイツール）
みたいな機能が必要になるだろうね。
プログラミング言語にソースコード管理ツールや
デプロイツールまで内蔵しないといけなくなる。
>>356 > プログラミング言語にソースコード管理ツールや
> デプロイツールまで内蔵しないといけなく
Smalltalk？！wwwwwwww
>>355 俺は君みたいな卑怯な人間が大嫌いだ。
俺と君との間ではロジカルなより一般的で広い話になっていた。
そこで自分の立場が危ういとみるやさも当然のように
狭い範囲での良識や常識を持ち出すのは尽く卑怯。
意図的か無意識かは知らないが、
俺はそういう、相手が一生懸命考えた行為、
人と人との対話の価値を台無しにするやつは大大大嫌いだ。
知能人として最も最低な行為だと知れ。
人よりも言語自体が目的っていう軽い感覚がかえって役に立つこともあるね
状況に合わせて使う言語を変えたいけど、
ライブラリとOSがCで書かれている必然性を気にする奴が多い
>>358 中身のない文章っていうのは、汎用的になるんだよねｗ
具体的な何かを指摘してないから、どんなときにも使える文章になる。
お前の文章の話な。
>>361 国際的な公用語が英語である必然性を気にする奴が多い
英語は手段に過ぎず、手段は他にもあるから、英語の必然性がないという
英語が偶然なのは当たり前
>>362 話突っ込んできたのも君だし、君が挙げたテーマに沿って具体的に話していたが？
それを卑怯な君が投げ出したのだろう？恥ずかしいやつ
え？ どこが投げ出してるの？
いつもの理想郷アスペ君と認識障害アスペ君のくっさいくっさい争い
Smalltalkerとのやりとりって、いつも不毛になるよね。
AがSmalltalkだろ
テント暮らしの元兵士A
>>370 こういうこと？
A「この流行りのIDE/ORM/SCM/コンテナ…、超便利でサイコーの環境だよ」
B「いや、俺ら大昔からふつーに統合化/永続化/分散ソース管理/仮想化すんでるし...商用分散OODBもあるし…」
A「不審者が近づいてきたら攻撃対象のコンテナ気軽に破棄できるから安全なんだぞ！」
B「いや、自分で育てた仮想イメージに住んでたら不審者から逃げる必要ないし…」
A「もし第三者にコードいじられたらどうするんだよ！おまえら全機能かかえこんんでるんだろ!?」
B「ヘッドレスで動かすかなんならコンパイラクラスぶっこ抜いておくし…」
>>374 SmalltalkのOODBってMysqlとかと比べて100倍位遅いんじゃなかったっけ？
talkerじゃないがRDBMS用のORMもあるって書いてなかったか
>>371 彼らはトンチンカンなわけではない
言語に求めること、向き合う姿勢が違うから話が噛み合っていないだけ
>>375 どんなOODBと比べて？ 商用のGemStone/Sがそんなだったらヤバい
talkerとしてはむしろ
漢字は外来語だけど翻訳しなくてもそのまま使える単語は便利じゃん
Smalltalkよりも遥かにマイナーなErlangは
違うと思うメッセージングによる遅延結合の徹底という考え方が人類にはまだ早すぎるから
メッセージングによる遅延結合の徹底というアイデアはwebで余すところなく実現されてる
そんなもんが現在価値があるかどうかと関係あるとでも？
>>371 > AがSmalltalkだろ
お前、どんな気持ちで
>>370 が「BがSmalltalk」って
言ったか、考えたことあるのか！
>>384 Smalktalkに価値があると言っても、全てに価値があるわけじゃないのです。
他に影響を与えられなかったものは価値がなかったと考えるべきです。
つまりSmalktalk独自と言えるようなものは価値がないということです。
>>385 たしかに馬車は自動車に先行して使われて影響を与えたし
今でも観光目的などに細々と使われている点とかはSmalltalkの現状に似ていていいたとえかもｗ
ただSmalltalkと馬車が違うのは、つい最近も自動車ｗのトレンドに影響を与えるものを生み出していること
>>387 豚に真珠、猫に小判じゃないけど、
まだ真似されず独自の部分が現時点では無価値という意味では当たらずとも遠からずか
などと言ってみたところで馬の耳に念仏…というところも含めて
こういう隔離スレでこんだけ暴れてるのに本スレは今月１レスしかない。終わった言語
暴れてるって、いわれのない言いがかりをつけてきて
どうせ仕事でSmalltalk使ってないでしょ？
いわれのない言いがかりをつけてきて
たしか最近は悪口ばかり言う方が悪者ということになっていた筈だが
>>388 関数型言語はMapReduceとか、最近だとAWS Lambdaなどにコンセプトが受け継がれてて
まさにトレンドに影響を与えてると言えるけど、
Smalltalkにそんなものあったか？
まさかtraitsとかいうoopの一構文に過ぎないものの事を言ってんの？
MapReduceとかAWS Lambdaとかはメインフレーム時代のプロセス指向なバッチ処理への回帰であって、
TraitsとMixinを混同するならともかく、oopの一構文とかどんな理解力不足なんだよ
>>398 どっちもスケールの問題に対する関数型的な解決だよ
なにがプロセス指向なバッチ処理だよ馬鹿は黙ってろ
>>399 traitsもmixinもたかがoopの一構文に過ぎない
そんなもん全く重要じゃないし、そんなのに拘ってるから下っ端コーダのままなんだよ
>>481 じゃあお前にとって重要なものは何？
社長が重要とかいうボケはいらないからね
>>400 > どっちもスケールの問題に対する関数型的な解決だよ
AWS Lambdaで使える言語は、Node、Java、Pythonなんだけど
関数型的な解決だという根拠は？
>>403 AWS Lambdaで書けるのはステートレスな関数に制限されてるだろ
状態を持たないことによる並列化のしやすさや疎結合という
関数型言語で得られる（と言われてる）メリットをアーキテクチャレベルで実現してる
てか、こんな簡単なことも言われないと分かんないの？馬鹿なの？どんな言語で書けるとかマジどーでも良いんだよ
vector<char>なら状態を持つがstringはステートレス
lambda言ってる時点で関数型意識してるでしょ。
なんだｗ 「関数」と「関数型」をごっちゃにしているやつだったかｗ
>>407 ステートレスなコンテナってとこがミソなんだよなぁ
いくらでもスケールアップできて、S3のイベントなんかに反応して計算して、終わったらコンテナごと全消去
入力と出力だけ考えれば良くて、リアクティブで副作用なしでスケールアップ可能ってのが特徴なので、古典的バッチとはぜーんぜん違う
それを単なるバッチ処理と言うんだよw
>>411 ユーザがファイルをアップロードしたらAWS Lambdaで計算して結果を返す（典型的な用途）
これがバッチ処理ならhttpサーバはバッチ処理してるんだなw
>>412 全く本質が見えてないな
それが関数型ならインプレース更新を行わない古典的なバッチ処理はだいたい関数型だと言ってるんだよ
>>413 本質が見えてないのはお前だよ
ただ単に、副作用がない関数でシステム書けば関数型か？って聞くならともかく
どっからバッチ処理が出てきたの?w
>>414 問題は処理の粒度
Lambdaにずいぶん夢見てるみたいだけど、Lambdaは呼び出しのオーバーヘッドが大きすぎる
現実的にはバッチ処理やS3にアップロードされた画像ファイルを処理するといった粒度の大きな処理単位でしか使い物にならん
そのレベル止まりなら全く目新しいものではなく、現代にあえて関数型だと言うなら粒度の小さな処理に対しても統一的に適用できる仕組みが必要
「Lambdaによるリアルタイム処理」みたいな言葉が独り歩きしてるが、あれスループット上げるために
わざわざKinesisを間に入れてマイクロバッチ処理に変換したりするんだぞ
OOPのメッセージパッシングも、所詮関数呼び出しじゃんって言ってそう、、、
粒度が荒くなると関数型じゃなくなるなんて
言語が一つじゃなくなる粒度とか
>>417 副作用をもたらすから関数型じゃないんだよｗ
オブジェクト指向でも副作用がない関数を書いたら
それは関数型だって主張したいのかい？ｗ
俺はこの問題に二十年取り組んできたが、結論は出てる。
意訳
「
>>420 が関数型と主張した」言語が関数型だ。
ニセ科学に反対するだけで良かったのに
つーか殆どがマルチパラダイムじゃね？
うるっせえなこの馬鹿どもは
PHP 7.0.x から PHP 7.1.x への移行
http://php.net/manual/ja/migration71.php PHP7.1リリースｷﾀｰ! hackのnullable型導入とかか？
とりあえず x.1 待ちしてた奴ら移行しろよ。
直也：.NET CoreというかC#って型があって、しかもサーバーサイドも書けるじゃないですか。Linuxでやってた人たちはずっとスクリプト言語使ってて、
>>428 いい加減現実を見よう
未来へ一歩踏み出そう
未来を見ず現実を見たつまらない言語がDartなんだが
間違いはGoogleが現実の問題とニーズだけを見ていて自分の立場が見えていなかったことだな
大事なのは言語云々よりDartVMでしょ
>>432 ブラウザ統合自体が重要なのではなくてGoogleのやる気の問題だろう
Chromeに統合するという触れ込みで登場した当時は
Googleが本気だ! ということでそれなりにインパクトがあった
Dartが注目されていたのはそのGoogleの本気というただ一点だったのだから、
「結局いつものGoogleだった」となった時点で当然もう何も残らないよ
>>432 サーバ側ならどう？
typescripあるしphpも型付けることできる用になったから難しいかな？
Goもあるし.NET Core(C#)も盛り上がってきたからねえ
wasm対応で先手を取れれば状況がひっくり返る可能性もあるが
JavaScript死亡ｗｗｗ
「WebAssembly」がITの未来に変革もたらす｜Google、Apple、Microsoft、Mozillaが共同で開発した新概念
「WebAssembly」がWebブラウザに変革をもたらします。
Webブラウザは、もともとただテキストを表示するだけのところから始まりました。その出発点から、現在ではコミュニケーションやゲームまで幅広い表現を可能にしています。
そして今回、「Webブラウザ」に新しい概念が加わわることになりました。
それをもたらしたのが、ブラウザに関わりの深い世界規模の４社「Google」「Apple」「Microsoft」「Mozilla」が共同開発した、Webのためのバイナリーフォーマット「WebAssembly」です。
今回はその「WebAssembly」について、「スゴイところって何？」「何が起きるの？」をご紹介していきます。
WebAssemblyは「JS不要。コンパイラ言語だけで動的アプリが作れる」「どの言語でもWebブラウザ上にアプリを作ることができる」
WebAssemblyによってもたらされるスゴイところは次の4つ。
コンパイラ言語だけで、Webブラウザ上に動的なアプリが作れる
ほぼ機械言語にコンパイルされるからヌルヌル動く
OSを一切気にする必要がなくなる。気にするのはブラウザのみ
C,C 以外の言語でもWebAssemblyにコンパイルされる「クロスコンパイラ」の可能性が高まった
これまでWebブラウザで、ユーザからの入力情報を元に、動的なアプリケーションを実現するためには「JavaScript」が必須でした。
「インタプリター言語」であるJavaScriptは、その都度ソースコードを機械語に翻訳する必要があるため、予め機械語に近くコンパイルされる「コンパイラ言語」と比較すると動作が遅いという特徴があります（※）。
もしコンパイル後の機械語に近い形で、Webブラウザ上でコードが実行されたら。
JavaScript以上にヌルヌルに動き、しかもJavaScriptを気にする必要がなくなります。
それを実現したのがこの「WebAssembly」です。
https://mayonez.jp/1690 モンスターのアイコンの統一感がなさすぎるな
>>438 今更な記事を引っ張ってこられてもな。
対応言語c,c++以外も増えたのかねぇ。
どうだろうね。
>>158 ただ自分の優位性を示したいだけの典型的な権威主義の馬鹿だな
自分の主張やは無いくせに〜ぐらいはしてるよね？とか
お前仕事場でも嫌われてるタイプだろ
少なくともHaskellは特定分野以外はまともに使えない
実際使ってればつまずくのですぐ分かる話
Haskellはまだ趣味の範囲であらゆる分野で使える言語だよ。だって純粋関数型言語じゃないから。
>>444 貴方の思う純粋関数型言語の定義とその例を述べなさい(100字以内)
このスレのお前らがどう思っているかが一番重要なんだよ
どうでも良いことばかりに着目しているド近眼ってこと
何も分かってないなぁ。
assertは書きたいことを大体書けるが、型表記機能とやらは書けないことの方が多い
それは当たり前だろうよ、縛りを設ける代わりに、主にIDEから恩恵を受けようというものだからね。
Pythonは素晴らしいけどPythonが素晴らしいのではなく、
必要以上に手をかけると処理系のメンテが困難になり結果的に進化の足を引っ張ることになる
でもPythonみたいにCythonで割り切るのもねぇと思う。
るびいは作者の頭とユーザーの頭と言語仕様が詰んでるって先生が言ってた
結果論だがPerlを批判するだけで勝てたんだよな
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
http://tamae.2ch.net/test/read.cgi/prog/1485008061/ http://gihyo.jp/news/report/01/rubykaigi2014/0002?page=2 古い記事だけどやっぱ面白いね
何が嫌なのか知らないけど、静的型から逃げ回って
無駄に複雑なことになっていく感覚、本当にすごいわ
型さえ書けば済むことを、よくもここまで複雑にね〜
Unixの思想に反するわ
で、最新の情報ではRuby3.0はどうなることになっているの？
静的型は導入されるの？
でもま、今更導入するぐらいなら初めから導入しておけばよかったのにね
当時から静的型はあったでしょ、C言語とか静的型だし
そんでRubyはCで書かれてて自分は静的型の恩恵を受けてRubyを開発したはずなのにね
十分知ってたはずなのに、今更導入とか、それって筋悪いんじゃないの？何周遅れww
それを認めたくないから静的型の導入に対して渋々なんだろうけど
そんな詰まらないプライドで言語使用が決定されたらRuby使いはたまったもんじゃないね
でもそんな事(タイプセーフの重要性)は周りから見れば分かりきっていたことで
だから俺はRubyには近づかなかったわけでさ
微妙に消極的に静的型のメリットを語ってて、何をいまさらって感じなんだけど
本当に複雑怪奇だね
>>462 スクリプト言語のほとんどは静的型じゃないけど、このスレ全体にケンカ売ってるのかな…？ｗ
スクリプト言語っていろんなものの橋渡し、
俺が思うにRubyは夢を売る商売なんじゃないかと思う
Rubyは意図的に静的型の機能を外したわけでしょ？
>>470 逆だが…動的型の方が面倒くさい
>>466 はただの荒らしだからまともに取り合うとロクなことないよ
>>471 動的型信者が静的型をdisるときによく言う「静的型の方が型が決まってるから実装が楽だが〜」
みたいなのを真に受けてるのかな
自分で簡単な言語を実装してみたらわかるよ
問題は型が静的か動的かよりも静的コンパイルの実装コスト
静的コンパイルはコンパイル系と実行系で処理系が2重になるのが複雑
仮に動的型のほうが静的型のよりも
静的型言語の実装の難易度を基準とすると
GoogleのV8エンジンとかは、技術的に本当に興味深く凄いなぁと思う反面
V8はC++で書かれているけど、
全ての答えおじさんは自分で言語作ったりするの?
動的言語を速くする努力なんて無駄だっていうけど
むしろJavaが先駆者というかJIT技術の長年の代表者かな
Javaなんかコンパイラがどんなに良質なバイトコードを吐いたところでJITを切ったら使いものにならないよ
JITコンパイル≠HotSpot技術≒V8の技術＝anamorphic
Animorphic Smalltalk VMやね
>>486 2倍は全くクリティカルではない
JSだとJITは数十から数百倍のスケールで恩恵がある
>>488 それベンチマークに特化したコードでの話じゃね？
それならJavaでも似たような差がでるよ
>>489 良いことなのかも知れないけれど、昔のインタプリタの頃のとてつもない低速度忘れちゃったんだな
>>490 Java VMは今も昔と変わらずバイトコードインタプリタだよ？
http://gihyo.jp/news/report/01/rubykaigi2016/0001 まったく往生際が悪いというかなんというか、何の意味があるの？
一方ロシアは鉛筆を使ったって感じ
「負けたんだよ」ってだれか言ってあげて
大体型を書くのが面倒ってのも良くわからないし、型推論とかもあるのにな
WASMでDOM操作とか夢のまた夢だし、
>>496 > それからダックタイピングは本当に必要なのかどうなのか
> 静的型であってもジェネリックやテンプレートやオーバーロードがあれば
> 静的なダックタイピングは可能なわけで、しかもタイプセーフだし
ダックタイピングのこと分かってないだろ
ダックタイピングはそれをプログラマが活用するのではなく
>>495 のURL先は皆読んでくれたかわからんが
掛け違えたボタン感が本当にすごくて
最初の一歩を間違えるとこんなにも面倒なんことになるのかって感じ
北朝鮮はどこまで進化しても北朝鮮ってことなんだろうよ
うすら寒い理想の未来を語るところもよく似ている
過去に生きて、未来を語って、現在に生きてないって感じ
まさに掛け違えたボタンで、「現実」のボタンをスキップして飛ばしている
胡散臭い宗教とかもそんな感じだよね
たぶん「現実」に不満がある人を集めるのが目的だから
過去の技術を使って、未来を語ってみせて、騙くらかすって事なんだろうな
これがまさしく、走り続けないと終わる、の意味だろう
でももう流石に誰も騙されないよね
麻疹みたいなものだから、学生さんは一度はそういう目に合うかもだが
もしくは、ボタンを掛け違えていることに本人だけが気付いていなくて
ダックタイピングというのは、（人間が）ガーガーと
>>501 ダックタイピングのことを何も分かってない人間がいくら言おうと説得力はゼロだよ
残念ながら
>>499 が正解なんだな〜
俺も、もし何かの都合で自分で言語を作る必要性に駆られたら
そうするだろうね、実装が圧倒的に楽だから
つまり、自分で言語を作って、自分で使うんなら
現代においてもなお、動的型はありうるんだよ、これが
言語を作る手間と時間もコストとして換算して
トータルで労力を最小にしたいから
どこでバランスするかの問題
もしくは自分はもっぱら言語を作るのがメインで、使うのは他のやつって場合も
自分だけが楽できれば良いという身勝手な発想に行き着いたのなら、ありえる
自分は静的型言語でその恩恵を十分に得ながら言語開発して
他人は自分の作った言語で苦しむっていう
人として最悪な感じにはなるけど、まぁ最終的には良心の問題
金もうけのためだったり仕事って事なら仕方ないけど
人生の目標にしたら只の嫌がらせだな
それはそれとして、既存の言語を使うだけなら
わざわざ手抜きな言語をあえて選択する意味はないよ
>>505 ダックタイピングをジェネリクスで代替できると思ってる人間の論理に説得力はない
ダックタイピングはジェネリクスではなく
>>507 その通りだね
そしてインタフェースをいちいち付けてまわるのは非常に面倒臭いこと
自分で作るクラスならまだ何とかなるが、使ってるライブラリのクラスだとそうもいかない
> そしてインタフェースをいちいち付けてまわるのは非常に面倒臭いこと
>>509 コメントなら書くか書かないかは開発者が選べる
それを「低レベルコード生産要素」と見るか「プログラマの自由を保証」と見るかは
ポジションによる
Matzなんかは後者の立場なんだろうし、日本のSIのような人月計算でレベルはおかまいなしのような
プロジェクトに関わってるような人から見れば前者になるんだろうね
「静的な」ダックタイピングはジェネリックとオーバーロードで実現可能
>>510 > コメントなら書くか書かないかは開発者が選べる
言い換えると、
コメント書きたくない、仕様書を書きたくない。
コード読まないとわからない。
というコードを書きたいってことか？
ひどいな。だから可読性が下がるんだよ。
>>511 ぜんぜん違う
ほんとダックタイピング分かってないんだな
ID:cCOM2/u0 なんかはその辺分かってるから議論になるけど、お前にゃ無理だよ
>>512 Matz の有名な言葉に「ソースがドキュメントだ．バグも完全に記述されている」ってのがあるからねぇ
冗談半分だとしても、思想としてそういう方向なんだろう
本気半分の言い分としては、ソース読んだだけでちんぷんかんぷんなコードはその時点で怪しいと思え
って感じだろうか
インターフェースは契約プログラミングの一種でもあるんだよ。
静的型において動的な多態にインターフェースを使うのは当たり前
>>515 そういう方向でバグを減らすというのもひとつの方向性としてはいいんじゃない？
単なる思想の違いというだけで、そういうのが嫌いな人が作った言語だって別に悪いわけじゃない
>>516 だからお前はダックタイピング分かってないんだからもういいよ
staticおじさんのように、分かってない機能は全部けなす方向性の人間と議論になんかならんからな
まずお前にすすめるのはリーベルGの「高慢と偏見」を読めってことだ
>>517 > そういう方向でバグを減らすというのも
そういう方向で"も" な
バグを減らすテクニックはいくつもある。
静的言語なら、そのテクニックが増えるわけだ
動的言語でできるバグを減らすテクニックは、静的言語でも使える。
さらにプラスして、静的言語ではコンパイル時に実行することなく
バグを減らすことが可能になる。
これは明らかにバグを減らすために追加された機能といえるだろう
>>519 そのために生産性やプログラマの自由が減るというトレードオフがあるけどね
そのトレードオフのどっちを取るかはポジションで決めればいいだけの話
ちなみにダックタイピングは、ダックのように振舞うものは、ダックとして扱える
って言ってるだけで
静的に解決するか、動的に解決するかは、別の問題であり
当然静的なダックタイピングは、ある
>ダック・タイピング
>
https://ja.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0 >C++のtemplateはダック・タイピングの静的版である
残念だったなwww
それともWikiを書き直すか？
>>521 俺はテンプレートに関しては何も言ってないが？
ジェネリクスはちゃうやろって言ってるんだが
>>520 > そのために生産性やプログラマの自由が減るというトレードオフがあるけどね
減ってないよ。逆に高くなっている。
っていうか、あんた書くときのことしか考えてないでしょ？ｗ
プログラミングっていうのは書くよりも読むことのほうが遥かに多い。
だから、可 "読" 性 が重視される。
読みやすいコードは生産性を大きく上げる
>>521 × C++のtemplateはダック・タイピングの静的版である
○ C++における型消去はダック・タイピングの静的版である
明らかに間違ってるから直しとけよ
>>523 それは違うな
コメントなら引数を「与えられる方」だけ書けばいいが、インタフェースは引数を「与える方」にもそれを強制する
そしてこれは結構面倒な作業だ
もちろん、引数として変なものを与えてしまう可能性も出てしまうが、それと上記の面倒さをどっちを取るかは
それぞれの人が決めればいい
現代に生き残りし貴重なサンプルだとは思うが
こういうと彼はきっとこう思う
>>525 クラスだけ与えられて、
さてこのクラスはどこで使えるでしょう？
みたいなクイズして楽しいか？
このクラスが持っているインターフェースは何かって
ちゃんと書いていれば、そのインターフェースを使える場所も
明確にわかるだろ
>>526 > 「何が面倒か」までは書かないんだよな
それだよなｗ
ほんと何が面倒なのか。
>>528 アプリケーションの全クラスが自分の管理下にあればそれも可能かもしれんな
でも実際は様々なライブラリを使うことは避けられないし、各ライブラリのクラスに後から自分が欲しい
インタフェースを追加することはできないことがほとんど
C#やScalaなんかはそういうこともできるみたいだが、今度は可読性が落ちるのでここぞというときの
秘密兵器扱いだな
>>530 各ライブラリのクラスに後から自分が欲しいインターフェースを追加して、
正しく動く保証はあるのですか？
そもそもそんなことする必要ありませんよね？
手段が目的になってしまってるんだよなｗ
>>531 あるよ
たとえばあるライブラリがAというクラスのオブジェクトを返したとする
これを別のライブラリか自分で作ったクラスのの引数として使いたいけど、その引数はBという
インタフェースを要求する
Aというクラスは字面の上ではBというインタフェースを満たしているのだが、Bというインタフェースを
implement しているわけではない
さてどうしよう
Bというインタフェースを持つクラスを自分で定義してコピーする？こんな余計なことしなきゃいけない
のは生産性の低下以外の何物でもないわな
これは一例であって他にも同様の例はいくらでもある
>>533 なんでAというクラスが、Aとは全く関係のなく作られたBというインターフェースを
たまたま運良く満たすなんて自体が起きるんだよｗ
ありえないだろ。
それよりか引数が違うのに、同じ名前のメソッドを定義してしまっていた
どうしようって思うほうが可能性高いわｗ
Aというクラスは字面の上ではBというインタフェースを満たしているのだが、
>>534 ありえるんだよ、これが
しかもしょっちゅう
(俺は静的型言語でも開発してるからよく出くわすよ)
たとえば、Serializable なんか典型じゃないかな
そのまま Serialize したいのになんで Serializable インタフェース持ってねぇんだよ！
みたいなのはほんといくらでもあるよ
このようにダックタイピングを使うとその場しのぎで直ぐに対応できるように思えるけど
>>536 > そのまま Serialize したいのになんで Serializable インタフェース持ってねぇんだよ！
そのクラスがSerializeする機能を実装してないからだろ？
http://rubytips86.hatenablog.com/entry/2014/03/19/184940 Rubyでこのシリアライズとデシリアライズを担うライブラリがMarshalモジュールだ。
注意点としてMarshal.dumpでは、無名のクラス・モジュールのオブジェクト、
システムがオブジェクトの状態を保持するIOなど、
Procなどいくつかのインスタンス、特異メソッドを定義したオブジェクトはシリアライズできない。
第一だよ
全然関係ないライブラリ同士でたまたま字面の上で
メソッド名が一致しているクラスがあるっていう
偶然の一致があったとしても
その動作振る舞いまでもが完全に一致していて
動作的にコンパチブルかどうかは分からないよ
想定してないんだからさ
おおよそ慣例というか習慣というか、その言語ではふつうそうするって
何らかの決まり事みたいなものがあるのなら問題ないかもしれないが
そういう場合は言語側やファウンダメンタリーなライブラリが
インターフェースを定義してくれているから、それ使えばよいわけで
やっぱり関係ないんだよ
そういうメソッド名と振る舞いの両方が偶然にも一致
っていう奇跡偶然に頼るってのが
まさにおまえ自身が
>>530 で言ってる
>アプリケーションの全クラスが自分の管理下にあればそれも可能かもしれんな
そのものなんだよ、まったくのブーメラン
>>540 ダックタイピングのことを知らないお前が言っても説得力はないよ
要するに、後付で色々したい場合はダックタイピングの方が楽なんだよ。
真面目にダックタイピングをやろうとする行為は、型やインタフェースを定義するのと違いがない
>>544 あの、精神論でごまかさないでください？
何一つ、ダックタイピングのほうが良いという理由を
言っていませんよ
>>546 良い悪いを議論する事じゃないよ。
結局は、どう思うか、どう感じるか、でしかないから。
型には型の得失があるし、ダックタイピングにしてもそう。
選べる状況なら好きな方選べばいいし、無理ならグダグダ言っても意味無いだろ。
利点を感じないのなら、これまでそういう状況に遭遇したことがないか、
或いはそもそもそっち派ではないか。
いずれにしても使わないってことで問題はない。
利点説明おねだり君なんてウザイだけだから止めろ。
http://yohshiy.blog.fc2.com/blog-entry-244.html 未確認飛行の人も同じようなことを言っていたと思ったけど見つからなかったから上記で。
結論出したいのならこの辺だと思うよ。
>>545 ガチでダックタイピングの利点を享受しようとすると、
型に留まらず世界が統一されていないといけないので、実は型よりも難しい。
そしてJavaScriptもそれに対応出来ていない。理由は標準化している奴らが馬鹿だから。
sizeとlengthが混在してるでしょ。
あれ、どっちでもいいけどどっちかに統一されてないといけない。
だから真面目にダックタイピングをやっている奴なんていない、というのは俺も思う。
> そしてインタフェースをいちいち付けてまわるのは非常に面倒臭いこと
>>540 同じインターフェースを実装してても、それは引数と戻り値の型が一致するだけで
動作振る舞いがコンパチブルかどうかは保証してくれないけどな
JavaやC#みたいなショボい言語では
>>549 interfaceは"インターフェースを"保証してくれるもので
インターフェース以外は別の話なのは当たり前だと思うが？
「お前型を保証してくれるんだろ？
バグがないことまで保証してくれよ」
っていうのと同じぐらい無茶なこと
普通保証の対象しか、保証しませんってｗ
>>549 ショボくない言語ではどういう感じになるのでしょうか？
純粋な興味として知りたいです
しょぼくない言語なら、
>>544 > 要するに、後付で色々したい場合はダックタイピングの方が楽なんだよ。
メソッドや関数のオーバーロードが可能なら静的型でも変わらなくない？
>>553 いや、それだと全部用意しないといけなくなるでしょ。
ダックタイピングだと必要なところだけ用意すればいいし、つまみ食いも出来る。その分楽。
丁度C++のスレが同じ事を言っているけど、
http://echo.2ch.net/test/read.cgi/tech/1490917669/137- そりゃ全てのオブジェクトが isScrollable や isSerealizable を持っているのが美しいだろうさ。
しかしそれは通常は余計に手間が増えるだろ。
インタフェースが肥大化するか、基底クラスが肥大化するかで。
だったらJavaScriptみたいに、
var obj_serialized = (obj.serialize)? obj.serialize() : null;
とか、
SomeObj.prototype.serialize = function(){};
とか、出来たら融通は利くでしょ。少なくとも「今」やりたいことは出来るようになる。
それが後々逆に足を引っ張ることになるかどうかは腕次第でしょ。
ただし、どっちが楽かという話であって、
出来るか出来ないかで言えば、同じだよ。同じ事を逆からアプローチしてるだけだから。
JavaScriptについて言えば、
初期状態は全ての名前のメソッドを定義してあるが、実装してない状態だと言える。
だから未実装ならundefinedが返ってくるし、実装済みなら使える。
C++とかだと、初期状態は全く定義がなくて、自分で全て追加しないといけない。
でも全てのダックタイピングを可能にしようとしたら、
型消去するなりして全てのインタフェースに対応しないといけなくなる。
これってJavaScriptの初期状態と同じでしょ。
C++のテンプレートは空回り感が酷い。
UIなんて張り切って実装しても意外に糞だったりするので、
とりあえず実装してから確認したいってのはある。
そういう時はJavaScriptみたいな、とりあえずサクサク実装出来る言語の方が向いている。
>>554 シリアライズのことしか考えてなくて、しかもシリアライズメソッドさえあれば
何でもかんでも簡単にシリアライズできるんだって思ってるみたいだけど、
まず前提として、いかなる言語も汎用的なシリアライズはなという話をしようか？
これが大前提なので、あとからシリアライズメソッドつければ、
シリアライズできて便利ーにはならないんだよ。
通常シリアライズメソッドは後から追加できないものと考えるべき。
例外的に可能なものもあるけど、あとからシリアライズメソッドを追加できるならば、
obj.serialize() ではなく、Serializer.serialize(obj) とやることで目的は達成できる。
あんたがやろうとしているのは、単にシリアライズ処理を
インスタンスメソッドにしたいと言っているだけ。
>>554 C++のテンプレートは空回り感が酷い。 とりあえず実装してから確認したいってのはある。
激しく同意する。
An one-liner で書けるようなものでは、型の恩恵などない。Local,global の峻別さえ無意味だ。そのようなときは duck typing で書かねば損だ。
逆に duck typing で一万行を超えてくると、強烈に型が欲しくなる。
>>554 そういう時はJavaScriptみたいな、とりあえずサクサク実装出来る言語の方が向いている。
俺は JavaScript(というより TypeScript) を使っていない。昔一舐めしただけだ。それ
に本格的に手を出すべきか迷っている。意見を貰いたい。
JavaScript を押す人たちのコードを見ていると、Python のほうが三倍程度は濃密な
コードで書けそうに見える。その理由は質の良いライブラリが揃っていることにある。
例えば N 重ループの iterator を Python ならば下のように書ける。JavaScript で、
こんな濃密なコードを書けるだろうか。
N=3; import itertools as md; list(md.product(*[range(3)]*N))
===============================
[(0, 0, 0), (0, 0, 1), (0, 0, 2), (0, 1, 0), (0, 1, 1), (0, 1, 2), (0, 2, 0),
(0, 2, 1), (0, 2, 2), (1, 0, 0), (1, 0, 1), (1, 0, 2), (1, 1, 0), (1, 1, 1),
(1, 1, 2), (1, 2, 0), (1, 2, 1), (1, 2, 2), (2, 0, 0), (2, 0, 1), (2, 0, 2),
(2, 1, 0), (2, 1, 1), (2, 1, 2), (2, 2, 0), (2, 2, 1), (2, 2, 2)]
>>550 そんなショボいものしか保証してくれないの？
まったく安心して使えないね
動的型付けと大差ないじゃん
動作を保証しないから問題だって言った（
>>540 ）直後に
動作を保証しなくて何が悪いと返せる（
>>550 ）って凄いねw
そのチンパンジー並みの記憶力は賞賛に値するよ
>>558 俺はPythonは知らないのでJavaScriptとの比較は出来ない。
ただPythonはクロージャに難ありなので今後も使う気はない。
改行が強制されるのも気に入らない。
JavaScriptは書いてて気持ちがいいんだよ。
理由は簡単で、全て具だから。
型等の動作には関係ない物がないから、動作に集中出来る。
なるほどMatzが目指したのはこれだったのか、というのは分かった。
だから俺が次にやるとしたらRubyだね。
今のところ、俺は型自体はは要らないという結論だ。
名前通りの型しか付けないので、見りゃ分かる。
ただ、現実として、実行前にタイプミスを見つけてくれないから困っている。
ダックタイプや動的に使う場所なんて限られているのだから、
そういう場所に対してワーニング出してくれるだけでいいんだが。
そのためのリントを探してはみたものの、
JavaScriptのリンターはそんな方向では全くなかった。
あと、C++が糞なのはクラスは全て独立で親クラスを掴めないことだ。
だから細かくクラスを階層化出来ない。というか、やると余計に手間が増える。
ここら辺はJavaでは改善されていて、明示的に掴めるし、
JavaScriptではデフォで掴んでる。（レキシカルスコープ）
粗結合を目指すのならJava方式がいいし、
お気楽を目指すのならJavaScriptの方がいい。
ところで初心者はそういう「短く書ける方がイイ」みたいなことをよく言うが、
君が本当に一万行のコードを書ける奴なら、それは意味無いと分かるだろ。
そしてそれをここで聞くのも意味無い。
だって俺の腕前なんて未知数だし、ここでは無駄に吠える初心者も多いし。
一般論としては、Pythonはキャズムを越えているっぽいから、
学んでも無駄にはならないと思うよ。
ああすまん、質問はPythonではなくて、JavaScriptを学ぶべきか？だったか。
>>560 > 動作を保証しないから問題だって言った（
>>540 ）直後に
> 動作を保証しなくて何が悪いと返せる（
>>550 ）って凄いねw
なんの動作？
ねぇねぇ、なんの動作？
わざとぼやかしてるでしょｗｗｗ
あとそれから
>>540 は俺じゃないからねｗ
IDすら見えない？
チンパンジーになみの理解力だった？ｗ
>>561 > JavaScriptのリンターはそんな方向では全くなかった。
TypeScriptがお前が望むものだよ
型を導入したJavaScriptだ。
いまあちこちで普及してる。
>>561 > ところで初心者はそういう「短く書ける方がイイ」みたいなことをよく言うが、
> 君が本当に一万行のコードを書ける奴なら、それは意味無いと分かるだろ。
え？ なんで？
同じ一万行なら、短く書ける方がより多くの機能を実装できるから
やっぱり短いほうが良いじゃんｗ
>>566 つまり型は余計だということだね
インタフェースとか余計なことを書かなきゃいけないから
>>567 それはインターフェースが余計なものであるという前提で成り立つものだ
インターフェースは余計なものではなくプログラマの意図を
コードというコンピュータにも理解できる言語で記述した価値がある情報だ
>>568 短く書ける方がいいんでしょ？
ダブスタいくないよ
>>569 正確に言うと「少ないステップ数」というべきだな。
インターフェースは実行されないのでステップには含まれない。
他にも型宣言とかimportとかコメントとか空行とか
{ だけの行とか、そういうのもステップには含まれない。
>>570 > インターフェースは実行されないのでステップには含まれない。
こんなオレオレ定義聞いたことありませんｗ
>>571 デバッガの「ステップ実行」って
使ったことないの？
インターフェースの前後でステップ実行することはない
>>572 ググってみたけどステップ数からインタフェースを抜くなんて計算方法はまったく出てこない
オレオレじゃないなら、どこか有名なサイトに計算方法が載ってるはずだからさ、ポインタでいいから
示してください
>>573 ステップ数は単に英語の意味の通り、ステップ（一歩）という意味しかないよ。
ステップイン、ステップアウト、ステップ実行できる単位と考えればいい。
ステップできないのに、ステップ数に数えるとか意味不明だろう
ソースコードの行数はLOCという。
>>574 たとえばさ、↓のページにあるように、ステップ数というと一般的にはプログラム規模を測るための
指標なんだよね
http://e-words.jp/w/%E3%82%B9%E3%83%86%E3%83%83%E3%83%97%E6%95%B0.html LOCからコメントや空行を抜いたり、中括弧だけの行を抜いたりと言語によって流儀はあるみたいだけど、
お前の言う流儀がどこにも載ってないんだよ
どこに載ってるか教えてくれないか？
>>575 だからステップ数は誰も正確な定義をしてないのだから
どんなものでも間違いではない。
>>576 とはいえ、「インタフェースはステップ数に含まない」と断言するからには、それなりに普及してる
流儀なんでしょ？
その流儀がどこに書いてるか知りたいんだが
動的型付言語の苦手な奴が多過ぎ
ここでダックタイプ嫌ってる奴って、ダックタイプを静的言語でやるとしたらジェネリクスとか言い出す奴だもんな
静的型の言語の補完の快適さは動的型言語には得られないものなんだよなぁ
>>581 という感想を持つ人は静的言語を使えばいいし、インタフェースとかをいちいち記述するのが面倒くさい人は
動的言語を使えばいいよね
ただそれだけの話
自分だけで完結してる話ならそれでいいんだけど仕事だとそれじゃ駄目なんだよね
インターフェースがある言語を使ってる人のほうが、よっぽどダックタイピング的思考をしてるだろう
>>562 意見ありがとう。552です。
>Web環境ではJavaScript以外の選択肢はないんだし。
同意します。Google が TypeScript を標準言語にしているのも、その意味なんでしょう。
俺としては型推論の働く、濃密なコード記述可能で、良質のライブラリが揃っている言語が欲しい。
Haskell が型推論で一番強力だと思うが、キャズムを超えられないと思う。Python のよ
うな、全世界の知性による良質なライブラリの膨大な蓄積は期待できない。
>> 562 ところで初心者はそういう「短く書ける方がイイ」みたいなことをよく言うが、
君が本当に一万行のコードを書ける奴なら、それは意味無いと分かるだろ。
この主張への反例として、下の URL にある RSA 暗号の実験コードを示す
http://www.math.kobe-u.ac.jp/ ~taka/asir-book-html/main/node96.html
二つの素数 p,q, から n=p q, n`=(p-1) (q-1) を経由して、秘密キーd 公開キー e を
構築する。ただし d e==1 mod n`。この 公開キー (e,n) を使ってデータ m から暗号
mm を生成し、mm から秘密キー(d,n) を使って m を復号する
## 素数 p,q から n` の定義する (暗号化されるデータ m は m < n` である)
p=13;q=17;n=p q; n`=(p-1) (q-1); n`
===============================
192
# e=35 は gcd(e,n)=1 となる適当に選んだ数数。
ts(); p=13;q=17;n=p q; n`=(p-1) (q-1); e=35; ts.gcd(e,n`)
===============================
1
## e から d e %n` == 1 となる d を作る
以上の計算ができれば、RSA 暗号を実装できる程度に理解したと言えます。
>>562 一番速いのは多分Rubyだろうし、この点ではPythonは遅いほうだよ。
老婆心ながら言っておきます。こんな理由で Ruby に学習コストを書けるのは止めるへき。
スピードが欲しいならば C 言語で実装して繋げばよい。SciPy は、実装にそうして実装
され、data science 分野で使われ、ライブラリが蓄積され続けている。
Ruby が書き安い言語なことには同意する。しかし勝手な互換性の放棄により、良質なラ
イブラリの作者たちを離反させすぎた。Python community とは差が付きすぎた。
Python は Ruby と比較して読みやすい。俺にとって読んで楽しめるコードは Python だ
けだ。C 言語はマクロの解析が必要になるなど、コードを読むことは苦痛のほうが勝
る。Ruby は C言語よりは読みやすいが、楽しめるほどではない。
今更 Ruby に向かうのは無謀すぎる。
どうせエンジンのお粗末なRubyのことだから
>>589 思いっきり文章の読み方を間違ってるよ
>>562 でいうスピードは変化のスピードだよ
君がPython好きなのは分かるが、他の言語をけなそうとする余り文章を読み違えるのは
いただけないな
>>591 「このプログラミング言語は速い」って文脈で「進化の速度」のことを言っている奴は初めて見たな
普通は実行速度だよな？ プログラミング基礎でO記法とか学ぶもの
>>593 >>562 で直前で
> とりあえず「進化している言語」を一つ追跡しておけば問題はないだろ。
と書かれているので、ここでの速いは進化の速度だよ
そうでないとJavaScriptを除外している部分と整合性が取れない
(JavaScriptは実行速度はかなり速いしね)
>>560 亀レスで申し訳ないが、それはお前の認識が誤っているからだ
あるライブラリAの、とあるクラスが、別のライブラリBて定義されている
インターフェースを実装していた場合
ライブラリAはライブラリBでも使われることを前提としている
というかライブラリBの上にライブラリAを築いている
あたりまえだろ？だから当然想定されている
で、ダックタイピングの場合は
メソッド名が一致しているからひょっとして使えるんじゃね？
ってレベルだろ
そんなの偶然の一致かもしれないし、使えるかどうかわからん
元の開発者はそんなこと想定してないかもしれない
微妙に動作が違うかもしれない
>元の開発者はそんなこと想定してないかもしれない
>>596 どういう主張だっけ？
作者が意図しない使い方はすべきでない、つまりダックタイピングは悪
ってこと？
言いえて妙な話で、あるクラスがあちこちで使われることを想定しているなら
ラッパークラスと書いたが、アダプタクラスと言ったほうが正しいかもしれん
そこそこ有名なライブラリAがあって、多数のライブラリC,D,E,...の中でそれを使っていたとする
インタフェースをきっちり設計するのは面倒だからな
>インターフェースのある言語だとライブラリAのインターフェースをBでも使わないと不可能じゃないの？
>>600 それは条件が公平ではない
動的言語がその差し替えを比較的容易に行えるのはソースコードを直に実行しており
依存関係がシンボリックだからにすぎない
CDEのソースが手元にあるなら、静的言語でもCDEをソースからリコンパイルすればいいだけの話
静的言語のリンクの仕方には色々あるが、同様にシンボリックなリンク方式を使っているなら
ソースが無くてもBにもAと全く同じインターフェースを定義すれば当然動く
>>603 > CDEのソースが手元にあるなら、静的言語でもCDEをソースからリコンパイルすればいいだけの話
さすがにライブラリ使用者にそこまで求めることはできないよね…
>>604 だからそれはインターフェースの有無ではなくコンパイルの有無の問題だよね
言ってる意味わかる?
>>605 ライブラリは基本的にコンパイル済の状態で提供されるよね？
>>606 だからインターフェースは関係ないと言ってるだけなんだけど
頭大丈夫?
>>607 ライブラリCDEをソースからコンパイルという時点でおかしよね？
>>608 そうだね
で、それがインターフェースとどう関係していると思うの?
一般論としては動的言語の方が比較的容易であることは
>>603 の冒頭で認めたうえで
それはインターフェースではなくコンパイル(の習慣)の有無の問題であるので
>>600 の「インターフェースがあるから差し替えが難しい」は誤りだというのが俺の意見なんだけど
ここまで説明しないと理解できない?
>>609 ライブラリはコンパイル済が配布されるのだから差し替えは難しいよね？
>>589 俺に言わせると、Pythonは学ぶ価値がないよ。
新しいプログラミングパラダイムを試したいなら、Rubyだろ。
「新しい事が至高」なコミュニティだから、今後もトップを走り続けるだろう。
逆に言えば、互換性なんて気にしている言語では、どうやってもRubyには追いつけない。
Pythonがゴミなのは、ラムダに式しか書けない点でも明らかだろ。
JavaScriptやってると分かると思うけど、式のラムダなんて使う割合は低い。
やりたいことが出来ない言語なんて、C派の俺にとってはゴミだよ。
そしてそれを教条的理由で採用しないというのも気に入らない。
Pythonの利点は、NumPyとかでしょ。
でもそれはNumJSとかにポーティングされれば終わる話。Python自体の魅力じゃない。
JavaScriptはローカルファイルへのアクセスが出来なかったからこの解はなかったが、
Nodeが出て、Electronが出て、という状況では、NumJSも時間の問題。
ただNodeなら直接Cで呼べるから誰もやらないかもしれないが。
Pythonが問題なのは、糞遅いこと。
これは現段階ではもう手当てする人が現れないでしょ。
NumPyでいい奴はそれで終わってるし。
NumJSが現れたら、Python＋NumPyよりも確実に速い。
その時にPythonを選択する理由がない。
JavaScriptの問題は、コミュニティとして非同期が正義な事。
正直、書きやすいとは言えない。ただこれも慣れれば何とかなるのも事実。
ネスト地獄ガーっていうのははっきり言って嘘で、ちゃんと組めばそんなことにはならない。
ただし、関数が細切れになるが。
まあこの辺も何だかなーってのもあるけど、致し方なし。
Pythonを今使うのならいいけど、将来性は無いと思うよ。
>>593 ,594
俺が言っていたのは「進化の速度」だよ。
というか、そんなに分かりにくい言い方だとも思わないけど。
ただ、本当に
>>558 が出来る言語が素晴らしいと思っているのなら、
まずは言語は何でも良いからガンガン書いてみて、
それをきっちり保守してみることだね。
そうすれば、そんな点は全く意味がないと分かるだろう。
>>611 気持ち良く長文書いてるとこ悪いけど、cythonって知ってる？
>>606 > ライブラリは基本的にコンパイル済の状態で提供されるよね？
ソースコードが提供されているならば
ソースコードを修正してコンパイルすれば良い。
そのライブラリがコンパイル済みの状態で提供されているかどうかは関係ない
>>610 > ライブラリはコンパイル済が配布されるのだから差し替えは難しいよね？
少なくともオープンソースであれば、ソースコードとコンパイル済みの
両方が配布されているから差し替えは難しくない。
>>610 多くのコンパイル型言語では故意に差し替え可能に設計しておかない限りインターフェイスの有無に関わらずライブラリのコンパイルが必要
たとえばC#でインターフェイスをつかわず、全部dynamicで呼び出してる場合でもDLL差し替えではだめ
>>611 >
>>589 >俺に言わせると、Pythonは学ぶ価値がないよ。
>
>新しいプログラミングパラダイムを試したいなら、Rubyだろ。
>「新しい事が至高」なコミュニティだから、今後もトップを走り続けるだろう。
>逆に言えば、互換性なんて気にしている言語では、どうやってもRubyには追いつけない。
釣り? 少なくともRubyは無いわ。昔はともかく、この2-3年は停滞しているように見える。
すまんが、最近Rubyに入った、新しいプログラミングパラダイムを教えてくれ。
# ちなみに貴方が腐している Python は、async/await とか、外部チェッカを利用した Gradual Typing とか Null safety とか入りました。
>>617 それのどこが新しいプログラミングパラダイスなの？
>>618 お前の頭がパラダイスだよアホ
ていうか、ruby3にgradual typing入れるってmatzが去年言ってなかったか？
>>611 ラムダ式に式しか書けないのは関数型言語好きがコミュニティに増えたからって気がする。
Pythonそのものも関数プログラミングをサポートしつつあって、同じ機能にオブジェクト指向版と関数プログラミング版と二つあるのがチラホラ。。。
そういう意味じゃすっごく気持ち悪い。
でも、使う側から見れば使えるライブラリ多いPython。
面白いかどうかじゃなくて、使えるかどうかね。
Rubyで使える数値計算やディープラーニングのライブラリ紹介してくれ。
宣伝してやるから。
>>611 少なくともNumPyが使われ続ける限りPythonを学ぶ価値はあるだろ
Pythonから学ぶことは反面教師的なこと以外はほとんどないけどさ
しかしRubyには使いどころはおろか、学びも皆無
自称言語オタク(失笑)が聞きかじった話題の他言語の顰みに倣ったり
その失敗を含む二番煎じを、ろくすっぽ論文も読まない取り巻きとひたすら繰り返しているだけ
Rubyを見て新しいとかいってる奴は元ネタを知らないだけのただの哀れな信者
アニメで小林さんがpython使ってたから本読んだ。仕事でciscoのopenpk使う事になった。小林さん、ありがとう。
>>614-615 mavenやsbtみたいなのを使うなってことですか？
これは驚いた…
>>623 意味不明
お前は公開リポジトリに既存の有名ライブラリと同姓同名の俺ライブラリを登録するつもりか?
そんな迷惑行為は常識的には認められない
>>624 ソースを入手してビルド、なんて依存性解決は面倒だしバージョンアップに追随するのも
面倒だしやってられないと思うんだが…
みんなやってられないと思ったからmavenやsbtみたいなのが作られたわけだし
>>625 Java系なら同じパッケージ名で同じ名称のクラスやインターフェースを定義しておけば
バイナリをmavenやsbtを用いて差し替えることは可能だよ
そんな”迷惑行為”は大抵のエコシステムでは認められないし、
パッケージ名の勝手な使用によって法的な問題が発生する可能性すらある
>
>>617 >それのどこが新しいプログラミングパラダイスなの？
コルーチンが普通の関数っぽく書けるようになったり、動的型言語に部分的に静的型を導入したりNullチェックを強制できるのは新しくないと。
ま、Pythonが史上初めてではないが、他言語で評判が良い部分を取り込んだ感じだな。
じゃ、貴方が思う、最近Rubyに入った新しいプログラミングパラダイムを教えてよ。
Rubyは「トップを走り続ける」のだから、1つ2つは簡単に紹介できるでしょ。
ここ最近このスレは全く書き込みが無くて閑古鳥が鳴いていて
>>628 インターフェース信者君がフルボッコになってるのを熱いバトルってww
このように、もはや違う時間軸に住んでいる人なんだよな
visual studioとc#の組み合わせが最強すぎる
>>630 staticおじさんというのは「自分の知らない機能を使えない機能だと断言してけなす人」だから、ID:KuJQA9vc のことだよ
>>630 まーた、タイプセーフの意味をわかってないやつかｗ
http://postd.cc/what-is-type-safety/ > C言語とC++：型安全ではない。
> Java、C#：（恐らく）型安全。
> Python、Ruby：（ほぼ間違いなく）型安全。
> タイプセーフは今時常識だよ
そのとおりだよ。PythonとかRubyを見よ。
タイプセーフになってるだろ
タイプセーフと、実行時型エラー出るのとは別かもだが、実行時型エラーが問題。
staticおじさんは今はタイプセーフの話なんてしてんの?
pythonは単純な手続き型プログラミングもできるしオブジェクト指向もそこそこできるし
重要な言語である事は誰もが認めるが、凄いかどうかは微妙。
今はjavascriptそのまま使うよりtypescriptでしょ
ぼほ主流スクリプト言語はオブジェクト指向も関数型も搭載済み。
ライブラリに頼らずjavascriptのそのままテキストエディタに手打ちで一気に書けるのが熟練エンジニア
と、IDEやフレームワークの進化ついて行けないロートルが申しております
近年必要なコード量が多過ぎだよな
http://goodpatch.com/blog/rubykaigi-2016-report-ruby3-typing/ >まずはじめに、プログラミング言語の「型」という側面についての
>振り返りがありました。
>プログラミング言語にも時代によって流行りがあり、
>それは振り子のように繰り返されています。
>かつては動的言語のSmalltalkやLispがあり、次に静的言語のJavaが流行し、
>JavaScriptやRubyのような動的言語が流行り、現在はGoやSwiftなどの静的言語が注目を集めています。
>このような変遷を辿り、2010年代に出てきた新しい言語には静的型付け言語が多く、
>Rubyのような言語は「死んだ」とまで言われることもあります。
>しかしMatzによると、このような流れは振り子のように繰り返されているので
>安易にRubyに静的型付けを導入するのではなく、Rubyにとっての型というものについて
>真剣に考えて導入していきたい、ということでした。
↑なんで嘘つくの？
動的型言語が静的型言語を抑えて人気だった時代なんか、あったか？
Rubyが流行っているといわれていた時代でさえ(ピーク時でさえ)
JavaやC/C++に負けていただろ、なんで嘘つくんだ？
振り子っていったい何のことだ？
当社比30%アップってやつか？
C/C++はもはや速度を求めるコアライブラリか組み込みでしか生き残ってないけどね
OSもアプリもたいていC/C++でしょ
>>647 アプリってObjective-Cのこと？
この文脈ではObj-CもC/C++に含めていいかと
>>649 だったらC/C++/Objective-Cと書かない？
CとC++をわざわざ併記してるのに、そこにObjective-Cを含めるのは拡大解釈っぽいと思う
366 :nobodyさん 2017/05/29(月) 16:07:39.16 ID:6v4UcGhE
今回の民法改正、ソフトウェア受託開発の場合、(検収後ではなく)バグ発見後１年瑕疵担保責任があるということで、地獄かよ、と思ったが、
元々問題が起きがちな受託案件がビジネス的に成立しなくなることで強制的に業界再編につながるなら良いことかもと思うようになった。
一部で地獄を見ても。
https://twitter.com/yukihiro_matz/status/869061879389343744 367 :nobodyさん 2017/05/29(月) 16:28:06.55 ID:6v4UcGhE
ニュース - 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大：ITpro
http://b.hatena.ne.jp/entry/itpro.nikkeibp.co.jp/atcl/news/17/052601508/ 372 :nobodyさん2017/05/29(月) 19:10:37.12 ID:???
Railsでシステム作って納品する
↓
Railsはマイナー、メジャーのアップデートが半年以内に必ずある
↓
客がアップデートする。アップデートによるエラーやバグ、動作の不具合に気づく
↓
気づいてから1年以内に通知すれば、5年間無料保証ゲット
↓
つまりRailsがアップデートするたびに、無償の修正作業を発生するということかな
376 :nobodyさん2017/05/30(火) 09:20:20.09 ID:L5po86sS
>>378 >>379
>>375 客が瑕疵担保責任法の法改正を知ってくると思うから、今後5年無償保証をお願いされるだろう
営業がそれでも仕事を取ってこれるか？たぶん無理だろう。無限の直していたら赤字になる。
こういう保守に弱い言語、ころころ仕様が変わる言語は仕事として発生しなくなってくる。
これは変わり目だ。お前らも早く逃げたほうがいいぞ。RubyやPHPなど動的言語は確実に廃れる。
保守に強い言語のみ生き残れる。
瑕疵担保責任（かしたんぽせきにん）
瑕疵担保責任のポイント
民法改正で事実上期限が「無制限」になった
バグや設計のミスなどは、瑕疵担保責任
納品物に不具合があれば損害賠償を請求される可能性もある
不具合を指摘されたらすぐに行動をとるべし
軽微なミスでも先延ばししない
http://www.atmarkit.co.jp/ait/articles/1706/26/news014.html http://itpro.nikkeibp.co.jp/atcl/news/17/052601508/?rt=nocnt 改正法では欠陥に気付いてから1年以内にITベンダーに通知すれば、
通知後5年以内は修正や報酬の減額などを求められるとしている
全ベンダーが泣いた民法改正案を解説しよう その1
http://www.atmarkit.co.jp/ait/articles/1609/14/news009.html http://www.atmarkit.co.jp/ait/articles/1609/14/news009_2.html http://www.atmarkit.co.jp/ait/articles/1609/14/news009_3.html ポイント1：修補や損害賠償、契約解除の期限がなくなる
従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。
条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、
その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、
11年後まで請求可能なのだ。
もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。
js/es は new を廃止するか、new を関数に変更して、且つ、定義時にデコレーターとして使えるようにしなきゃ、今の大流行は尻すぼみになるだろうな。
newが問題だった訳じゃない、貧弱で変わり者のクラスシステムに頼らざるを得なかったことが問題だっただけ
ファイル操作とテキスト処理とか正規表現が得意なスクリプト言語ってないですか
今のサイトってHTML5ばかりだからjsを知ってるだけで得することが沢山あるよな
chromeのプラグインで無垢なサイトにやりたい放題^^
ｐｈｐで検索WebAPIを作ってみてるんですが、
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
PHPとかJavaScriptで金融関連システム案件有るけど、本当に金額計算とかに使えるの?
javascriptってjavaよりややこしいね。
型情報ないのに、コールバックばかりだなら、
javascriptのスレって過疎ってるな(´・ω・｀)
js初心者なんだが
Node.jsがよく分かってないし
ローカルファイルなら、Ruby。
firebaseを使ってログイン機能を実装してるんだが
ログインしている時にユーザ情報を取得する関数としてuserInfo()と言うのを書いたんだがうまく動いてくれん
btnをクリックしたら
53行目のアラートが実行されて
62行目のアラートが実行されるんよね
それで戻り値はundefinedだし
js初心者なもんでエロい人教えてください(´・ω・｀)
ajaxで複数のオブジェクトを同時に送ることって出来るの？
$.when( getJsonA(), getJsonB(),getOtherData() ).done( function( obj1, obj2, obj3 ){ var jsonA = obj1[0]; var jsonB = obj2; var otherData = obj[3] });
PHP始めるけどどんな環境がいいの？
それをマルチって言うんだよ
「別スレで聞くことにしました」って書いたからってなにか変わるわけでもないけどな。
別スレで回答があれば閉じるし閉じなくても違う意見があれば聞けるわな
composerぐらいすぐ出てくるだろ
>>687 普通にマナーだし、それ書いてたクロスポストじゃないと判断するよ。
マルチポストと判断しようがしまいが実質何も変わらんと思うが。
ひろゆき 就職出来なかったらプログラマーになれ！！
VIDEO >>693 ホリエモンがいうところの勉強すればだれでも東大生になれるっていうのと同じ理論だな
初心者です
(u＿・y)ruby以外の言語がいくら出来るようになっても
コントローラ側にruby使ってます。
Ruby on Rails では、ファイルのアップロードなら、Active Storage
その簡単な言語に滅ぼされてる言語の墓場はここですか？
簡単だからこそ覇権を取れた
簡単ではないだろう。
日本人でJavaScriptを使いこなせるプログラマーなどれぐらいいるのだろうか？
JavaScriptは大変難しい言語です。Rubyの難易度を2、Cの難易度を5、C++の難易度を8にすると、
>>704 JSすら理解出来ない馬鹿が、自分の馬鹿さを認められない時に「JSは難しい」事にしようとしてるだけ
お前のことだが
理解に困らない奴は普通にもうJSやってる
ブラウザ上でアプリ動かすのも自然だし、さっさとそれに気づいた奴がchromeOSを提唱しただけ
俺もJS使い慣れてからは確かにOSの代わりにブラウザでいいわ、って思うし
同様にサーバーサイドもJSでいいし、実際そう思う奴がそれなりにいるからそういう動きになる
お前は自分が理解出来ないのを自分の馬鹿さゆえと認めたくないから他を否定してるだけ
それをやってる限りお前に進歩はないよ
ただ、そういう流れ/動きになってるというのは、
お前以外の他多数はそう思ってそう動いているという事実を認めた方がいい
>>707 じゃ、お前はJSでマリオカートを作ってみろ。
JSという小道具で高級なもの作るのが要求されるんだから結果論としてJSは難しい
>>708 WebGLもある今なら普通に出来るだろ
任天堂から十分な金額で求人が出てれば俺は応募してもいいが
そもそもお前は勘違いしていると思うが、マリオカートを作る難しさはどの言語でも大して変わらん
スプライトとかのレンダリング周りはあれば便利だが、無ければ自前で作るしかない
ただそれは「手間」が大幅に増えるだけで、「難しさ」には寄与しない
結局は座標を計算して投げるだけだから、それによって複雑になることはないんだよ
あれば楽なだけで
>>709 ならRubyやPythonならマリオカートをど素人でも作れて、JSだと無理とでも？
さすがJSすら理解出来ない馬鹿は言うことが違うね
>>710 >ならRubyやPythonならマリオカートをど素人でも作れて、JSだと無理とでも？
>さすがJSすら理解出来ない馬鹿は言うことが違うね
そもそもお前は勘違いしていると思うが、マリオカートを作る難しさはどの言語でも大して変わらん
スプライトとかのレンダリング周りはあれば便利だが、無ければ自前で作るしかない
VIDEO マリカーなんて作っても仕方ない
>>712 それはお前らお得意の「論点のすり替え」でしかないだろ。
言語間の難易度の比較なのだから、当然同じ事（同じアプリ）をそれぞれの言語で実装する時に難しいかどうかだろ。
「マリオカートを作る時に難しいかどうか」という視点はこの意味で正しい。
座標の計算が出来ない馬鹿がマリカー作れないのは、どの言語でも同じだよ。
> 自称js出来るってだけの人じゃ難しいよね
これは単にJSの馬鹿共が勘違いしてるってだけだろ。
これは事実としてあるが、逆に言えば、
勘違いする奴が多い＝本当は大した実力もないのに、いろんな事が出来てしまう
ということであり、JSの簡単さを補強しているだけだよ。
> Javaとかrubyで作っていたものをブラウザ上で動かすためにJsに落とし込むような作業があるでしょ
> それが簡単な作業とでも？
ねえよそんなの。と言うか言うほどインタフェースは変わらんし。
具体的に何に困った？それは君がそれを知らないからでしかないだろ。
座標計算出来ない奴がマリカー作ることは『どの言語を使っても』無理なように。
JSは一般的に簡単だとされているLightWeight言語にカテゴライズされてる。
PHP/Ruby/Python/Perlもそうだが。
そしてそれ以外、つまりJava/C#/C++/Rust等を使いこなせている奴がJSを難しいなんて言うのはほぼ居ないだろ。
(完全にJava脳になってる奴にはどうにも受け付けられないらしいが)
だから多くの人にとってJSが比較的簡単なのは事実であり、それをグダグダ言ったところで始まらんよ。
で、その簡単に書けてるJSで仕事って取れてるの？
>>714 また論点そらしか。その程度だとプログラマとしては無理だから止めた方がいい。
それのどこが「JSが比較的難しいプログラミング言語」になるんだ？
お前は学生なのかそれ以下なのか知らんが、
当たり前だが、誰でも出来るようなことで簡単に給料を得る方法なんて無い。
それはどの職業でも同じ事だ。勿論プログラマも含まれる。
お前が言ってるのは「プログラマは誰でもなれて高給を得られる職業ではない」であって、これはその通りだ。
しかしこれだと論点がずれていることにすら気づけないお前ではプログラマは無理だ。止めとけ。
前述の通り、給料を得ようと思えばそれなりなのが必要なのは全職業だし、
プログラマに限っても、『どの言語でも』同じ事だ。
まあそれでも比較的JSとPHPはプログラマ全体から見たら馬鹿が多いからWeb系と馬鹿にされてるわけだが、
しかしこれも、逆に言えば比較的馬鹿でも給料を得られるということではある。
ただし今Webがバブルってるだけかもしれんが。
まあJSすら理解出来ない馬鹿と話しても意味がないと理解した。
次の論点逸らしには返答しないからそのつもりでよろしく。
お前には未来永劫「JSは難しい」とつぶやき続けて次世代から馬鹿にされる未来がお似合いだよ。
jsが難しいというか
>>716 > js周りのフレームワークは移り変わりが激しい
乱立しているのは事実として、
いちいち付いていきたくなければ使わないのもありだし、古いのを使い続けるのもありだろ。
Javaみたいに10年間進化しない方がいいのならこれでいい。
選択肢がある分ましだと思うが。
> 生jsはIDEの支援が少ない
これは動的型言語共通の話で、Python/Ruby/Perl/PHPとも同じだし、同程度には支援があると思うよ。
それ以上の支援が欲しければ型を明示的に書くしか無く、TSがこれになる。
逆に、静的型言語で型を（全面的に）省略することは出来ないから、これも選択肢がある分ましだろ。
まあPythonは意図的に選択肢を絞っているし、それが受けているようではあるが、
俺はMatzと同様、いろんな実装方法があった方がいい、という意見なので。
>>716 それ故に新しい環境にちゃんとついていける奴は少なくなるし
ついていければ有利だろうって算段でやってる
>>715 オラオラしたいだけの学生キッズと違って大人はお金や＋＠が必要なんよね
無駄なエネルギーを使うのをやめたほうがいい
>>717 >これは動的型言語共通の話で、Python/Ruby/Perl/PHPとも同じだし、同程度には支援があると思うよ。
原理上はそうだけど環境の比較であれば実際に入手できる環境の優劣はあるね。
VSCodeのlanguage serverはTypeScriptじゃない生jsでもかなり強力に推論してくれるし
Pylanceもそこそこ使えるものになっている。
PHPとRubyはこれからってところじゃなかったかな。
>>719 その辺に関しては結局のところ人数勝負であり、JSとPython以外については死体蹴りでしかない。
ただしVSは(Codeは知らんが多分同じ）ただのフロントエンドであり、
IDEサポートについてはどの言語でも原理は同じなので、横方向展開は（やる気があれば）早いはずだが。
まあバトルロワイヤルなら第一ラウンドは終わって、これから優勝決定戦が JS vs Py で行われるといったところだろう。
ついでにPythonも滅ぼして欲しいところだが、JSは非同期強制なのとコンソールがないのが痛い。
MSがPowerShellとかいうゴミに逃げずにCScriptを発展させてくれれば良かったのだが、
これはどっちかというとMSが追い出された側だからJSの失態だが。
して、JS vs Py はお互い相手を滅ぼすほどの決定打を持たず、しばらくは膠着状態が続くのだろうね。
>その辺に関しては結局のところ人数勝負であり、JSとPython以外については死体蹴りでしかない。
pythonが生き残ってる理由ってnumpyがあったからでしょ。単に機械学習の分野で使われてるだけ。
> pythonが生き残ってる理由ってnumpyがあったからでしょ。
スクリプト言語としての活用の仕方っていっぱいあるじゃん。例えばクローリングや業務の効率化の為とか。
そういうのは、非同期に処理したいときだけ、使えば良いんですよ。
JavaScriptも同期的処理がメインのライブラリ、実行環境がでればいいけど
結局の所、ライブラリや実行環境という
必要もないのにpromiseを使ってる例を教えてね。多分必要があるからそう書いてると思うよ。
> 必要もないのにpromiseを使ってる例を教えてね。多分必要があるからそう書いてると思うよ。
それは当たり前にpromise返すよね。
>>731 並列で処理したいとか思ってないんだが？
データがないとその先の処理はできないんだから非同期にする理由がない
ただデータを欲しいだけで、その処理を並列でやろうとか思ってない
なのにPromiseを強要されるって話をしてるんだが？
言っただろ？
そういうのは、非同期に処理したいときだけ、使えば良いんですよ。
今なんの話をしてるのかわかってないのか？
俺が例を聞いて、データベースの例出してきのは君だよね？
async awaitの登場でそこら辺も意識しないで済むでしょ。
>>734 データベースからデータを取得するプログラムが
いつ非同期が必要になったんだ？ｗ
データベース自体が必要なのと、
データベースを使う「アプリ」が必要なのの
違いも区別できてないのか？
今話をしてるのはJavaScriptで作るアプリの方だろうが
>>735 async awaitを使うか使わないかを
使い分けてる時点で意識してるｗ
asyncawait全然難しくないのにそんな同期欲しいか？
>>738 どちらかに統一されるならまだしも
同期と非同期の２つが頻繁に混ざることが問題
同期メインで必要なときだけ非同期を使うほうが楽だって言ってんの
すまんけど混ざった経験がない
>>740 日付操作ライブラリは非同期ではない
普段書いてるJavaScriptコードも非同期ではない
>>723 基本的に ID:Y7rxETSL の言うとおりであって、空回りしてるのはお前が色々無知だからだ。
今言ってる「コンソール」ってのは、「『コンソール』アプリケーション」の「コンソール」であって、
つまりC/C++/Java/AWK/Perl/Ruby/Pythonのデフォの動作環境のことだ。
JSがPyhtonを滅ぼせないのはまずこれで、
動作環境が全く違うから、他スクリプト言語(AWK/Perl/Python/Ruby)の置き換えが単純には出来ない。
逆に、これらの言語間では容易に置き換えが出来、勝者はPythonになりつつある。
なおこの意味ではPHPも動作環境が全く異なるのでとりあえずは生き残る。
非同期が駄目な点は、単純に難しくなるからだ。
Python等で処理される事柄の大半は同期処理で全く問題ない。
JSの場合はC10K問題を非同期で解決するというのが宗教になってて、実際これは上手く機能しているが、
通常用途にはオーバースペック過ぎる。（データ待ちで待たされても何ら問題ない）
必要な時だけ非同期にさせろ、というのが正しくて、他言語はほぼ全てこうだが、JSは宗教だからこれを認めない。
asyncとpromiseでー、というのは、「一方ロシアは鉛筆を使った」を学んでこい。
個人的に勿体ないと思うのはIndexedDBの同期I/Oが廃止されたことだ。
書き込みだけでも同期I/Oが残っていればbeforeunloadで使えて、LocalStorageを廃止出来たはずだが、
現状そうでないからJS的に目の上のたんこぶな同期強制のLocalStorageを廃止出来ずにいる。
ここら辺は仕様を作る奴等が間抜けだと思う。
(ただし現行LocalStorageは設定値保存に使われており、
これが非同期読み出しだけになると大半の連中はまともに組めなくなるとは思う。《モーダル/モードレスよりも難易度が高くなる》
この意味ではLocalStorageを同期のままで残しているのは現実的な方策ではある）
>>738 > モラルハザードが起こるから要らないんだけど
これが典型的な宗教家だよ。
本来誰でも簡単に組めて、技量があればもっと素晴らしくも組める、というのが正しくて、
技量がないと組めない、というのは間違いなんだよ。
サーバーアプリも、DBつつくと無駄に非同期がいるから、JSよりもPHPの方が簡単に書けてしまう。
これがJSがPHPを滅ぼせない理由の一つだよ。
今言ってるコンソールって誰も言っていません。どこで出てきましたか？
indexedDBの同期apiがなくなったのは当たり前。localstrageも非同期になって欲しいくらい。
> 俺は幅広いユースケースに対応できるのはjsだよねって話しています。
非同期が必要ないユースケース＝待ち時間にする処理がない場合
>>743-744 お前が日本語もプログラミングも出来ないのは分かった。
相手する価値がないからもうやめにする。
> pythonが勝者だというソースを出してください。
と言う以上、お前はこれを否定出来るソースを出せるのだろ？まずそれを出せ。
このレベルの既知の事柄についていちいちソースソース言われても話が進まなくてウザイだけだし、
そもそもこの点に反論したいのなら743の時点で君が君側のソースを出す手もあった。
それが出来ないのは君が会話が出来ない馬鹿だからだよ。
> localstrageも非同期になって欲しいくらい。
これも既に言ってるだろ。
JS界では同期I/OのLocalStorageは以前から問題視されてて、非推奨とされているが、いまだに廃止出来てない。
それは廃止出来ない理由があるからであり、俺は既にそれを言ってる。
君は日本語が不自由だから話について来れず、何度も同じ事を説明されないと分からない馬鹿だ。
それだと話が全く噛み合わず、進まないんだよ。
実際、他の件もそうだろ。ここで会話出来る最低限の日本語レベルに達してないし、プログラミングの知識もない。
まあそれでも君みたいな馬鹿でも非同期ガーとイキれるのはJSの良いところで、
つまり馬鹿でも出来てそれなりに見栄えのする結果も得られ、出来ると勘違い出来る言語、ということでもある。
ただ、イキってる馬鹿はどの言語にもいるが、JSのイキリ馬鹿は他言語に比べてもだいぶ酷い。
よくよく考えてみると、JavaScriptでPromise（≒非同期）を使う場合って
>>748 >よくよく考えてみると、JavaScriptでPromise（≒非同期）を使う場合って
>「処理が終わるまで（何もしないで）待つ」時に使ってるよな？
待つ時以外にも用途があるわ。
例えばファイルをreadする処理がある場合、非同期だとreadする時間を有効活用して何か処理を実行できたりするだろ
>>750 > 非同期だとreadする時間を有効活用して何か処理を実行できたりするだろ
うん、可能性としてはそういうこと出来るよね。
でも、そんな考えで非同期使ってることってほとんどまずないよね
ただ待つためだけに使ってるよね。
ちゃんと画面を反応を止めなくするため or 他のリクエストを処理するために
非同期使ってますって意識してる？
それを知ってるなら、コンソールアプリなどのユースケースは
勿論手元でワンライナー書く程度のどうでもいい用途には同期APIで十分
>>754 そしてそのどうでもいい用途向け言語がいわゆるスクリプト言語で、実際にそういった用途が大半なわけだ。
状況が変わってきてるんだよ。
昔と比べて（文系含め、コンピュータのことを全く知らない、いわゆる）馬鹿がプログラミングするようになった。
これ自体はスマホが一般化するのと同様に自然な流れなのだが、その分、簡単な言語が必要とされるようになった。
Pythonが伸びているのはこれ。他と比べて比較的簡単だから。
PHPに至っては、プログラミングの何たるかを知らなくても何とかなってしまうという、すさまじく簡単な点が受けている。
（なおC->Javaに移行したのも簡単だからだ。というか、ど素人含めて全員Cで書け、という90年代が今から考えたら無茶すぎた）
非同期が駄目ってわけではないが、非同期縛りは馬鹿にとってかなり高い参入障壁になってる。
JSやって最初に引っかかる点も大体ここだろ。
JSが覇権を取る為に何かを修正するのなら、俺はここだと思うね。
逆にPythonが覇権を取る為には実行速度で、連中があまりここに着手しないのが俺にはよく分からない。
（とはいえPythonにはそれ以前に色々駄目な点が多いが）
ついでに言うとRubyも実行速度だと思う。
Pythonが今程度に遅いうちにJSの速度に追いつけば、Pythonを食う可能性も十分あると思うのだけど、
連中も何故かあまりここには手を付けないんだよね。
>>754 なんでワンライナーが基準なの？
曖昧なこと言ってないでもう少し具体的に言おうか
少なくともJSにとっては大半じゃないよ
例えばgitの実装なんか、非同期処理は殆どいらないだろ？
CLIコマンドのほとんどは非同期は必要ない
>>757 Perlが覇権取ってたのは事実だが、それも過去になりつつある。
Perl6に移行してる奴はほぼ居なかったはず。
そして今時は「インストールスクリプトでPython使ってます」という理由で
Pythonがインストールされてないとインストール出来ない物が当然のように出てきており、
俺のPCにも使いもしないPythonはインストールされてる。2も3もだ。
この意味ではPython汚染はPerlより酷いと思うよ。
なおRubyもインストールされてる。同様に何かRubyを必要とする物があって入れたと思った。
まあこれがいいかどうかはさておき、JSはこの分野に進出出来ないでいる。
これが覇権を取りきれない理由でもある。
JSサイコー、愛してるぜ・・・(*´Д`)ﾊｧﾊｧ
日本国内でjavascriptを使えるプログラマーはどの位いるのでしょうか？
このスレへの固定リンク： http://5chb.net/r/tech/1475332848/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ55【php,py,pl,rb】 [無断転載禁止]©2ch.net YouTube動画>3本 ->画像>3枚 」 を見た人も見ています：・ん 尼 ﾃｽﾄ ) ∫ る . 肴 | 上 も 空牙 g 石井 幾何 ω て 石 んほ て 交流会 会7 t ^ 虎専 n んあん む て a k ほれ 愚痴 報告 t _ . て 珈琲4 ^ 奈良 J は t , ' o 報告 て - 8 愚痴 . _ 雑 e ま 7 ﾃｽﾄ y t
04:02:49 up 28 days, 14:26, 1 user, load average: 7.66, 8.77, 8.82
in 1.305018901825 sec
@1.305018901825@0b7 on 010918
![【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ55【php,py,pl,rb】 [無断転載禁止]©2ch.net YouTube動画>3本 ->画像>3枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/07PL6Yh.png)
ブックマークへ![【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ55【php,py,pl,rb】 [無断転載禁止]©2ch.net YouTube動画>3本 ->画像>3枚](https://rz.anime-tube.win/pic.php?http://pbs.twimg.com/media/Dy9NfMKU0AAjOgP.jpg)