【JS,PHP,Python】スクリプト,バカロワイヤル32【Perl,Ruby】
1 :
デフォルトの名無しさん :
2013/04/20(土) 21:45:08.37 JavaScript, Perl, PHP, Python, Ruby, …
スクリプト言語をすべて扱うスレッドです。
最強のスクリプト言語は、どれよ?
さあ、死ぬまで語りやがれ!!!
■ スクリプト言語の用途
Webアプリ、シェルスクリプト
■ スクリプト言語の特徴
実行速度に優れているわけではないが、
取り回しに優れ、コードの作成や修正が容易、プログラマの負担が軽い!
・インタプリタ
・動的型
・正規表現
・クロージャ
などを利用できるものがある。
JavaはJavaScriptとは全くの別物でありこのスレで対象としていません
Java語りたいならよそでやれ
長いコードはここで
ttp://play.island.ac/codepaste/ 【JS,PHP,Python】スクリプト,バカロワイヤル31【Perl,Ruby】
http://toro.2ch.net/test/read.cgi/tech/1365250318/
Node.jsってechoサーバみたいなトイプログラムは簡単に書けるけど、 ちょっと規模が大きくなると他のフレームワークと差が無くなる そういうところはRuby on Railsと似ている (性能面でも、IO多重化を使うフレームワークの中では並) あと、ステマが激しいのも一時のRailsと似ている
規模が大きくなるとフレームワーク以外の部分でやらなきゃいけないことが 増えるからな
>>2 その意見には賛成できない。
なぜなら、
> Node.jsってechoサーバみたいなトイプログラムは簡単に書けるけど、
トイと言うのはあんたの意見であり、トイとはいえ、簡単にかけると認めている。
> ちょっと規模が大きくなると他のフレームワークと差が無くなる
この根拠が書かれていない。
> そういうところはRuby on Railsと似ている
「そういう所」つまり上の行はまだ立証されていない。
> (性能面でも、IO多重化を使うフレームワークの中では並)
そのフレームワークの具体名がでていないので比較しようがない。
本来ならば、あんたが並であるというデータを持って来るべき。
知ってるなら持ってこれるはず。
> あと、ステマが激しいのも一時のRailsと似ている
ステマであるという根拠が書かれていない。
Railsと似てるのかどうかもわからない。
そもそもNode.jsはフレームワークではないので
>>2 は根本的に勘違いしている可能性が
極めて高い。
ステマの根拠も一切無いけどw
>>2 みたいな中身に根拠が無い文章って
単語を入れ替えても成り立つんだよw
別のフレームワーク名にしても成り立つからやってみw
RailsとかはASP.netなどはフルスタックのフレームワークと言われるもの。 JavaScriptはフルスタックのフレームワークはない。 node.jsとかexpressとかバラバラの分断されたのを寄せ集めて作らないといけない。 どのバージョンの組み合わせなら動くかなども気にしないといけない。 情報収集や学習に時間がかかり、コストは高くつく。 現状はnode.jsはリアルタイム処理が必要なごく一部のサイトで 限定的に使われているだけ。
>>10 > 現状はnode.jsはリアルタイム処理が必要なごく一部のサイトで
> 限定的に使われているだけ。
それはお前の周りではそうだってだけだろ。
まあ俺の周りでもそういう使い方しかしてないが。
>>11 あんたの周りでもそうなら、否定スンナ
node.jsの立ち位置は世界的にそういうもんだ
リアルタイムが必要のないケースで使う必要性はゼロ
node.jsはアーキテクチャがシングルスレッドだから基本的にゴミ
>>12 ゴミではない
目的があってシングルスレッドにしているわけだし、その目的の元では当然ながら有用
要は適材適所
>>10 バラバラの寄せ集め?って
お前、Railsだって、Ruby APIなどを寄せ集めて作ってるだろ?
言語標準ライブラリを見逃したとしても
例えばRailsがTwitterのOAuth認証を標準でサポートしているわけもあるまいし、
お前のフルスタックの定義は間違ってるよ。
パッケージマネージャの機能が充実してればバラバラの寄せ集めで問題無いね Railsもバラバラ化を進めてる感じじゃないか
Compound.js Geddy Sails.js Node.jsのフレームワーク、ここら辺は押さえとけ
>>14 フルスタックは俺の定義ではなく一般的な定義だ
誰もが使うものは最初からセットにしとくべきだし
大部分のひとが望んでるのはそういうフルスタック
>>17 だからその定義であればnode.jsは寄せ集めたとしても
フルスタックなJavaScriptのフレームワークは成り立つ。
分かりやすく言おう。
フルスタックなフレームワークをインストールした。
この時、言語はフルスタックのフレームワークに内蔵されていなくてもよい。(例Ruby)
この時、実行環境はフルスタックのフレームワークに内蔵されていなくてもよい。(例 JavaVM)
この時、ライブラリはフルスタックのフレームワークに内蔵されていなくてもよい。(例Twitter OAuth認証モジュール)
MeteorがJavaScriptのフルスタックフレームワークらしいよ。
>>15 ぜんぜんちがうわ
だれもが使う機能は予めセットになっていてこそ
一般的なユーザは手軽に始められるし、安心して使える。
小さなライブラリを自分で選んで使えってのは古い。
それは昔のJavaのフレームワークのやり方
大半はそんなめんどうなのは望んでいない。
>>18 何言ってんだw
フルスタックってのは言語やVMは含まれないにきまってるだろ
フルスタックってのはもっと誰もが使う機能がはじめからあるかをいうんだよ
ORMとかテンプレートエンジンとかのことだ。
RailsもDjangoもフルスタック。これは俺の定義ではない。
Twitter OAuth認証モジュールなんて全員が使うわけじゃないから
バンドルしなくて当たり前
反対にだれもが使う機能すらはいってないのがmicro frameworkと呼ばれるもの
sinatraとかscalatra(Scala)とかFlask(Python)とか
>>20 のような奴がMSみたいな体質の企業を支えてるんだろうな
こういうのが主流になると技術が停滞する
いくつものライブラリをそろえないといけないのは時間がかかるし バージョン組み合わせのテストもしないといけない。 特定のライブラリだけバージョン上げようとしても その組み合わせで不具合がでないか自分で検証しないといけない。 こういうのが生産性の低下につながるし、実際に嫌がられている
>>23 だからパッケージマネージャが重要なんだって
いまどきのパッケージマネージャならアプリに必要な各ライブラリのバージョンを固定化したり
複数のアプリで異なるバージョンのライブラリを共存させたりできる
>>22 似たようなディストリビューションがたくさんでて
分裂しまくったLinuxはデスクトップOSで惨敗した
シェアは1%程度しかない
ベンダーがしっかりコントロールしたWindowsとMacは生き残った。
これが結果
開発者から見た使い勝手の話だろ? 素人も使うデスクトップのシェアなんてどうでもよいわけだが
>>24 パッケージマネージャあっても変わらないっての
バージョンの共存ができるとかそんな当たり前の話じゃないんだが
まったくわかってないようだな
特定のバージョンや環境の組み合わせで起こる問題ってのはあるわけよ
それくらいはわかるよな?
たくさんの人が同じ環境で使うからこそそういうバグが見つかって
品質があがっていく。
>>26 開発者でさえLinuxをデスクトップ用途でつかってないだろ
WindowsかMacだ
Linuxをデスクトップ利用してる人の大半は
Mac本体やWindows OSが買えない貧乏人ばっかり
昔はパワーユーザーが使っていたがそういう人はMacに流れた。
>>27 安定したバージョンの組み合わせで使えばいいんだよ
多数のユーザで多く使われるモジュールとバージョンの組み合わせは自然に安定する
>>27 パッケージマネージャがあっても変わらないってのは無いわw
RubyとかもうBundler無しじゃやっていけんw
モジュールが別れてても、依存関係がきっちり指定されてれば、 それはフルスタックのフレームワークと代わらんと思うけどね。 Railsだって複数のモジュールに分割されて提供されてるわけで。
node.jsでも普通にパッケージマネージャー使われてるし 何が言いたいんだかさっぱりだ。
パッケージマネージャーはnpmが抜きん出ているな
>>21 > フルスタックってのはもっと誰もが使う機能がはじめからあるかをいうんだよ
> ORMとかテンプレートエンジンとかのことだ。
「誰もが使う機能」になんでORMやテンプレートエンジンが含まれるんだ?
それがおかしいと思わないのか?
例えばGUIアプリを作るのにテンプレートエンジンは使わないだろ?
何を作るかで「誰もが使う機能」は変わってくるんだよ。
クライアントウェブアプリを作るのにORMは含まれない。
なぜならデータベースに接続できないからだ。
だからクライアントウェブアプリのフルスタックにはORMは含まれない。
ここまでは理解できるか?
Compound.jsがフルスタックだ これで解決だろ 遅いRails使いが悔しがっているだけ
GUIアプリを作るのにRailsはフルスタックと言えない。 じゃあフルスタックとは何か? それは「何のフレームワークか?」って所が重要になる。 Railsとかウェブ関係の人は、ウェブの世界しか知らない人が多いから 自分の常識の範囲で物事を語ってしまう。 Railsとは何か? それは「MVC設計に基づいたサーバーサイドフレームワーク」 「MVC設計に基づいたサーバーサイドフレームワーク」としてフルスタックということを 単にフルスタックと言っているだけ。 この「」の中身が違えば、フルスタックとして要求される機能は変わってくる 「Windowsアプリのフレームワーク」ならGUIコンポーネントが無ければフルスタックにならない。 何のフレームワークかを先に決めないと、それがフルスタックかどうかなんて決まらない。
38 :
デフォルトの名無しさん :2013/04/21(日) 02:57:10.70
JSはライブラリが乱立し過ぎだよな。 似たような機能で微妙に違うのがいくつもあって、デファクトスタンダードと言えるのはjQuery位か。 処理系の実装からしてバラバラだし。 TypeScriptなんかも結構良さそうだけど、果たしてこれに掛けて良いのか、判断難しい。
39 :
デフォルトの名無しさん :2013/04/21(日) 03:01:51.56
まー、CとかC#とかだと、フレームワークと言っても幅広いけど、 スクリプト言語のこのスレで言う場合、フレームワークとは、バックエンドにデータベースがあるのを前提としたウェブアプリケーションの為のライブラリ、ウェブフレームワークを指すって事でいいのでは。
>>38 jQueryすらPrototypeとかYUIとかと競合してるだろ(震え声)
>>37 馬鹿な揚げ足取りはいらん
いまだれもGUIアプリの話なんてしてないだろ
Web frameworkの話をしていてフルスタックといったら
full stackのweb frameworkだなとわかるわけ
わからないなら、基本的な用語の知識がない
>>40 競合がない技術なんて
世の中にないだろうなw
>>41 > Web frameworkの話をしていてフルスタックといったら
> full stackのweb frameworkだなとわかるわけ
じゃあ、JavaScriptで(サーバーサイドの)web frameworkってなに?
それがフルスタックかそうでないかの話だよね?
議論の次元が低いな スクリプトスレだけあって
>>42 YUIやprototypeはまだまだシェアがあるから、無視できない(正論)
>>43 それらを用いた開発なんかありえんし、そもそも一部はRails本体になっているはず
>>44 JSのフレームワークの世界では、他の言語のフレームワークでいうところの
フルスタックにあたるものはない。
>>47 Compound.jsがあると書いてあるだろ
白痴か?
Meteorはフルスタックじゃないのか? サーバーサイドどころか、クライアントサイドも一部 含有してる雰囲気だが
50 :
デフォルトの名無しさん :2013/04/21(日) 07:42:23.11
>>27 いまどきのパッケージマネージャについて勉強しておいで
>>40 ♪こーいしちった
アンケートで「その他」が一番多い場合にも「その他」を1位とは認めない というルールがある だから「その他」は1位にならない でもそれは現実を反映したデータではなく、ただのルールだろ これが結果だとか現実を受け入れろとかバカじゃねぇの
ぶっちゃけクライアントとサーバでデータやり取りする層なんて どのフレームワークでも馬鹿でも書ける(適当な下請けに丸投げ可能)程度の単純作業 そんな物の優劣なんてどうでも良いんだけどな
>>50 サーバ用途にLinuxも使ってるしいまどきのパッケージマネージャとやらも知ってるよ
新しいものでも依存関係を完全に管理できてない
ディストリビューション次第で動かないrpm、debパッケージがあるなんて常識だし
アンインストールでもアップデートでも依存関係ぶちこわれる問題もまだある。
あとフレームワーク全体の品質の話してるんだからパッケージマネージャだけでは解決策にならない
それは同一パッケージの中の依存関係を解決するだけのもの
ファイルレベルでしか解決できない
連携して機能する別のパッケージ、モジュールと組み合わせた場合に
上手く動くかはまったく関与しない
他のパッケージと連携して動く場合は、各パッケージが安定しているからといって
組み合わせた場合に安定するとはいえないわな
なんでこんな当たり前のことを説明しないといけないのか
54 :
デフォルトの名無しさん :2013/04/21(日) 09:37:11.53
>>49 有名サービスでの採用事例が見つからないようなフレームワークはどうでもいい
海外ですら人気でてないもの追いかけてられない
>>48 Compound.jsなんて知らないしだれもそんなもの使ってない
JS信者は誰も使ってないようなもの名前あげて得意になってるよな
ほんとレベル低い
55 :
デフォルトの名無しさん :2013/04/21(日) 09:46:07.34
>>54 Meteorに有名事例がないのは、とても新しいフレームワークで
未だPreview版だから
しかし、注目度はかなりある
そうそうたるメンバーが投資しているし、
将来的には次々と使われるのはほぼ確定してるよ
だから、このスレの人はラッキーだね 情報が早い人がMeteorを挙げてくれたおかげで、 次世代の波をキャッチできた
58 :
デフォルトの名無しさん :2013/04/21(日) 10:10:09.03
>>55 名前変更前のRailwayJSを考慮していないし
名前の通りRailsをリスペクトして作られているのだが
お前は何と戦っているんだ?
時間の経過を無視している事から少なくとも馬鹿だよお前
Meteorは1600人のフォロワーか すでにブレイクの兆候が見られるな これからブレイクに立ち会えるとは胸熱
62 :
デフォルトの名無しさん :2013/04/21(日) 10:24:09.85
meteor厨はなんなんだよw
>>53 残念だけどrpmとかdebは今時のパッケージマネージャとは言えないぞ
今時のスクリプト言語がrpmとかdebとは別の独自パッケージマネージャを用意してる
意味がわかってないんだな
>>64 すまん、質問数とフォロワー間違えてた
まあ、600でも結構多いと思うけど
既にsinatraくらいの質問数だしな
荒らしてると思ってるようだが、次世代を適確にキャッチアップして 情報を流していると言って欲しいな そりゃまあ時代の流れについていけずに 受け入れられない気持ちは分かるが 悪いことは言わないから、javascriptやmeteor、nodeあたりの 情報はしいれていた方がいいぞ 将来的にも仕事が欲しいならな
フォロワー数で価値を見るアホがいると聞いて
>>67 良いものは自然と人気が出るんだから、
人気やユーザ数をはかるよい指標になるだろ
google trendでは検索数だからあてにならない
違う意味の検索結果も反映されてしまう。
>>68 フォローとのタイムラグなんて誤差レベルだ
本当にリリースされたばかりでもなければ時間は関係ない
古いものでも人気がなくなったものはちゃんとフォロワー減ってる。
使わなくなって乗り換えればフォロー外すのがふつうだからだ
71 :
デフォルトの名無しさん :2013/04/21(日) 10:50:42.48
Meteorとかあの手のMVVMって、そもそもMicrosoftが提唱したデザインパターンだよな。
まあフォロワー数は知名度と注目度がある程度分かると思う 時系列のグラフが出ないのが難点だが trendsはprogrammingとかweb frameworkと言った言葉と一緒に 検索すれば、関係ないのがフィルターされて結構使えると思う
>>71 起源は分からないけど、asp.net mvcの制作者たちも、meteorは相当意識してる
見たいだね
そういうブログ見かけた
逆に、乱立は不人気の証拠か? 人気だからモノマネが乱立するという解釈もできるんだが
>>74 それは基本的には人気ある証拠
ただ、まだまだ不満がたくさんあったり、新しい概念が
出てきすぎて試行錯誤してる段階だという意味でもある
76 :
デフォルトの名無しさん :2013/04/21(日) 11:14:50.05
ブラウザのJSの実装が進んで、クライアントサイドプログラミングがし易い状況になったから、AngularとかKnockoutとかMeteorとかMVVMのフレームワークがワラワラ出て来たけど、Windowsでデスクトップアプリ作って来た人にはお馴染みの開発手法でしょ。
このスレってMeteorを実際に使ってるヤツ居るの? それとも使った事も無いのにすげーって言ってるの?どっち?
結局Javaのフルスタックフレームワークあるじゃんw 違うというのなら、どのフレームワークは違うのか その名前言ってみ。
Meteor使ったことあるかないかと Meteorがフルスタックという事実は 無関係。話をすり替えようとしてるよね。
>>79 いや、そういうんじゃなくて、使ってるヤツが居るなら質問したかったんだよ
Meteorって明らかにコード書きやすいけど、あれってPythonのgeventみたいに
非同期IOを同期っぽく書けるようにしたのか
それともIOが非同期じゃないのか分からなかった
いや、ネットでちょっと調べたらIOが非同期じゃないって書いてあったんだけどね
というか、使うのは非常に簡単だよ コマンドライン一つで全世界に公開しちゃえるしw
Meteorがフルスタックじゃないと言ってる奴はいないのか。 じゃあ結論でたな。JavaScriptにフルスタックフレームワークはある。 この前提でいいならということなら、話を進めようか。
>>80 すまん、meteorのIoってどの部分のことを言ってるのかよく分からん
単純にリクエストのやり取りのこと?
その部分はnodeだと思うんだけど
>>83 この辺にも書いてあるんだけど、どうやら普通のnode.jsスタイルで書いた場合と
違ってリクエストに対し同期になるみたいね
http://docs.meteor.com/ > In Meteor, your server code runs in a single thread per request,
> not in the asynchronous callback style typical of Node.
> We find the linear execution model a better fit for the typical server code in a Meteor application.
>>84 英語がわからない人のために、Google翻訳にかけましたよ。
唯一のサーバ資産は、JavaScriptです。流星は、クライアントと公共のサブディレクトリの下に何を除く、
すべてのJavaScriptファイルを収集し、繊維内部にNode.jsのサーバー・インスタンスにそれらをロードします。
メテオでは、あなたのサーバーのコードではなく、
ノードの典型的な非同期コールバックのスタイルで、リクエストごとに単一のスレッドで実行されます。
我々は、線形実行モデル流星アプリケーションの典型的なサーバーコードのためのより良いフィットを見つける。
まあ確かに言われてみれば、同期スタイルでdbいじるコードとか書くけど、 実際に同期なのかね? Google翻訳の方には「繊維」とか出てるけど、これfiberだよね? なら本当は非同期だけど同期スタイルで書けるってことでしょ
87 :
デフォルトの名無しさん :2013/04/21(日) 12:33:45.01
英語がわからないの人のためにGoogle翻訳にかけました wwww お前が一番わかってないんじゃん
>>86 お、使ってる人っぽい。
確かに同期っぽく書いてるからって同期してるとは限らないから
質問したんだけど、非同期でFA?
| | ___ \ / . ャ:´/ /: : :l: :`ヽ、 \ | | / \ / /:/: : ;{: : : : : ハ :`ヽ. \ / _ 争 も _ / : / / ヘ.: : : : : : : : :!:.ヽ: :\ _ 争 _ _ え っ _ ,:':.:/,' / 丶: : : : : : : ト.: :ヘ: : ヽ _ え _ _ : . と _ /: : : /|/ _ ` 三_‐ミ!:l: : :i: : ハ _ : _ _ : _ ' : : : i: :| '´ 二 :::::::::: 二¨¨` !: : : : : : : i _ : _ |: :〃:|: :i. 不j下:::::::::::不:j下 .' : : : : : : :.| / \ !: :|: : : :ム ー' ::::::::::::: ー' /: :,: : : : : : リ / \ / | | \ ヘ: : ; ; ;、_ヘ_'' ._' _. ''/:.ィ: : : : // / | | \ `<: : : ≫ . ´ヤ: : : : :,: イ 乂`: : : リ≧‐‐≦、ム: : :_:ノ `ト: :ヽニr〒ニ{: : : リ=、 ≠ゝ:、メ、,ゝl、γ: : ィ≠ ヽ { 乂:_:リ./ | 弋彡'/ !
お題
StackOverflow の API を使ってスクリプト言語の人気を調査しなさい
https://api.stackexchange.com/docs どんなデータを取得してどう評価するかは問わない
ただしレスポンスは gzip または deflate でもらうこと
例)タグ付けされた質問の数で人気調査
$ ./stackoverflow perl python ruby php javascript
php: 376924
javascript: 363342
python: 181287
ruby: 70827
perl: 26347
(quota: 299/300)
(
>>55 みたいにフォロワー数も拾えればと思ったんだけど見当らなかった)
お題 ifとelseで半分こしなさい
>>90 # Python3
import sys, io, gzip, json
from urllib.request import urlopen
for arg in sys.argv[1:]:
src = urlopen('
https://api.stackexchange.com/2.1/tags/%s/info? '
'site=stackoverflow' % arg).read()
d = json.loads(gzip.GzipFile(fileobj=io.BytesIO(src)).read().
decode('utf-8'))['items'][0]
print(d['name'], d['count'])
毎度思うんだけど、コードの違いって
ほとんどがライブラリの違いになってるよね?
もしライブラリが同じという前提に経つと
for(arg in sys.argv[1]) {
var src = urlopen(sprintf('
https://api.stackexchange.com/2.1/tags/%s/info? '
'site=stackoverflow', arg)).read() ;
var d = json.loads(gzip.GzipFile(fileobj=io.BytesIO(src)).read().
decode('utf-8'))['items'][0];
print(d['name'], d['count']) ;
}
大抵同じようにかけるかな。
>>93 > もしライブラリが同じという前提に経つと
何でそんな無意味な前提に立つの?アホなの?
あとJavascriptはこの御題に有利だぜ?
jsonを直接evalできるから。
大体同じように書けるというなら、スライス記法まで模倣するべきだな
meteorが注目を浴びている理由って、どこぞのエンジェルが莫大な額を投資したからだろ ぱっと見でも、express.jsの方が普通に使われてる
97 :
デフォルトの名無しさん :2013/04/21(日) 18:11:20.31
>>93 同感
言語そのものというよりも、ライブラリが生産性を分けている
ただ、JavaScriptは完璧なクロージャを備えていたから
イベントモデルや非同期処理と相性が良かったという面や、
JSONのような記法を備えていたからDSLのような使い方が出来た
という側面も忘れては行けない
どのみち新しい仕組みなんてのは、 枯れてきたところでMicrosoftクンさんが追従してくれるから、ASP.NETで安心だよね
まあ確かにMicrosoftはそういう安心感があるよなあ
#python2 2行変更 from urllib import urlopen print d['name'], d['count'], "|", $./stack_lang.py lua qt4 qt5 laravel-3 laravel-4 laravel php lua 3605 | qt4 3768 | qt5 367 | laravel-3 130 | laravel-4 222 | laravel 1022 | php 376976 | バージョン変わると書き方変わったりするし 何とも言いがたいもんがあるか
淡々とコードが貼られる言語と、 フレームワークだ何だという話題のときだけ出てきて 実際に動くコードは決して貼られない言語があるな
>>93 豊富なライブラリという意味ではスクリプト言語のなかではPythonが頭ひとつ抜けてるわ
>>102 Webアプリってレベルで考えると、コード片なんて役に立たないから
使い捨てコードだけで考えればRubyがベストでも、
なんだかんだでjavascriptがバランス取れてるってのが世界の選択だよ
Javascript the language of the world!
っ論より証拠
まあ御題も下らないけど、JS厨の逃げ口上は面白い その言い訳書き込む時間でコード書けるだろと
こういうのがお望みなのか
var zlib = require('zlib');
var stream = require('stream');
var https = require('https');
https.get("
https://api.stackexchange.com/2.1/tags/meteor/info?site=stackoverflow ").on('response', function(res) {
var output = zlib.createGunzip();
res.pipe(output);
var body = "";
output.on('data', function (data) {
body += data.toString();
});
output.on('end', function() {
var data = JSON.parse(body).items[0];
console.log(data.name + ' ' + data.count);
});
});
JS厨の中で一人だけnode.jsを実際に使ってる人がいるね。 いつもインデントしてないという特徴がある。
むしろ、実際に使うやつはバカ
metasploit規模のApplicationって何があるんだろ
>>109 2chにソースコード貼ったらインデントが消えてるんだよ
node.jsはon('foo', function(bar){}が好きなんだな。
1000 名前:デフォルトの名無しさん [sage]: 2013/04/20(土) 16:46:54.46
>>999 tibeなんて、検索エンジンで引っかかった数見てるだけだから
あんまり開発言語の人気を表してない
google trendsで「Javascript programming」とでもやった方がマシかもw
TIBOEでCが強い理由が解明されたw 組み込みとかで使われてるのかなと思ったら単に検索エンジンで引っかかりやすいからだったw
TIBOEでRubyが思ったより順位が高い強い理由が解明されたw 単に宝石のRubyが検索エンジンで引っかかりやすいからだったw
pythonもモンティ・パイソンが!とか言うんだろうな JS信者のキモさは言語に似て限界突破してるしずっとこのスレに粘着して糞工作続けてて目障りすぎる
>>118 しかもソースコードもかけちゃうし、やたらと詳しいしなw
無知極まるし理解力ないし
>>119 みたいな恥ずかしい自画自賛を繰り返すし最悪なんだが
モンティ・パイソン か パンティ・モイソン かしらんが キモいわw
>>120 3年後にJavascriptの時代が来ても知らんぞw
>>123 pythonが高いのだけ納得がいかんわ
なんでこんなに高いんだ
Pythonはニシキヘビが引っかかってるんだろ
programmingも付いてるんだから、それはない
C ProgramingってC++も入っちゃってるだろ
もう入ってんねんからええやんけ
つまり実質一位はJavaか CはC++と共同で一位
下手するとCはObjective Cとかも相当入ってそうだしな JavaはJava Scriptが入ってる可能性もあるが
結局tiobeと同じような結果じゃね?
>>135 いやいや、なんかその値はおかしいぞ
なんだその現象は
何が起こってるのかすら俺には分からんw
>>134 PHPやJavascriptの値が大きく違うような気がする
>>138 つまり、
Java 15
C 12
C++ 10
って感じかね
だがよく考えてみてほしい。 普通後ろにprogrammingなんてつけるだろうか? 普通は付けない。なぜならつけなくても プログラム言語として検索できるからだ。 ただひとつ、Cを除いて。 C アニメ 『C』(シー)は、竜の子プロダクション制作の日本のテレビアニメ。 2011年4月から6月にかけてフジテレビ・ノイタミナ枠などで放送されていた。 副題には『THE MONEY OF SOUL AND POSSIBILITY CONTROL』が表記されている
そりゃ日本だけだろ
あとグーグルの検索結果はユーザーの地域だけじゃなく 検索履歴やgmailのやりとりなどで表示結果を変えるから お前の結果がおれと同じという保証はない
>>139 本当にC++を検索したい人の多くが
Cで検索するならね
なお、googleで"C programming"で検索すると
C++だけのページは少なくとも上位には出てこないので、
google自体はCとC++は違う単語として認識している
JSのうんこっぷり
>>143 俺の場合一番上にいきなり、C++との合同ページが出てきて、9番目くらいに
Objective Cのサイトが出てくるぞ
確かにC++のページは結構少ないみたいだけど
web専用スクリプトであるJSやRubyが他の汎用言語と比べて上位に来るわけない
>>147 pythonとruby以外ものすごい勢いで落ち込んでるなw
JSは人気急上昇中じゃなかったの???
Programmingをつけるのと付けないのでここまで違う。 ・つけた場合 Python 43 PHP 38 Perl 31 Ruby 18 JavaScript 14 ・つけない場合 PHP 55 JavaScript 34 Python 14 Perl 13 Ruby 13
>>147 それだとブラウザのJavascriptが引っかかってJavascriptが有利な上に、
ニシキヘビやら宝石やらが引っかからないPerl(真珠とは綴りが違う)が不利
>>150 Googleの場合は、検索ページ数じゃなくて
検索数だから問題ないよ。
>>151 プログラミングやらない人でもJavascriptは検索しそうだけどね
Javascript off とかさ
>>148 「Javascriptを有効にするやり方」とか「JavaScript素材集」みたいなサイトが
下火になってるだけだろ
>>153 つまり、全体的に下火になってるってことだよね
>>154 まあブラウザの設定ではJavascript当たり前になっちゃったし
素材集とかでホームページ作る時代でもないしね
全体的には下火なんじゃないのw
苦しいのうw
つまりプログラミング目的で検索してる奴に絞ると
>>123 になると
そう「Javascript Programming」は人気上昇中 ここから加速度的に上がる 今はその兆しが見えかかった段階
でも、Javaが予想以上に凄いな やっぱサーバーサイドといえばJavaなんだな
>>159 数年前のPHPも半端無いしな。もうオワコンっぽいが
クソ言語でも使われるんだよなあ、JSとかまさにその典型だろ
デファクトスタンダードでこの検索数ってどんだけ嫌われてんだというね
JSを使う必要がないところでは一切使われてないんだろうな
代替がある言語は好きで使ってる数だが
俺が言いたいのは、Programing というキーワードはデータを歪めないのか?ってことだよ。
どの言語にも存在するであろう if をつけてみる
・if
http://www.google.co.jp/trends/explore#q=Javascript%20if%2C%20Perl%20if%2C%20PHP%20if%2C%20Python%20if%2C%20Ruby%20if&cmpt=q PHP 84, JavaScript 67, Perl 27, Python 21, Ruby 8
・同様にfor
http://www.google.co.jp/trends/explore#q=Javascript%20for%2C%20Perl%20for%2C%20PHP%20for%2C%20Python%20for%2C%20Ruby%20for&cmpt=q PHP 74, JavaScript 51, Python 28, Ruby 23, Perl 21
・object
JavaScript 54, PHP 18, , Python 8, Perl 4, Ruby 3
以下偏ったキーワード
・Perlにしかなさそうなscalar
http://www.google.co.jp/trends/explore#q=Javascript%20scalar%2C%20Perl%20%20scalar%2C%20PHP%20%20scalar%2C%20Python%20%20scalar%2C%20Ruby%20%20scalar&cmpt=q Perl 33, PHP 5, Python 1, JavaScript 0, Ruby 0
・PerlとJavaScriptにはないclass
http://www.google.co.jp/trends/explore#q=Javascript%20class%2C%20Perl%20class%2C%20PHP%20class%2C%20Python%20class%2C%20Ruby%20class&cmpt=q PHP 72, JavaScript 39, Python 19, Ruby 11, Perl 4
・PythonとRubyにあるdef
Python 56, Ruby 23, PHP 5, JavaScript 3, Perl 0
いくつかリンク入れ忘れたw
>>161 ifとかforで検索する奴は低能だろ
あれ?PHPとJavascriptが多いな?
なるほど納得できるw
>>163 そりゃ、CoffeeScriptのwikiだとそうなるだろw
JavaScript比定がCoffeeScriptの存在意義だぞ
167 :
デフォルトの名無しさん :2013/04/22(月) 00:25:41.13
検索数ベースでの比較だと、 どういうキーワードとるかで結果は大幅にかわってしまう StackOverflowのフォロワー数のがあてになると思うわ php, Python,C#, Javaは30,000人越えしてるが、perlは6200人くらい。 コードベースは多いが、新規で興味を持っている人は少ないという実態を反映してる。 Rubyは14,000人。 Railsはフレームワークではトップなのに、Rubyタグのフォロワーは少ない。 RubyがRails専用言語といわれるほどRailsに偏った利用実態をよく反映してる。
科学、数学、統計、自然言語処理、機械学習などの関連キーワードではPythonの圧勝
Perlは完全にPythonに抜かれた PHPとJSは今の傾向が続けばPythonに抜かれそう
JSの派生言語が量産されたのはJSが糞だからだけど JSの検索数が減ってるのは派生言語に分散してるからではないよw
>>173 > JSの派生言語が量産されたのはJSが糞だからだけど
それは間違い。JavaScriptの派生言語が増えているのは、
単にブラウザで動くのがJavaScriptだけだから、
JavaScriptの派生言語にするしかないだけ。
本質的には、違う言語が出現した。それだけの話。
新しい言語が出来たのは、既存の言語が糞だったから。とか言うわけ?
> JSの検索数が減ってるのは派生言語に分散してるからではないよw
最近は増えてきてると思うが?
JSが糞だから、わざわざコンパイラ作ってまでJS以外の言語で書こうとするんだよ
C言語が糞だったからJavaScriptを作った。
>>175 世の中にいろんな人がいる。
クソと思う奴もいれば、
そのJS以外の言語の方をクソだと思う奴もいる。
どちらをそう思うかは、データによって示されている。
>>174 >新しい言語が出来たのは、既存の言語が糞だったから。とか言うわけ?
CoffeeやTypeに関しては、その通りだよ
JSが糞じゃないとか言ってる奴は頭が逝ってるから会話は成立しないと思うけど
>>178 違う。
糞だったからではなく、
作者が糞だと思ったから。
「糞だと思ったから」はただの主観にすぎない。
別の言語を作らずに、JavaScriptを改良していった方がいいという意見も多い。
JavaScriptを変更したら互換性がなくなって古いブラウザで動かなくなる。
という問題は、とある言語が教えてくれた。変換すれば良い。
Googleはもっと早い段階でDartに移行させるべきだった。 AndroidもGoで開発させるべきだった。 結局JavaとJavascriptと言った性的・動的言語の二大糞を延命させてしまったのがGoogle
>>179 あぁ、そうだね。自分のことをよくわかってるね。
>>181 あ、知ってる。
自分の気に食わない者は
全部クソって言っちゃう人でしょ?
よくいるーw
>>180 お前の理屈だと糞な言語はないということになるじゃないか
JSの改良だの変換だの、とにかくその辺は終わってる
そういうプログラミングに関わる必要がなくて本当に良かった
JSを好きでやってる人はいないし、嫌々使わなければならない人には本当に同情する
>>184 何いってんだ?
糞な言語の定義は、生まれたけど普及しなかった言語でいいだろ。
CoffeeScriptとか、少なくとも今はこの定義に当てはまってる。
そりゃ技術は発展するし、延命させられた旧世代言語が糞なのは仕方のないことで それは普通に認めるべきだろう でも世の技術書は盲目的に褒めるだけだよね、まあそうしないと売れないのだろうが C言語くらいじゃね?この言語はここが糞だから気をつけろと堂々と書いてあるのは
>>185 それはお前に都合の良い定義なのだろうなw
普及したら糞じゃないとか頭大丈夫か?
じゃあお前は一生パンチカードでプログラミングしてろよ
あれだって一時期は主流だったんだからな
>>184 電球あるよな。LED電球に置き換わってきている。
これは電球がクソであることになるのか?
以前より優れたものが出来たってだけで
以前のものがクソってことにはならないだろ。
なんでクソかそうでないかの二元論になってるんだ?
過去のものがあってこそ、新しいものが出来るんだよ。
新しいものに移行したら、改良されたってことをでいいじゃないか
古いものに感謝してもディスる必要はない。
で移行したか?そのJavaScriptを置き換えるものに。
初期のLED電球と同じだ。一部の点では優れているかもしれないが
問題点が残っており、移行するメリットが少ない。
これは、一部を除いて、以前の物の方が優れている。
つまり新しく作られたものの方がクソってこだよ。
>>188 いや、以前の電球は明るさの質もエネルギー効率も悪くて糞だろ。当然だ
時代遅れを正当化しても迷惑がかかるだけ
何が新しいものの方がクソだよ。老害にも程がある
>>187 パンチカードをクソだと言うつもりはないよ?
当時はあれが最先端だった。あのおかげで今の発展がある。
だけど、今は使うつもりはないよ。なぜなら、もっといいものがあるから
全ての点で優れているものがあり、それが一般に普及しているから。
でもな、CoffeeScriptはないな。
あれはできることがJavaScriptと大差ない上に違う言語になってる。
標準化もされていない長続きしそうもない言語
JavaScriptは標準化され多数の人が関わっており
将来のバージョンアップ計画もでている。
それを超えるだけの信頼度をCofeeScriptはいつ獲得するんだい?
>>189 じゃあなぜLED電球ができてから
今まで普及していなかったのか考えてみろよ。
LED電球が出来たのはいつかね?
問題点がないのであれば、出来たらすぐに普及する。
問題点があるということは、それはクソだということだ。
>>191 じゃあ今の電球も問題点があるからクソだということになる
普及してる、してないという指標がおかしい
歴史を見れば競合製品でどれをとっても優れてたものが負けたこともある
普及するかしないかは運の要素も強い
馬鹿は世界一売れているハンバーガーが世界一美味いと言うがね
新しいものはまだ普及してないからクソという理屈は意味不明
CoffeeScriptは宣伝聞く限り優れていると思った。 JavaScriptコードの半分の量ぐらいでかけると宣伝されていた。 そして比較コードを見た。 確かに行数が減っていた。 自分で使ってみた。確かに行数は減るが、 } だけの行みたいなものが消えただけ。 大きく減るのは自動補完もできそうな、functionとreturnの文字数。 改行、スペースを除いて全体的な文字数で計算すると9割まで減れば良い程度だった。
>>192 問題点がないものなんてねーよ。
お前は、問題点がある=クソなんだろう?
どんなものにも問題点はある。問題点=クソという定義なら
CoffeeScriptもクソになる。
俺はそれは問題点があってもクソという事にはならないって
言ってるんだよ。どんなものにも問題点はある。
少なくとも今はCoffeeScriptの方が大きな問題点がある。
196 :
デフォルトの名無しさん :2013/04/22(月) 01:44:11.17
coffeeはrailsの標準サポートだけあって、rubyライクにかけるからrailsと同時に使うとストレスなく書ける
>>193 > 新しいものはまだ普及してないからクソという理屈は意味不明
だからなに? 新しいものでクソなものもあるだろう?
新しくて普及してないからクソだと言ってるのではなく、
普及するまでは、他人をクソ呼ばわりする資格が無いってだけ。
>>194 それは「Coffeeらしい」コーディングができずにJS脳で書いてる可能性が高い
だが仮にどんだけCoffeeらしく書こうが、JSからは逃れられない
JSが糞だから代替を作りたいという意図はわかるが、そのJSに依存してる時点で
最初から終わってる言語とも言える。確かにお前の言うとおりクソだな
>>198 じゃあ、文字数ベースで大きく差が出来る
コードを書いて示してくれ。
>>197 それはお前に評価能力がなくて他人に責任転嫁してるだけ
糞だから糞だと言ってるだけ
普及してても糞は糞。あたりまえだろ。お前が何を必死こいてJSは糞じゃないと言い張ってるのか理解不能
>>200 お前が何に対してクソだと言ってるのか理解不能。
>>199 JSに依存してる糞言語だから無理だろうし
ソースコードが短ければ良いという理屈が理解できない
perlはPythonに比べてとてつもなく短く書けるが
それが喜ばれるのはもはやシェルの付属品としてだけだろ
もちろんJavaのような冗長なクラスや型の宣言がないことがスクリプト言語の良さだから
そういう手軽さは欲しいが普通のプログラミングなら短いより分かりやすい方が優先される
Coffeeがどうなのか知らんが、お前からしたら分かりにくい糞言語なのだろう
>>202 じゃあ何に対して「糞じゃない!」と反論してるんだ?
JSは完全無欠なのか?糞な所は一切ないのか?
ま、おれは汎用目的でプログラミングするからあえてJSなんて醜い言語を使うことはないけどもw
>>204 「糞じゃない」ではなくどの言語にも問題はある。
全てをCoffeeScriptが超えているわけでもないのに
JavaScriptを糞というなと言ってるだけ。
まったくこれのとおりだよ。
183 名前:デフォルトの名無しさん[sage] 投稿日:2013/04/22(月) 01:15:22.10
>>181 あ、知ってる。
自分の気に食わない者は
全部クソって言っちゃう人でしょ?
よくいるーw
。つけてる奴は同一人物?自己レスが目立つぞ
>>205 Coffeeに比べて糞だとは言ってないよw
JS系は全部糞なんだから
「以前より優れている」(以前が標準で進化したんだという言い方)というか、 「以前の方は糞」(今が標準で以前の物は退化したんだという言い方)をするかで その人の性格がよく分かるなw
>>209 時代遅れ言語をそこまで擁護する意味がわからん。糞は糞だろ
聖人君子にでもなったつもりなのだろうが、馬鹿にしか見えない
時代遅れっていうのは、 使われなくなってから言うもんだw まったく思い込み激しいな。 お前ん中ではなってやつか?w
じゃあなんでパンチカードは糞じゃないと言い張るんだ? 当時の人間だって糞だと思いながら使ってたと語るのに 温故知新なのか知らんがいくらなんでも無批判すぎるわ
自己矛盾に陥らないために、パンチカードを擁護する必要があったんだろうな 普及しても糞は糞という事実を認めないために
うはw 当時の人がゆってた。でてたきたよw ここで自称○○の登場ですかね? 音声変えて語ってくれるんですかねw 対抗してこっちも当時の人登場させていいっすかね?w
いきなり草生やして煽るだけの敗北宣言
パンチカード以前を知っていれば、 パンチカードの素晴らしさも知ってるだろ。 なんだろうね、この自分の知ってる世界だけで語る人。
俺百年後の未来から来たけど、 CoffeeScriptは糞ですよ。 っていう人もいるだろうな。 じゃあ糞で決定じゃないか?
プラス思考の人は、俺はみんなより優れているという。 マイナス思考の人は、みんなは俺より糞だという。
パンチカード以前からしたら、素晴らしい。だから何? その仮定は今は違うってことだろ。根本的におかしい。頭がおかしい そこまでして過去の拙さ、過ちを過大評価する意味はなんだ? 馬鹿すぎる。救いようがない
今の話をすればCoffeeScriptはクソってことだよ。
JSが糞だからCoffeeも糞という当然の帰結。どんな天才がいくら頑張ってもこの法則は変えられない
そしてC言語はクソという答えにたどり着く これがマイナス思考の発想
そして黒人奴隷や女性差別は素晴らしいという答えにたどり着く プラス思考の発想
差別してるのはクソ呼ばわりしている方じゃね?
過去の常識を素晴らしいと持ち上げてる馬鹿のことだよ それのどこがプラス思考なのか理解できないけど
誰か過去を素晴らしいと言ってる奴いるか? 過去がクソっていうやつにたいして 頭が悪いって言っているだけだろ。 ましてや現役に向かってクソとか意味不明。
糞だからなんとかしようとしてる人がいるのに、糞だと言ってはいけないとか馬鹿かよ その無批判性がどこから来るのか知りたい 勘違いしないで欲しいのは、それは間違っても「プラス思考」なんかではない
お前は何とかしようとしていない。 お前はただ文句を言っているだけ。 クソだといっていい権利を持つのは なんとかしている人だけ。
まーた「貢献してない奴は文句言うな」かよ じゃあお前も黙ってろよ。このスレに何しに来てるんだ 馬鹿を晒しに来てるのか、その目的は十分に達成できてるから帰っていいぞ
普通は糞なら何とかしようとせず関わらないだろう 糞だと言われなくなきゃさっさとお前が何とかすることだな まあJSがJSであるかぎり永遠に不可能だけど
文句言っている奴って? あぉ、糞だと文句を言ってるやつか。
言語ディスにアレルギーがある奴が、こういう議論な参加しようとする意味がわからない お花畑から出てくるなよ。現行言語へのディスのない世界とか、そもそもが噛み合わない
見ての通り、はじめから「普及したものを糞って言うな!」だけ 論点はそこじゃねーだろ。小学生以下の知能だな
CoffeeScriptの立場は、JavaScriptを 置き換えられてないことが証明してるだろ。 それなのに問題点がないと思っているのか? 言語のいいところ、悪いところを 素直に受け入れられない奴が何いってんだか。 技術者として恥ずかしいな。
言語に関する議論をしようぜ! よしじゃあお前 「JSは糞だ!」「JSは糞だ!」「JSは糞だ!」「JSは糞だ!」 これが議論か?w
置き換えられないから素晴らしい? ただの袋小路だろ、技術者が聞いて呆れる
「糞と言うな!」「糞と言うな!」「糞と言うな!」「糞と言うな!」「糞と言うな!」 これは議論じゃないね。なんでこのスレにいるのか説明しないし まあJS信者であることは火を見るより明らかだけど ディスが嫌なら来なくていいよ
「糞だと言うな。議論をしろ。」 正当な意見だと思うが?
ちょっと前からこのスレに粘着してるJS厨さあ、それは酷すぎるよ お前のカスすぎる駄々のせいでこうなってんだぞ 毎回そう。会話が成立しない。相手にした俺が馬鹿だった 貢献してなけりゃ意見できないとか言う奴は間違いなく議論をする気がない ただ荒らしたいだけ。もう死ねよ
JavaScriptはこれからも進化していくことが確定しているのに 何処の骨が作ったのかもわからんものを 使い続ける価値なんてあんのかねぇ。 まあJavaScript進化の糧になってくれればいいよ。 コンパイルしてJavaScriptを生成する技術は 将来のJavaScriptをコンパイルして、 古いブラウザで動かす技術として使われるから。
俺は多分Javascript厨だと思うんだが、なんか最近別の javascript厨がこのスレにいて議論に参加してるぞw 俺はCoffeeScript大好きだぞw javascriptには欠点も多いし、実は世間のイメージとは違い、 非常に分かりにくい言語でもある ただ、クロージャやJsonは優れていたし、プロトタイプベースは クラスベースよりも柔軟で自由度が高かった それが今のJavascriptの熱狂に繋がってるんだと思う
世間のイメージからして非常にわかりにくい言語だし 「将来のJSを今のJSにコンパイルして古いブラウザで動かす」 とか馬鹿なこと言ってるからJSは糞なんだよ 糞JSの尻拭きをいつまでたってもやらなきゃいけない だから今のJSが糞なら、将来のJSも間違いなく糞にしかならない 開発の分散と互換性地獄。これがJSが糞である所以。誰も否定できない この糞に付き合える奇特なやつは、そりゃ粘着キチガイ荒らしにもなるわ
まあ平行線だわなあ 開発の分散というのは何のことを言ってるのか分からないが 互換性はjqueryなどのライブラリの登場で だいぶ吸収してくれるようになったよな jqueryやnode、今の熱狂ぶりなど、相当優れた言語なのは明確なわけだけど そろそろ無益な議論になってきたな ただまあ、毛嫌いするより、普通に向き合った方が得なのにかわいそうに とは思う
>>242 理由書いてないぞw
多分自分で気づいてないと思うがな。
>>243 開発リソースの分散。JS派生言語を使うとJSまで面倒みなきゃいけなくなるというゴミカス言語群をなしてるわけだ
JavaScriptは標準化されてるからな。 コレが一番重要なこと。
Javaと同じこと言ってるわ それはどんなに糞言語でも嫌々でも使わなければならないというだけのことだろ まあそんな糞分野に関わらない幸せな人は絶対に使わない言語でもあるけど
>>245 それに関しては、意外とそうでもないぞ
CoffeeScriptなら、普通にCoffeescriptだけ管理していればいい
ただ、慣れるまでは生成されたソースと見比べて開発した方が
学習の点でいい
でもそれは、かえって学習コストを下げる結果になるし
両方の言語の理解が深まるし、利点だと思うけど
>>248 それはお前がショボい使い方しかしてないからだろw
って、ソースを見比べて開発だって、頭おかしいw
まあ学習に良いとか言ってるからチョチョイとしか使ってないことは分かる
>>249 確かにCoffeeScriptに関してはそうだな
Javascriptは仕事で使うけど
というか、お前は本格的にCoffeeScriptを使っていて文句を言っていたのか?
マジで?
>>250 本格的にcoffeeを使うとどうなるかなんて、お前を除いてたくさんの人がやって結論出てる
coffeeを作るモチベーションは間違いなく正当だったけど、結果的に流行るかは難しい
それはそもそものモチベーションに起因している
生成されたJSのコードを読まなければいけないなら、最初から糞JSでやったほうがマシなんじゃないかってこと
JSを仕事で使ってるなんてかわいそうだけどね
>>251 例えば、何を見て結論が出ていると思ったんだ?
確かにCoffeeScriptはまだ全然主流になれていないけど、
それを見て開発リソースの分散が問題だと結論づけてるのか?
それだと正直、ちょっと根拠が弱いなあ
自分で使ってみてそう思ったなら、理由が聞きたかったけど
まあいいや
生成されたjsのコードは、慣れれば読む必要は無くなるよ 最初のうちは読む必要がある、というか読んだ方が理解が深まって いいと思うし、かえって早い気がする
CoffeeScriptは主流になってない時点で 開発リソース分散はしていない。 ほんの少しの変わり者が使ってるだけ。 開発リソースのほとんどはJavaScriptのまま。
CoffeeScriptから生成したJavaScriptコードは長いけど、 普通にJavaScript書けばかなり短くかける。 js2coffeeでJavaScriptをCoffeeScriptに 変換すると長くなる。それと同じ事だ。
CoffeeScriptを使いたいという同期は 単に文法が気に入らないというだけだ。 効率がどうとか短くかけるとか そういうのは後付の理由でしか無い。
まあぶっちゃけ、今じゃどの言語も使いこなしたら生産性は大差ない Javaだって、8になったらラムダかクロージャみたいなものが入って だいぶマシになるようだ 開発時間の大半は調査やテスト、デバッグといった言語とは関係のない 部分だし ただ、個人的に発想が面白いし、CoffeeScriptのデモでリアルタイムに 変換されるのは遊んでて楽しいw まあ一部の変わり者なんだろうw
>>256 ちなみに、参考までに聞きたいが、JavaScriptのどのへんが気に食わない?
俺も気に食わない点はいろいろあるんだけど、君と一緒なんだろうか
>>258 JavaScriptでいいと思うよ。
別に気にくわないところはない。
あえて言えば、昔、prototype.jsもなかった頃は
ライブラリがまだまだ成熟していないと感じていた。
それは今は解決している。
それぐらいなもんだ。
後は考えれば些細な問題が思いつくかもしれない程度。
>>259 なるほど、多分javascriptを毛嫌いしてる人かと思ったが、
違う人か
聞く人を間違えたようだ
>>260 だってプログラム書いた事ないだろそいつ
具体的な事聞いたら逃げるよ
頭おかしいJS厨が二人も跋扈しててウザすぎるな それで宣伝してるつもりなのだろうか いかにゴミか、いかにキチガイかということはひしひしと伝わってくるが
coffee大嫌いのJS厨とcoffee大好きのJS厨の茶番は見ててくだらないな たとえばJSの文法は一般的に気に食わないと思われてるんだから 文法が違うだけのcoffeeを使う理由には十分だわ まだ短い方が良いとか、JSの方が短いとか馬鹿な議論をしてるが、そこが問題じゃない coffeeがJSに依存してる時点で短さはJSに依存するし どんな言語でもデバッグという作業がある以上、そして実行されるのがJSのコードである以上 JSの糞文法からは逃れられない。ただ何とかしようって人が少なからずいるのは事実 最初から読みやすさを考慮して設計されてないし、今更どうしようもないというのが終わってる 互換性を切って仕様を変えてまで読みやすくすることはできない
これからも毎日、夜通しJS厨がひたすら擁護を続けるのかと思うと気が滅入る JSは糞じゃないって。他の言語使ったことあんのかよ なんとか普及してるものは糞じゃないと言いたいんだろうけど、 その根拠がJavaにラムダがーとか今更何言ってんの?ラムダとか何十年前の機能だよ 周回遅れのくせに継ぎ接ぎだから糞文法だし。無理に評価するのやめたら? しかもそれがJavaにとっては未来の話なんだから笑える。 さらに重要視してるコードの短さではJavaほど冗長なものもない。糞は糞だろ。そこは認めろよ馬鹿 しかもコイツってJSがディスられたときのみ、糞って言うな!って現れて駄々こねてるんだよな 他の言語がディスられてるときも暴れてみろよボケ
Coffeeを使ってる人間は好き嫌いに関わらずJSをある程度知ってるだろう JavaができないからScalaというのもない。両方使えなければならない JavaとScalaを使い分けることは意味があるけど JSとCoffeeだとその旨みがない。CoffeeはJSの文法がちょっと違うだけで はっきり言ってよく似た言語でしかない。デバッグで生成されたJSのコードを読んで思うんだよ Coffeeの文法はJSのクソ文法よりはるかにマシだけど、 最初から素直にJSの糞仕様に付き合ったほうがマシだなって 2つの文法を行き来することが「勉強になる」とか言ってるのはJSが大好きだからだろうが 普通はJSなんて好きな奴いないし、不幸にもJSが好きならCoffee使わないので デファクトスタンダードの泥沼っぷりが理解できただろうか
おとなしく病院に行けw
267 :
デフォルトの名無しさん :2013/04/22(月) 13:20:18.42
CoffeeScriptは違う気がする。 JSをそのまま使うか、そうでないなら、TypeScriptみたいに出来るだけオリジナルを損ねないようにする方がいいと思う。
そのオリジナルが糞すぎるからだろ。頭悪いなコイツ ただ逃げようとしても逃げられないというだけ。どんなハッカーでさえJS地獄は避けられない それなのに普及してるから素晴らしいとか馬鹿言ってる奴がいてドン引きだわ だれも好きで使ってるわけじゃねーし、他の用途では一切使われてねーから。勘違いすんな
269 :
デフォルトの名無しさん :2013/04/22(月) 13:26:03.91
スクリプト言語をわざわざコンパイルして生成するってのも冷静に考えると凄いことだな
C#のラムダ式って冗長だよなあ つーかラムダ式である必要性がなくね? obj.All(n => n > 0) これなんて obj.All( n > 0) じゃダメなの?
>>270 仮引数になる変数名を暗黙で決めろって意味?
それとも式の最初の変数を仮引数にするのか?
ラムダ式と普通の式を完全に混同してる
引数を式に限定する場合は、あるいはそういう実装も可能だけど その引数は関数オブジェクトでしょ?どう考えても無理
引数の形で判断させれば無理ではないけど人間から見たら分かりにくくなるだけ
単純な式じゃなくてラムダ式が指定できることで 応用がいろいろ効くようになるんだよね
276 :
デフォルトの名無しさん :2013/04/22(月) 22:25:57.96
フルボッコ
jsgit ...
278 :
デフォルトの名無しさん :2013/04/22(月) 23:23:00.82
bash で優れたプログラムが書ける人はすごいと思うけれど、初心者は bash なんぞでプログラムを書くべきではないと悟った一日 よく有名なプログラマが、bash が一番!みたいなこと言うけれど それを真似してか、プロダクションコードを bash で書き始める奴がいる・・・ まじ、やめてほしいわ。手足縛られてプログラム書いているような感覚に陥る。 みんなどう思う?
バッチ処理だけ書けばいいと思う
PHP,Ruby,Python辺りのWeb周りがjsで再実装されるのは時間の問題 数年後にはecma scriptのバージョンが上がって動かなくなると予想 いや、どこかでjs処理系が仮想マシンとして言語と分離される方に賭けよう ベンチャーはともかく企業での選択肢はもとよりjavaかc#しかないだろうな 何処かしら失敗した感が拭えないmonoっていつまで粘るだろう?
281 :
デフォルトの名無しさん :2013/04/22(月) 23:29:31.86
だよね あえて声を大にして言うけど、bash という言語が劣ると言ってるのではなくて、 ほとんどのプログラマが、bash を使いこなせないってこと。
何が良いかってPOSIXで標準化されていること
バージョンが上がる毎に些細な互換性を失ってメンテ不能になるとか、考えただけでもゾッとする
284 :
デフォルトの名無しさん :2013/04/22(月) 23:41:42.55
逆に、posix モードとか理解していないと痛い目を見る
c/c++とjsで支配される世界。java/c#で支配される世界。 一般的な才能のないPGにとって快適な世界は、どちらだろう? CADやOpenOfficeクラスのアプリケーションを書くこと想定した場合でね
校舎だな
けれども、今のjsバブルが継続するとc/c++ & jsな世界はあるよね 特にgoogleやmozilla、Qt、GNUが率いるOSS周りの勢力 web browserと何かしらのデバイスを繋いだサービスを考えると、こっちの方が妥当かなと
JS厨もC/C++には敵わないことを認めて 共存路線に走ることにしたのか でもC/C++から見たらJSなんてゴミなので一緒にしないでね
イノベーションがどうとか、ベンチャーがどうとかいう才能の塊がc/c++&js 世の中の現実を知り、色々と草臥れた大人たちの溜まり場がjava/c#
標準化可能な部分をjs、カバー出来ない部分をc/c++って誰にでも予想付くだろ
まーたJS厨が法螺吹いてるのか。何がC/C++の内蔵スクリプトだよ 妄想で造語まで作って恥ずかしくないのかね
毎日JS厨が二人で工作してるからやばい
JS厨の世界にはC/C++とJSしかないらしい JSなんてブラウザでしか使われてないのに
というか2つの言語の短所を補ってて普通に考えて理想的だし
ブラウザで何でもできるのが理想だけどJSが糞すぎて 個別にインストールするアプリばかり
>>295 JSなんてアプリケーション開発ではありえないからw
C/C++を補ってるのはJava/C#だろ
JSはもともと別分野で蚊帳の外。論外
もちろん簡単なファイル処理、文字列処理などのスクリプト用途でも使われてない
今もう、一般的なユーザーが使う領域にはブラウザがあるんだよね。
それより下層なんてSDKなりapplication frameworkで実装すりゃ良いんだしさ
>>297 MySpaceはNode.jsだろ?
Node.jsのconfigureがautoconf/automake系ツールを使わずに Pythonで書かれててワロタw Node.js作ってる連中すらスクリプティングにPythonを使ってるという
むしろ、スマートフォンやマイナーOSが増える毎に、 jvmや.netの構想はメンテ不能になるんじゃないの?
> JSなんてアプリケーション開発ではありえないからw そうでもないんだよなぁ。 例えばスマホアプリ。 HTML+JavaScriptで作って iPhone、Android、他 マルチプラットフォーム対応できちゃう。 もちろんネイティブAPIも使える。
>>264 Scala、Java、C++、Scheme、Python、VB、C#といろいろ使ってきたし、
PythonやHaskellあたりもかじったりしたし、他の言語の本を読んだりもしたが、
JavaScriptは侮れない
色々と設計ミスはあるが、気をつければ大部分は回避可能
柔軟でメタな素晴らしい機能があるから、ライブラリで
カバーできる
というか、JavaScriptを批判してるのか、Javaを批判してるのかはっきりしろw
ちなみに俺はJavaは嫌いだw
>>299 そもそも、そのとき使える最善のもの使う文化だし
WindowsもJavaScriptでアプリ作れるようになってるね。
>>302 メタで何とかするとか言ってる時点でそもそもがまともな言語じゃないから
オナニーコード量産だから糞だと言われる
>>264 憂鬱なの?
なあに、君もJavaScriptをマスターしちゃえばいいのさ
そうすれば全て解決
世界的ですもんね 乗るしかない このビッグウェーブに
307 :
デフォルトの名無しさん :2013/04/23(火) 00:22:23.68
>>305 まともな言語でなくても、まともな機能を備えることが出来る
なんと素晴らしいw
309 :
デフォルトの名無しさん :2013/04/23(火) 00:24:31.06
もう JS の時代だよね。JS 古いなんて時代錯誤
JavaScriptには特徴的な点が一つあって ファイルシステムへのアクセス機能が 言語標準 もしくは準標準ライブラリに存在しないこと。 ブラウザ上で動かす必要が有るためセキュリティ上の制約で このようなことになってしまった。 それは汎用言語からすればマイナス点なのだが、 セキュリティの点からすればプラスに働いた。 だからといって、nodeなどがそうであるように ファイルシステムに全くアクセス出来ないわけじゃない。 でもこれはJavaScriptからすればオプショナルの機能。 かくして、JavaScriptは他の言語のように危険な操作を 禁止するというブラックリスト的なアプローチではなく 許可した機能が使えるというホワイトリスト的なアプローチの言語になった。 これこそ何もがネットでつながっている時代にふさわしい言語といえよう。
>>308 糞設計、糞文法、糞機能だから誰も使おうとしないんだろ
>>307 ちょっと思いつくだけでも、Chrome Packaged App、Flex、XUL、node-webkit、app.js、tidesdk
好きなの選べよ
>>310 妄想もいい加減にしろよ
データ処理がしたければ、いまどきどの言語でもweb上のデータをかき集めて解析できる
ファイル処理が下手くそなJSなんて糞の役にも立たない
JSはJSの仕事しかできないからその他のすべてのプログラマからしたらゴミでしかない
プログラミングの適応範囲はいろいろあって いろんな書籍にコードを見つけることができるだろうけどJSなんてまずないね JSだけで作られた世界でJSしか見えてない人間にはわからないだろうけど
今時のアプリでファイル処理ってあまりやらんけどな。 データベース、キーバリューストア、ネット越しにJSON通信。 単純でデータの並びでしかないファイルではなく 構造を持ったアクセスしやすい先進的なデータストアに最適化されている。
>>315 いい加減理由書けよw
だからみんなから厨房って目で見られてるんだぞ。
ブラウザアプリだけの世界の価値観なんだよなあ 平行線というか、それしか言えないならもう隔離スレ立ててやればいいと思うよ JS以外は関係ないもん
jsgitが28時間で開発資金調達する時代。
>>317 JS厨って反論できなくなったら草生やしてそれだよね。毎日それだよ
隔離スレというか、板違い。JS厨はweb制作板にいけばいいよ 他の言語のことしらないようだし、アジテーションみたいな気持ち悪いレスでスレ潰されてるの迷惑
RubyもPythonもオワコンだしね デバイスの進化について行けなかった悲しい言語
>>310 本当にブラウザで動かす言語であることによって、全てが奇跡的に良い方向に向かったよな
セキュリティがしっかりしていること、プログラミングの天才達による
最適化でとても速い言語になったこと、クロージャを備えていたため
イベントモデルと相性が抜群だったこと
DOMと組み合わせて使う言語であったこと
クロージャ、メタ、リフレクション的な機能により、高度に柔軟性を
持った言語であったこと、HTMLによって視覚的な表現を備えていたこと
つくづく奇跡の言語だと思う
プログラミングとかコンピュータ・サイエンスをやりたい人がまずJSを触ることはないだろう JSはJava以上のお仕事言語だよ 一般業務ともアカデミックとも切り離された存在
webであっても、サーバサイドは扱うデータが巨大になって 機械学習を駆使しないとデータ活用できないようになってるが そういうのってJavascript使いの世界観には存在しないんだろうな
c/c++で書けば良いじゃん。数値計算のライブラリ腐るってるだろ
これから莫大な数のjava厨が職を失うかと思うとゾクゾクするよね
気づけばJavaScriptがブラウザから 抜け出てるんだよな。 気づいていなかった? サーバーサイド、スマホアプリ、 組み込み系でもUIとしてJavaScriptが 使われている時代。
>>327 JavaScriptへの転職でみんなハッピーだな
地上の楽園へようこそ
たとえば複雑ネットワークを可視化するC/C++で書かれたigraphはRとPythonから使える PythonとC/C++の連携という話題は結構盛んで 関連キーワード検索数でもそれは明らか JSは科学者、技術者のようなプログラミングが専門でない人間には不気味すぎる
まあサーバで計算したデータを 端末に表示するだけのドカタ仕事の役割が Javascriptに与えられただけだな 良かったなドカタ仕事が手に入って
>>330 まあその辺もJavascriptがこれから続々浸食するよ
研究者はその辺柔軟だから、すぐJavascriptに乗り換えるよ
ちょっと前までPascalやLispやPrologを使ってた連中だろ?w
そういう人たちしか、python使わないけど pythonでアルゴリズム書いてた人は院を出てから無職だったよ
>>328 >>331 なんでそんな気持ち悪い文章が書けるんだ?
内容一個も理解してないだろ?Pythonの足元にも及んでないって理解してるか?理解してないだろ?
何がゾクゾクしたんだ?一個も説明できないだろ?
>>333 あのさ、そういうステレオタイプな無知を晒すのやめてくれないか?
>>334 理系院卒よりJSプログラマのほうが圧倒的に底辺だらけだろ
コンピュータサイエンスなんて言うけどさ、世の中、先見性の方が重要だよ。 大学なんてテム・レイしか居ないぞ
JavaScriptでDOOMを再現、すげーと言っていた時代は もう既に過去のものなんだな。 今は更に進んでいるのか。
>>337 けどさ、世の中ってJSプログラマよりも無職の方をバカにするだろ?
理系院卒なんて足みたいなもので、偉い人には分からないだけだよ
高卒底辺のJS厨が大学を目の敵にするのは勝手だけど よく知らないことをテキトーに吹聴するのやめてもらえませんかね
>>336 うーんと、一応理系の院は出てるんで無知になりにまあ少しは
知ってるんだけど、C++やPythonはあんまりなかったかなあ
案外MATLABやJavaが使われてたね
これがもう過去の話なのか?
まあ確かに2年近く前の話だが。
DOOM、LLVM-to-JavaScriptコンパイラ使いブラウザで動作
http://news.mynavi.jp/news/2011/06/07/035/index.html Emscriptenと呼ばれるLLVM-to-JavaScriptコンパイラを使い、
CのソースコードをJavaScriptへ変換して実現している。
特別な実装は使用されておらず、標準のWeb技術のみを組み合わせて実現したと説明がある。
EmscriptenはLLVMのバイトコードをJavaScriptへコンパイルするコンパイラ。
このため、C/C++に限らずLLVMバイトコードに変換できる言語であればどの言語でも利用できる。
Alon Zakai氏が発表したこの取り組みはネイティブアプリケーションを
Webアプリケーションに変換する手法のひとつとして興味深い。
>>342 教授が書いたウンコみたいな論文ならよく知ってるけど?
gnuplotの使い方みたいなものがCINIIに上がってたよ
>>345 過去の話
今はそのEmscriptenがさらにasm.jsとかってのと組み合わさって
さらにヤバいことになるかもしれない
ただ、それ以上にヤバいのが素のJavascript
素のJavascriptが既にCの数倍程度しか遅くないという
静的言語の域に達し始めた
普通にC++とPythonで数値計算するお仕事してるけど、 Scipyを遥かに超えるライブラリが(当然C/C++との相互運用性の高さも含めて) Javascriptに出来たら普通に乗り換えると思う だからJavascript使いには頑張ってほしい それまでPythonを使い続けてライブラリもPython向けに書くけど
>>344 MATABが使われるのが案外とかどこのFランだよ
FランではJSを使う風潮があるのか?終わってんなw
>>349 というか、web上からデータ取ってくるような研究室なら普通にPHPとかjsとか使うから
なんでアンチJSって
>>349 みたいに品がないんだろうか?
>>350 そういう研究やってるとこって大学では底辺……
>>349 ええと、まあ一応Fランではないかなあw
数オリ出身者とか、学長賞の人とか同じ研究室にいたけど
たいしたことないですよ
ぶっちゃけ、俺の学歴高いんだわー。 JS厨とは違う。すごいんだよ。
MATLAB、Rはよく見る。Pythonもたまに見る
授業でやるからCを使う学生が多いけど、JSは一度も見たことない
>>350 聞いたことないね。RやC#でそういうのやってるのは見たが
どこの研究室?
先にお前が研究所いえって 言われそうな展開だなw
>>357 今は授業でJavaも結構使われる
珍しいところではOcamlなんかも使われてた
>>351 > 技術系ではない多くの学生がITに関するニュースを正しく理解し、間違った内容であれば
> 指摘できるようになることを目指して、ITの普遍的な技術や概念を丁寧で分りやすく解説。
情弱向けの一般教養本じゃねーかw
この流れは学歴自慢で JS厨をこてんぱんにする流れだろ?
ほんと、アンチJSは 品と知性がないなw
俺は東大だ。
>>363 ああ、京大かよ
負けた
おれ某T大だわ
さすがJS厨の俺低学歴だw
>>360 > 珍しいところではOcamlなんかも使われてた
名古屋 or お茶の水?
>>368 ドンマイ。JS至上主義なのは結構だけど、かなり限定的な用途にしか使えないって気づいたほうがいいよ
JSの糞設計じゃね
>>371 別段至上主義ではないよ
ただ、JavaScriptはほとんどどんな用途にでも使える汎用言語になったと思ってはいるけどw
>>371 品と知性が感じられない。
具体的な内容がなくて、単にクソとしか言ってないからだろうか?
まともな学歴の人はこんなとこにいないだろう(直球)
限定的な用途にしか使えないという
>>371 汎用言語になったという
>>372 さあ戦ってもらいましょう。
>>371 はJavaScriptでできないことをあげる。
>>372 はJavaScriptでできることをあげる。
さあどちらが多いか?
私も少し参加しましょう。
JavaScriptでMySQL、PostgreSQLへ
直接接続できる。
地方のE欄でもHHK LiteのUS配列が用意されたけど、大学出た後でLinuxの使用を廃止したって聞いたな。 これが改悪なのか改善なのか今ひとつ分からないけど 頑張ってgtkとかqtとか覚えるぐらいならjs覚えた方が遥かにマシだよ scipy使うぐらいなら普通にR,octaveでデータ処理した後でnode.jsで加工する方が潰し効くだろうしね
JavaScriptはOSのカーネルには向かないとは思う ただ、数値計算には十分使えるようになってきたね pythonも手軽に使えていいけど
>>376 JSが汎用言語とか言ってるの頭おかしいやつだけだろ
>>376 スマン
俺372なんだが、378でJavascriptが出来ないことを挙げてしまったわw
jslinuxってあるけど、数値計算は勧めない 型が分り辛いし、cで書いた方がマシ
>>377 pythonにはpandasやpython-controlがあるから
データ処理の後の加工もすべてPythonでできる
>>381 あるにはあるけど、向いてはいないね
CやC++のようなもうちょっと低級言語の方がやっぱり良いだろう
>>382 大学出た後で使わないしドキュメント読むだけ時間の無駄。
使いたいならR&Dみたいな職を獲てからにしないさい
> JavaScriptはOSのカーネルには向かないとは思う それ動的言語全部当てはまると思うけどw
OpenMPIやMVAPICH2がJavascriptで使えると良いな CudaやOpenCLが使えると尚良い
正直、pythonもC++も使えるから、その時になったらその時で必要そうなライブラリと言語使うだけだわ JS厨の俺
>>386 そういうのググってからレスした方が良いよ
>>377 > scipy使うぐらいなら普通にR,octaveでデータ処理した後でnode.jsで加工する方が潰し効くだろうしね
クライアントとサーバで同じ言語が使えるのが便利ってのが
JS厨の常套句なのに、そこは別の言語を使うんだww
Pythonがスクリプトとして使われてるアプリは現にあるわけで libreofficeやblenderとかなんとかってエディタのマクロを書けたりする 汎用性という意味ではOSSコミュニティにおける土壌が違いすぎる
JSを無理やり別の用途で使うことにどんなメリットがあるのか理解できない
OOoはrhino装備してるだろ そもそもOSSコミュニティがjsに傾いている
>>392 バッチファイルに埋め込む言語としてはお世話になってます。
そうか。libreofficeやblenderも JavaScriptに対応していた。
>>392 JavaScriptはだれでも使える言語だからね。
誰もが実行環境持ってる言語って
そうないでしょ?
>>390 jsはグルーとして最良で、わざわざライブラリ書いたり、数値計算したりは
ストラディバリウスのヴァイオリンで釘を打つようなものっだってオジイチャンが言ってた
まあ、Pythonは良く出来た素晴らしい言語ではあると思う ただ、いかんせんブラウザで動かない
>>396 それはよく言われるが、一番馬鹿な理屈だと思う
まず環境を準備できないような一般人に実行環境を与えたとして誰が使うんだ?
現にJSを使ってる人間なんてブラウザ持ってる人間の1%もないだろ
>>388 ごめん。GPGPUで数値計算するわーとか言って
おもむろにブラウザ立ち上げる姿を想像したら笑ってしまった
それを言ったら、みんなPCとネットがあるんだから どの言語の実行環境も持っていることになる だからなんだと言うんだ。ほとんどの人間は実行しないだろ
>>399 google社員だって地球上には1%も以内だろ
>>399 誰でも最初は環境を準備できないよ。
だれでもそんな状態から使いはじめるんだ。
>>403 その気持ち悪すぎる言い回しやめてくれないか
ブラウザは実行環境ではあっても開発環境ではない ブラウザ+エディタで開発するのはめんどいよ という理由であんまり JavaScript 触ってこなかったけど V8 + Node.js 触りはじめたらそうも言ってられなくなってきた こんなに入りやすい環境だとは思ってなかったわ
>>401 例えばアプリを作る。
そのアプリを実行する。
さっとできるのがJavaScriptじゃん。
> ブラウザは実行環境ではあっても開発環境ではない > ブラウザ+エディタで開発するのはめんどいよ じゃあ君は何で開発してるの? ブラウザ+エディタから さらにブラウザをとった エディタで開発しているよ。
俺にとってブラウザは実行環境+デバッガという位置づけです。
ブラウザって、SmalltalkやEmacsの環境に近いんだよね dinabookの構想が現実になったような具合
>>404 だからさ、いくらみんながブラウザを持ってたって
JSからプログラミングをはじめる人間なんて明らかに少数派だろ
そこは認めろよ。なんかJSの過大評価が異常すぎるわ
全く関係ないのないファクターを持ってきてJSがすごいとか言い出してドン引き
動的言語、つまりこのスレのスレタイの言語での開発って、みんなIDE使ってるの? エディタで開発するのはめんどいって言われたら どうしようもないんだがw
その昔、電源を付けるとすぐにBasicが動いたわけで、 今のVSやEclipseをインストールしないとダメな方が不自然
>>407 いや、まだその域には達してない
インストールして、ボタンちょこちょこ押して、はい雛形実行みたいな
VSみたいな環境
なんだかんだで、コマンドラインいくつか叩いてエディタを使って
ソース貼付けてみたいな、初心者を逸脱した操作が要求される
環境ばっか
まあ、そろそろ出てくるだろうけど
しかしVSはかなりよくできた環境だわ とにかく楽に何かを作りたい初心者に勧めるならVSになってしまうと思う
>>411 最近は多いらしいよ。JSというか
HTMLから入るらしい。
>>416 それって、どこの畑で育ったかの問題で、
一世代前のPGにはIDEから入ったとかいうと馬鹿にされるよ
HTML+JavaScriptはすごくて これでクライアントアプリを作るだろ? そうすれば一部を手直しするだけで ウェブアプリにできてしまう。
「多いらしい」なんじゃそりゃ
>>421 へえ、おれはJS使いじゃないからウェブアプリなんて作れないわ
お前の一番力作のウェブアプリ見せてよ
>>417 たとえばどういうライブラリなりフレームワークなりを使うの?
俺は初心者に勧めるならSmall BasicとかProcessingとかになっちゃうんだが
>>423 先にお前の一番の力作のウェブじゃないアプリを見せてよ。
反JS厨の自作自演が始まりました
初心者なんてSICPでも解いてりゃ良いだろ
429 :
デフォルトの名無しさん :2013/04/23(火) 01:48:07.14
コンピュータサイエンス専攻でも JS できるやつはおるよ。 ちょっとしたアプリケーション(プロトタイプ)作って、動かしてみて、理論を形にする、なんてことはやってるやつはやってるよ。 最近は JS も優れたライブラリがかなり豊富になってきて、 簡単なデモを作るにはもってこいの言語だよね。
JavaScriptでデスクトップアプリを作る方法は
>>312 に書いてあるとおり。
> ちょっと思いつくだけでも、Chrome Packaged App、Flex、XUL、node-webkit、app.js、tidesdk
> 好きなの選べよ
あとはデータ保存などを抽象化しておけば
その部分をサーバーから読み書きすれば
デスクトップアプリのウェブアプリ化が完了。
さらにスマホにも対応できてしまう。
>>427 自分が挙げられないものを他人に要求する。
その人の人格を疑うよねw
>>429 その嘘っぱち妄想を並べたいかにも印象操作みたいな宣伝文句やめてくれないか
>>429 コンピュータサイエンス専攻なんていうけれど、
そもそも教授たちの頭の中が自分らが過ごした青春時代で時が止まっててスゴく迷惑
>>431 ここで毎日粘着してるJS厨がどういうものを作ってるのかかなり気になったもので
何も作ってないんだろうけど
>>435 だからぁ。同じように粘着しているお前が
何を作るのか気になるんだよ。
何も作ってないんだろうけど。
え?俺は毎日来て粘着JS厨にレスしてるだけで 俺自身は粘着してないよ。 みたいなこと言ってほしいなw
>>432 何を嘘だと思ったのか気になるけど、
gtkだとかqtを自前で用意するより遥かに労力がイラナイし仕事もあるから
awt/swingみたいな無名クラス書くとかやってられん
>>436 現実ネットワークを複雑ネットワークとしてモデル化して解析したり
マルチエージェントシミュレーションしたりするプログラム
プログラマならLinux使えよ。 Linuxならいろんな言語を簡単に使えるんだぜ。 インストールが簡単。 って言ってる人に限って JavaScrptならLinuxじゃなくても簡単に使えますよ 実行環境誰でも持っていますから。 というとムキになって反論するだよな。
443 :
デフォルトの名無しさん :2013/04/23(火) 01:57:22.94
JSの使えるIDEと言えば?
>>440 あ、その程度の紹介でいいんだ?
ならお金を稼ぐことができるウェブサービスを作る仕事。
>>443 Eclipse
NetBeans
Visual Studio
>>433 カーニハン先生の新刊には十数ページほどのプログラミング入門があるけど
JavaScript で Hello World, 制御構文ときて最後に Google Maps の API を
叩くところまでやってた
これを日本人の同年代の学者さんがやると使用言語が Pascal や Lisp になって
階乗とハノイの塔を解くんだろうなと思うと絶望した
まずはコンパイラを作れ C/C++の最大の特徴は、コンパイラが自分自身のソースをコンパイルすること それができない限り、言語が一つになる時代は来ないから
>>441 何を馬鹿なこと言ってるのか不思議だけど、そもそもgithubの連中がjsを使い出したわけで、
プロトタイプ作るにも一番に楽な言語なわけ
debianよりubuntuが流行る理由を考えろよ
誰も依存関係の解消に時間なんて割きたくないんだよ
JavaScriptのライブラリの依存関係を解決する仕組みは 素晴らしいね。
cよりマシ
>>440 誰でもあんた個人が特定できるぐらいの
具体的な製品名やプロジェクト名言ってよ。
>>441 なにかlinuxユーザーにトラウマを植え付けられたのか知らんが
何をどう結び付けてるのか理解できない
>>456 そりゃ、他人にそれを要求する奴には
同じようにそれを要求するさ。
速くお前個人を特定できる情報をよこせ。
JSに底辺の仕事があるのは理解できたけど お前に仕事を与えてる上の上の人間は別にJSなんて一切知らなくていいわけだ そういうものに私はなりたい
>>456 やっぱり品と知性がないなw
なーに、そういう結果にしたいんですだよ。
>>457 いや、たぶんお前がどんなサービス(の一部の一部)を作ってると言ったところで
個人は特定できんよ。JSの仕事がショボいってことはわかるだろうが
仕事なんて往々にしてそういうものだ
自分で仕事とってくる世界の方がマシ
>>460 個人が特定されることは、俺自身がわかってる。
だからお前に俺がされたのと
同等の質問をしている。
何か問題でも?
>>462 ならいいです。こんだけ危険人物だとみなされてるJS厨の個人が特定されたら大変だろうから
たんなる研究分野という大きな括りの情報も明かせないなんて解せないけど
特定された日には松江とアムステルダム(適当)から箱詰めチンパンジーが送られてきます
>>460 googleでajaxアプリ書いてもショボいって言うんだろうな
JS厨の仕事がコーダーならいいんだけど 少しでも商品について文章を書いてるとしたら 臭すぎるからちょっと注意したほうがいいと思う
>>466 むしろgoogleって時点ですごいと感じてしまう
彼はgoogleなのかな
商品について文章を書くってエンジニアの仕事なんだっけ?
なんかこの板もそろそろID制にしてほしい 昨日からJSについて100レスぐらいしている基地外が2匹ぐらいいるだろ
特にJavaScriptのことをJSって言ってるやつな
え?もともと俺しか居ないけど?
JSって表記してる奴はレスからして専門学校生とか高卒でしょ
「JSは奇跡の言語」とか言ってるキチガイはネタだとしてもさすがにやばいと思う
node.jsがどうこう騒がれてるけど、reactだのcocoonだの似たようなものなら何処にでもあれば、 c#に至ってはライブラリ実装するまでもないなんて言われてるわけだけど、 世の中は標準化とトレンドに逆らっても何のメリットもないよ ところで、node.jsが普及して困るのって誰だろう?大手SIer?
関係のない分野に逆張りしてるのはJSだけどな。流行らないけど
流行る流行らない以前に、企業やベンチャーが標準化したがってる。 c/c++&jsとjava&jsは確定された未来で、LLにとってのディストピア。 皆、perlの二の舞にならないように気を付けてね
はいまた出た。「確定された未来」だって。なんでそんな煽動的な言葉を使うんだろう さきのことなんて誰もわからない。そんなことがわかれば誰も苦労しない JS厨が徹底して詐欺師スタイルなのはなぜだ?それも分からない
言葉選びのセンスが詐欺師なのは素なのか?
「確定された未来」とは暗に「今はそうではない」という事実を物語っているだけだろうに
同じ処理をやらせたら PHP Python Ruby Perl どれが一番処理早い?
どの言語が〜とか言われても、 左にあったものが右に来るだけで、本質的には何も変わらない気がする。
大量のデータを処理したいので処理速度が一番速いのを希望
それならCでしょ。
>>452 >JavaScriptのライブラリの依存関係を解決する仕組みは
>素晴らしいね。
jQueryのnoConflictとかな
あれ考えて見たら地味に凄いよな
余計な構文を付加しないでただ普通の言語の基本機能使ってるだけだもん
パッケージやモジュールが一つの変数に値として入ってるという感覚
なかなか他の言語ではこういうのないよね
> なかなか他の言語ではこういうのないよね ほんと他の言語を知ろうともしない上に 気持ち悪さだけは一流だな
>>486 お前が次々具体的な言語を挙げて反論すればいいだけやん
>>485 > パッケージやモジュールが一つの変数に値として入ってるという感覚
> なかなか他の言語ではこういうのないよね
Python なんかもそういう感覚だよ
>>488 よく見てなかったけど変なの一杯あるな
一通りメジャーな言語からJavascriptに変換できるようだし、
JS嫌いのやつ良かったじゃんw
モジュールはシングルトンとして振る舞うほうが直感的だし、 別にdir辺りでモジュール情報読み込んで シングルトンじゃないように振る舞うデコレータを書くのも簡単だけどね
まあ確かにdirみたいなリフレクション的な機能は優れてるね pythonも希有な言語だと思う
>>488 Moescript - Indent-based language
LispyScript - A JavaScript with Lispy syntax and Macros.
RedScript - Ruby flavored JavaScript.
この辺面白そうだな
萌えスクリプトw
モジュールが変数に入った値のように扱える言語って pythonとかlisp系くらいかね あとは知らないけどrubyあたりもそうかも
そのへんは Ruby も Module クラスがあるぐらいでファーストクラス
誰かが言ってたけど、新しいJavascriptを古いJavascriptにコンパイルして古いバージョンのブラウザで動かすことも 夢じゃないな しかも、簡単な記述で自動的に出来そう 古いバージョンと新しいバージョンを宣言一つで自由自在に切り替えたり、 古いバージョンから新しいバージョンへの逆方向も簡単に出来そうだし そうなると、古いバージョンにしか対応していないライブラリの利用も簡単に出来る 仕組みが出来上がるかも 長年プログラマを悩ませてきた言語の後方互換性の問題をJavascriptが解決しちゃうかもな
>>477 一時期のPerlは酷い時代だったねぇ
専門分野でもないのにCGIの話ばかりで
perlがCGIという言語の処理系だと思ってる輩とか
.cgi=Perlソースの拡張子と思ってる輩とかが跋扈してた
やっと元のPerlに戻りつつあって良いと思うよ
二の舞で言えばRuby辺りは既に二の舞を踏んだとこだと思うな
何かRubyと言えばRails前提みたいなのが増えちゃってキモイことになった
js使えない化石がいると聞いて
>>488 JSへコンパイルする言語が乱立しているとは聞いていたが、
まさかこれほどとは・・・
JSの世界で、一体何が起こっているんだ・・・
>>500 JSの世界には何も起きてないよ?
お前は、機械語に変換する言語が増えたら
機械語の世界で何が起きてるんだっていうか?
いや起きてるだろ。 だれもJSなんか書きたくないからこうなった、まさにカオス。
>Schemeの仕様書はR5RSだと50ページにも満たないため、かなりの数の実装が存在する。 仕様が小さいので(あんま細かいこと要求されない) 処理系が書きやすいんだろうな なんかあったらJSが悪いで押し通せるというかその辺Schemeと似てるなw
>>502 JS使ってる人が大半なのに何で誰も書きたくないっておもった?
>>504 JS使ってる人が大半だって何でおもった?
C (書きたい) C++ (書きたくない) AWK (書きたい) Perl (書きたくない) HTML (書きたい) Ajax (書きたくない) これがセカンドシステム症候群だ
>>503 信者の言い分もLisperそっくりだからな
>>484 CのCGIは設置できないってことなので
PHP Perl Python Rubyの中で処理速度が一番高速なのを知りたいです
やりたいのは2MBくらいの圧縮されたファイル(zip/gzip)から数MBのテキストファイル(UTF-8)を取り出し解析してデータを抽出しデータベース(mysql)に登録するという感じです
>>505 >JS使ってる人が大半だって何でおもった?
客観的なデータからだよ
君のほうの根拠は?
JS使いたくない人の大半はJS派生言語も使いたくないと思ってるよ 結局いつも使っている言語を使いたいだけ
>>508 その程度なら差はほとんど出ない
設置しやすさとかメンテ要員とか開発者の好みとか他の要素で決めればいい
JS厨なのにJSの限定的な用途を一切把握してないというのがすごいな
>511 d 差が無いのか・・・それは残念です
JSが機械語のポジションとして機能することが当たり前になるなら 静的型付けで書きたいから どれかまともな静的型付け言語がJS上でデファクトの地位を確立しないものか
機械語というか中間言語 googleが業界最速のデファクト処理系を作った時点でポイされるのがjs
>>483 RDBがボトルネックになるよというのが昔からある決まり文句
>>488 のbrython使ったら、ブラウザでまんまPython動かせるじゃん
もうPythonでよくね?
ぼくはhaXe使うよ!
JSに変換するタイプの言語はCoffeeScriptとかTypeScript程度ならいいけど、 あまりに元ソースとかけ離れちゃうとブラウザのデバッガが使いずらい。 ソースの行番号程度ならソースマップで同期させられるけど、 オブジェクトのインスペクタがダメ。
>>520 普及すれば言語専用のデバッグツールも充実してくるかも
Kotlin、Ceylon、Xtend、Vala ここらへんはJavaやGNOMEにこだわってないでJS上にも実装しちゃえよ 普及に弾みが付くかもしれんぞ
>>522 使いづらいから普及しなくて
普及しないから使いづらいままのループ
>>524 重要で面白いことは全部サーバ側で計算して
ブラウザ側はviewだけ担当すればいいんだから
JS厨みたいな低能じゃなかったらデバッガなんていらんだろ
>>526 サーバ側で動くようなコードはかなり複雑でもデバッガに頼る必要ってあまり感じないけどね
直線的に動き切るような感じのコードにすることが多いし
ビューのコードは単純でも状態を遷移させながら永続的に動き続けるような感じになるんで、
リアルタイムでデバッガの支援を受けながらデバッグしたいことが多い
いやんキモい
デバッガを作るよりクロスコンパイラを作りたい
>>521 他のJS厨のレスを見てもわかる通りすべて妄想だよ
質問です。 JavascriptでのHTTPリクエストは基本的に鯖が対応してないと クロスドメイン制約に引っかかってできないのでしょうか?
>>531 基本的にはね
JSONPもCORSも鯖対応が必要
ただ、別にブラウザ上の組み込み言語じゃなければそんな制限はないので
node.jsとかは普通にできるし、Flashはポリシーファイルを使うみたいだね
>>532 ありがとうございます。
ちょっとandroidで処理を全部htmlで書く場合どうすればいいかと思いまして、
クライアント側のhtmlではそういう通信は諦めたほうが良さそうですね。
おとなしくネイティブでやろうと思います。
んー、うろ覚えだけど、Androidの場合はJavascript側にネイティブ処理を一応 追加出来たはず ただ、この場合も全部HTMLってわけではないけど
HTMLを使うならPhoneGapとかいいんじゃない? ネイティブ命令へもアクセスできるし。 HTMLを使わないならTitaniumが有名だね。 こちらもJavaScriptでネイティブ命令を使える。
>>535 お前が初心者だということが良く分かった
間違ったことは言ってないと思うが? またいつもの、悔しいからとりあえずなんか言っとけ ってやつか? たいてい捨て台詞はいて去っていくんだよなw
ネイティブ命令w
539 :
デフォルトの名無しさん :2013/04/24(水) 03:21:48.88
ナイーブ命令><
女性のデリケートゾーン
他言語からJSに変換するノウハウもどんどん溜まってきて ブラウザで動く唯一の言語というJSのメリットがどんどん無くなってきた
そしてふと気づくんだよ Javascriptが言語として優れていることに
実際使ってみると気がつくんだよな
>>520 みたいな問題がわりと致命的だと
asm.js使わないとダメな案件でたらどうする?
その質問に意味はあるのか?
あれを使えと言われたら、asm.jsのコードは最小限にして、他の環境でデバッグしてから、 ブラウザ上ではそのコードをブラックボックスとして扱うようにするな
php 案件のが圧倒的に多いし そりゃ富士山噴火したらどうすんの?並に起こる確率低いがな
ちなみに今の世代が生きてるうちに富士山が噴火する可能性はかなり高いけどなw
いつ?
これなんだよな。JS厨が徹頭徹尾デタラメを並べて擁護してるのがだんだんネガキャンに見えてきた
理解できてない奴がいるようだがasm.jsとPHPは競合するような技術じゃない
はっきり言って、普通にDBサーバと連携したようなWebサイトだったらPHPで十分じゃないんの? なんでわざわざ実績のない「こ難しい」もの使うの?
現状維持で十分と思えば実績を肯定できるが 欲を出すとネガティブになる
asm.jsの話になんでphpが出てくるんだよ 用途も目的も全く違うじゃないかw
>>552 君が難しいと思っていることはどうでもいい。
DBサーバーと連携したようなウェブサイトというが
今のほとんどのウェブサイトはDBサーバーと連携してるので
ほぼ全てのサイトに当てはまる。
PHPがクライアントサイドで動くのならいいが、
PHPはサーバーサイド用なので
クライアントサイドの言語がどうしても一つは必要になる。
以上二つの理由からほぼすべてのサイトでクライアントサイドの言語が必要になる。
HTMLは文書のためのマークアップ言語なので、一部の数少ないフォームを除いて
ユーザーインターフェースを備えていない。HTMLのフォームは機能が貧弱で
例えば日付入力すら使いづらい。(HTML5で一部のブラウザでは少しましになったが)
閲覧するだけのウェブサイトならばHTML+CSSだけでも何とかなるが
使うことが出来るウェブアプリにはJavaScript(または同等の言語)が必要となる。
asm.jsはJavaScriptのサブセットの言語。
asm.js言語で書かれたソースコードは、JavaScript言語として実行できる。
サンプルコード無いのかと思ってちょっと見つけた。
http://hagino3000.blogspot.jp/2013/04/asmjs.html function create_my_asm_module(stdlib, foreign, heap) {
"use asm";
}
こう書くと、対応しているブラウザではasm.js言語と解釈されるらしい。"use strict"みたいやな。
function calc_tax_included_price(price, tax_rate) {
price = price|0; // priceはint
tax_rate = +tax_rate; // tax_rateはdouble
//略
}
これが型宣言の方法らしいw
int priceみたいな書き方はJavaScriptとの互換性がなくなるから、
まあ使えないわな。でもやっぱりキモいw
"int"; price; とか/* int */ price; みたいな
方法じゃダメだったんかいな?
>>557 理由書かないとお前のほうが馬鹿に見えるぞ。
>>555 stackoverflowのAPIを使うクライアントを作れというお題があったよな
あれはPHPでもできるんじゃないか
>>559 あ、クライアントというのはウェブアプリのクライアント、
ブラウザで動かすって意味ね。
PHPでデスクトップアプリ作るとか
CLIアプリでクライアントの役目をすることは出来るけど
そういう意味じゃない。
あっ! hcapp.rakusaba.jp
asm.jsはマジで素晴らしいよ。 素のJSより速いだけじゃなく、emscriptenみたいなクロスコンパイラが使えるというのが良い。 LLVM用のフロントエンドがある言語(C/C++含む)と、それらの言語で書かれた処理系がある言語(Perl,Python,Ruby,PHP)は ブラウザで動くようになる。 ウンコなJSを人間が読み書きする必要は無くなり、生産性の高い言語で開発することが出来る。 クロスコンパイラなので、ゴミのようなブラウザのデバッガを使う必要も無い。
素のJSより早いといってもFirefox限定 LLVMとかのクロスコンパイラで生成するのが前提で、 生のasm.jsでコーディングするのはあまり考慮されていない ブラウザのAPIにアクセスするようなコードは当然ながらブラウザ上でしか動作しないので、 asm.jsに変換されたわけのわからないコードとにらめっこしながら ブラウザ上でデバッグすることになる
クロスコンパイラを作る手間に比べたら、 開発環境でブラウザAPIをエミュレートする層を用意するくらい簡単。 わざわざブラウザ上でデバッグするわけねーだろ。 やっぱJS厨はアホだなw
クロスコンパイラとして機能するLLVMのフロントエンドを作るのはそれほど難しくないよ 個人でなんとかなるようなレベル それに比べたら、ビューのデバッグができるようなブラウザAPIの エミュレーション環境を作るのは非常に手間がかかる 実用的に使えるものはほとんど存在しない
全然大変じゃなさそうだけど、そもそも不要でしょ だってemscriptenでデバッガも移植できるんだから 好きなだけブレークポイント貼るなりステップ実行なりすれば良い
例えばC言語用の単純なデバッガをemscriptenでasm.jsに変換できたとして、 それでasm.jsのコードをデバッグなんて出来ないぞ デバッガの仕組みを根本的に理解できて無いだろ
スクリプト言語のデバッガは動くよ それに、そもそもアプリはブラウザ固有のAPIなんて直接叩かなくなるよ Qt等のクロスプラットフォームGUIフレームワークが抽象化して ネイティブアプリとWebアプリが同じコードで動くようになる で、基本はネイティブクライアントとして開発するけど、 インストールしたく無い人は少し遅いけどブラウザでも動きますよ、って世界になる
そういう時代がくるといいね まあ俺は普通にjsでもいいからどうでもいいけどw
ブラウザ内で手間がかかるならブラウザ外に逃げる、ってグローバル化の人が言ってた
スクリプト言語のコードをasm.jsに変換するんじゃなくて、 C言語で書かれたインタプリタ自体をasm.jに変換して、 スクリプト言語のコードをそのままブラウザで動かすってことかね まず、インタプリタがOSのAPIにアクセスしまくりなんで、 それをブラウザで動くように変換するのはかなり手間がかかるな さらに、スクリプト言語のコードからブラウザのDOMとかにアクセスする手段は 新たに用意する必要があるので、これにも激しく手間がかかる こんなの誰が作るんだよ
ネイティブアプリをストアで販売して、 ブラウザで動くバージョンはタダで使える 開発者側は一つのコードベースで良い 悪くないな ブラウザ由来の機能制限も、これならメリットにすらなりそう
ブラウザのHTML+DOMをクロスプラットフォームのGUIフレームワークで抽象化ってのが難しいな まあCanvasに描画とかになるんだろうが激しく重そう 逆にネィティブアプリも表示にDOM+HTMLを使うようになるって方が現実味がある
WebGLだよアホか
WebGLに固定しちまったらさすがに普及はしないだろな
576 :
デフォルトの名無しさん :2013/04/25(木) 10:19:27.65
asmjsって、ブラウザのJSエンジンが対応しないなら意味ないというか、わけわからないコードが紛れ込む事になって可読性が多いに低下する。 WebGLも使い道ほとんどないだろう。 高度な3Dグラフィックのゲーム作るのにわざわざブラウザをプラットホームにする理由ない。 ネイティブアプリで作る方が遥かに簡単で高速なんだから。
asm.jsな これは中間言語みたいなもんで可読性とか考えるようなものじゃない
578 :
デフォルトの名無しさん :2013/04/25(木) 11:22:19.83
Firefoxしかないモジラと違って、MicrosoftやAppleやGoogleはネイティブアプリのプラットホームを持ってる。 インターネットの標準にノイズを入れる事を彼らが支持するはずかない。 ECMAもasmjsにはマジおこ。
COMETってHTTPリクエストを繋ぎっぱなしにするってあるけど これはサーバープログラムの設定でできるの? apacheとかでやる場合どうするんですか?keep aliveとか関係してますか? 教えてください
とりあえず勢いソートして人が多そうなところに質問する馬鹿
>>574-576 WebGLはそもそも、対Flashのためにあるんじゃないの?
そんなに速度がシビアな分野には使われねんじゃねーかと思う
>>581 別に何も困らんけどね
バッドノウハウがいらなくなって、javascriptが速くなって
結構なことじゃんw
Javascript最強すぎるなw asm.jsにWebGL パフォーマンスまでもが強みになってきた 死角なさすぎて笑が止まらんw
>>581 > JS厨が後生大事に溜め込んだバッドノウハウが
> 陳腐化してゴミになることを除けば、誰も損をしない
あれ? 普通はバッドノウハウは
早く不要になってほしいと思ってるはずだけど?
JS厨を含めて、誰も損しないじゃんか。
asm.jsって可読性変わってないと思うけど? 可読性に関することって int型とdouble型の指定の 2つだけでしょ? あとは標準のJavaScriptそのまんま。
先輩方ご助言をお願いします! 今以下の様なスクリプト書いています。これらをJSON形式にて出力したいのですが、 どうにもやり方が分らず苦戦してます。そもそもこれだと無理なのかすら判断が出来ず、 お知恵を貸して下さい! book.items.each do | item| res1 = item.get('ItemAttributes/Title') res2 = item.get('DetailPageURL') res3 = item.get('MediumImage/URL') js = { "title" => res1, "url" => res2, "img" => res3} ans = JSON.pretty_generate(js) puts ans 出力結果(カンマが入らないのと [ ] が付与されない) { "title": "name", "url": "address", "img": "path.jpg" } { "title": "name", "url": "address", "img": "path.jpg" }
Perlだったらわかってた
そんなことはどうでもいいから JSの話に戻ろうぜ。
590 :
587 :2013/04/26(金) 01:03:02.11
度々すいません。実現したいのは以下の様な形です。
[
{
"title": "name",
"url": "address",
"img": "path.jpg"
},
{
"title": "name",
"url": "address",
"img": "path.jpg"
}
]
>>588 Rubyですいません。。。
>>589 下らない質問ですいません。。
>>590 なんでRubyスレがあるのにここで質問するの?
592 :
587 :2013/04/26(金) 01:20:06.80
>>591 ぁっあ!!!すいませんでした、全然違うところに書き込んでいるの気がつきませんでしたOrz…
移動します。ありがとうございます。
我が覇気に恐れをなして逃げたか
>>585 JS自体のコーディング需要が無くなるという意味で
バッドノウハウが不要になるんだけどね
JSは中間言語としてのみ生き残る
PHPが無くならないのと同じ理由で、JSを駆逐するのは無理だろうな
>>583 >>584 JS厨の書く普通のJSコードは全く速くならんがな
GCすら無いasm.js用コードを手書きしたいというなら止めんが
お前らが女子小学生好きなのは分かった
>>596 正直そのレベルならどの言語で書こうとasm.js用なのを
意識する必要があるんじゃね?
仮にそれが無いとすれば、普通のjavascriptやよく似たtypescriptあたりを
自動変換する技術も現れるだろう
とりあえず現実的なasm.jsの使い方は、JSから呼び出すサブルーチンを Cで書いてasm.jsに変換したものに置き換えるあたりだろう
asm.jsでネイティブの50%程度の速度が得られるっていうのは Cとかの静的言語のコードをasm.jsのコードへ変換した場合なんだよね 動的言語のコードを変換してもそれほど速くはならんし、 インタプリタ自体をasm.jsで変換してその上でスクリプトを動かしたりしたらスッゲー遅いよw
CとJavascriptを愛する俺の時代が来るのか
それじゃ石器時代に逆戻りじゃないですか。やだー
>>595 > GCすら無いasm.js用コードを手書きしたいというなら止めんが
asm.jsはJavaScriptとして実行可能って言ってるだろうがw
>>603 たぶんなんか勘違いしてる
"use asm";を付けたコードは、Javascriptとしてもasm.jsとしても実行できるコードになってる必要がある
>>604 asm.jsはjsのサブセットだからasm.jsが動くならjaも必ず動く
jaじゃなくjsね
>>605 その逆はダメだってことね。だからまずはGCを止めるasm.jsの環境で動くコードである必要がある。
そのコードがJSの環境でも一応動くってだけ。
サブセットは簡単だけど⊆と⊇を間違える事故が必ず起きるよね
>>600 Cで書かれたプログラムが50%程度の速度で動くなら、
Cで処理系が書かれたスクリプト言語も50%程度の速度で動くのでは?
>>609 スクリプト言語はインタプリタがネイティブで動いてる状態でも
ブラウザで動くJSと比べてかなり遅いからね
ゲームならともかく、普通のGUIアプリなんて ウィジェットが速い言語で書かれてたら 他の部分は何で書いても速度差なんて体感できんけどね 特にウェブアプリはネットワークがボトルネックの上に計算はサーバでやるし まあ、速度が欲しけりゃC/C++で書いてFFIで呼べば良いよ
Javascriptは型付けが弱くてウザいわ 暗黙の型変換が邪魔すぎる 文字列と数を足せたり、加算するだけで整数が実数になったり馬鹿かと で、こう書くと型付けの弱さと動的型付けの 区別が付かないアホが湧くんだよなぁ
>>612 型付けの弱さに、暗黙の型変換がどう関係するの?
暗黙の型変換なんて演算子オーバーロードみたいなものとしか
思ってないんだが?
加算するだけで整数が実数になるのか? マジで? 2+1が3と比較したら等しくなかったりするんか クソすぎるじゃん
>>614 クソ言う前に自分で調べるかレスを待てよ。
クソ言ったお前がバカに見られるぞw
それで型付けの弱さと暗黙の型変換の関係は?
型付けが弱かったら、絶対に暗黙の型変換が行われると
思ってるのかな?
いや、javascriptに整数という概念がなくても、人間にはあるだろ 人間にとっての整数が、加算で整数でなくなったりしたら困る
整数型は桁があふれると非常に困るんじゃないかね 実数型なら誤差かもしれない
Javascriptに整数型はあるぞ bit演算なんかの特定の演算の結果は整数になる
620 :
デフォルトの名無しさん :2013/04/27(土) 03:56:02.48
javascriptは\dでマッチさせてもparseIntが必要なのがダルいよな
数と文字列とリストとハッシュとクロージャ どれを相互に足しても実行時エラーにならないとかJS糞すぎる
>>618 スクリプト言語なのに整数の桁あふれを
意識する必要がある時点でダセェ
JSは整数の加算や乗算で桁あふれしないけどねw
>>622 これって、スクリプト言語とは違うジャンルが出てくる前兆だよな
スクリプト言語でもでっかい整数を扱いたいとき普通はGNU Multi-Precision Library(GMP)が使えるからね PHPでも爆速よ
>>623 JSは桁あふれっつーか、こっそり精度が落ちる
1000000013 * 1000000013 => 1000000026000000100
JSで言うGMPはゲームエンジンだから笑える
JS GMPでググると1番上はゲームエンジンだけど 2番目はGNU Multi-Precision Libraryを使うためのgmp.jsってライブラリだな
gmp.jsってemscriptenを使ってCをJSに変換してるんだよな やっぱasm.jsが待ち遠しいな JSは中間言語になっちゃうけど
gmpを明示的に使うの? 何それスクリプト言語ってよりCに近いじゃん
>>629 それ遅いんじゃね?
他言語関数インターフェースじゃなくて、中身もJSなの?
emscriptenは意外にそこまで遅くはないな ただダウンロードサイズがでかくなりがちで、こんだけ待たせるならそもそもネイティブの方がよくね? という根本的などうしようもない問題があるのであまり実用的ではないな
ヒント:キャッシュ
中身もJS emscriptenはブラウザ側が対応する必要無いのがメリット GoogleV8ならJSのままでもそんなに遅くなるわけじゃない asm.jsに変換できればもうちょっと早くなる まあでもどっちにしろ読み込みと本格的に動き出すまでの時間がネックだね キャッシュ関係の工夫である程度改善できそうだけど
静的型言語でもリンクが遅いという問題はあるけど gmpyに関してはすぐ使えるなあ
>>633 Webサイトで初回読み込みで待たされるのは致命的だろ
ライブラリを一元的に提供するサービスがあればいいけど
>>637 Googleとかがそういうサービスを提供してる
>>638 emscriptenで使うようなライブラリがどこで配布されてるの?
それにemscriptenって基本的に全部スタティックリンクするのが推奨なんだけど
ゲームを始めるのに、ダウンロード時間がなくなるといいよね。 ウェブアプリならそれが可能。
ソフトウェア全体を単体のバイナリにするんじゃなくて、 小さなバイナリの集合体にして 必要なところだけダウンロードする方式がでてきそうだな。 実際の所データと同じだ。ステージが進むたびに 必要なデータ(プログラム)をダウンロードする。 あとはそれをうまく最適化すれば、初回読み込みであっても すぐに開始され待ち時間も少なくて済むだろう。 データに比べれば、プログラムのサイズなんてたかが知れてる。
ミドルウェアが一番でかいんだから結局あんまり意味ないんだよねそれ
>>637 > Webサイトで初回読み込みで待たされるのは致命的だろ
プログラムのサイズで待たされることなんてまず無いよw
>>642 なんで? ミドルウェアも必要なところだけ
読みこむようにすればいいじゃん。
JavaScriptはそれが可能。
>>643 俺もそう思ってた
emscriptenのデモ動かしてみなよw
>>644 ああemscriptenの話な
必要なところだけ読み込むっていっても
C/C++のライブラリってもともと結構な依存関係があるもんだからどうしてもデカくなる
まーたJS厨の夢物語かよ お前の言う未来像とかとっくの昔に誰かが考えてるし 毎度毎度大袈裟に語るほど劇的なものじゃない 現実や実現可能性を無視したお花畑イメージを垂れ流しすぎ
>>645 でもさ変わりに、ネイティブ版をやろうと思っても
どうせダウンロードに時間がかかるんだろ?
>>645 だから、それはデータのダウンロードの量でしょ?
ここらへんにゲーム以外のデモがある
https://github.com/kripken/emscripten/wiki こっちはすぐに実行される。
昔のゲームは、データをネットワークからダウンロードするのではなく
ローカルに全てダウンロード済みであるのを前提として
動くようになっている。
だからそれをemscriptenで単純に移植しても
最初のダウンロードに時間がかかるのは当たり前だろう。
でもそれはデータの話。
ソフトウェア自体はダウンロードの時間がかかってないから
移植ではなく新たに作るとき、データのロード部分を考慮すれば問題ない。
自分で何を言ってるのか分かってなさそう
>>650 お前は自分が言いたいことをちゃんとかけ。
スマートフォンでストアアプリって文化圏が出来て、HTML5のウェブアプリがネイティブアプリに取って代わるみたいな未来像は消えた。
>>653 特定の言語でゲームを作れば、大容量ゲームが
ダウンロード無しにできるといいたいのなら
はっきりそう書けよw
賢者は歴史に学ぶ 現在と未来については分からないことが多すぎて学ぶのは不可能だから
>>654 ソフトウェアって言葉が何を意味するのか理解してないの?
普通はデータこみのパッケージを指す訳だが。
つまり言いたいのは、ソフトウェアのうち プログラムは小さいが、ソフトウェア全体はデータ込みだから でかいってこと。
話を戻すと、ウェブサイトで初回読み込みで待たされるのは プログラムではなくデータ部分ってことだよ。
JS厨のズレっぷりがスゴい 自覚はあるようで必死に連投して軌道修正しようとはしてるが そもそもの方向性がおかしい
>>660 その根拠は?
なんで理由も言わず文句言ってる奴が多いんだろうか?
JSを否定している奴ってみんなそうなの?
JS厨が頭おかしくて当時ながら誰も乗ってこないので議論が盛り上がらない というかJSマンセー馬鹿はJSに限った話しかできないからスレチレベルで最悪 他の言語では問題にしてないJS特有の制約をまるでメリットのように宣伝してるのが糞だし 実現してないこと、できないことまで息をするように紛れ込ませる 特殊言語を最高の汎用言語のように語っても端から見たらゴミカスでしかないから早く消えてほしい
と息巻いて書いているが、 具体的に何を批判しているのか全くわからない。 JSを他の言語に置き換えても成り立つ汎用性の高さ。
Ruby厨が頭おかしくて当時ながら誰も乗ってこないので議論が盛り上がらない というかRubyマンセー馬鹿はRubyに限った話しかできないからスレチレベルで最悪 他の言語では問題にしてないRuby特有の制約をまるでメリットのように宣伝してるのが糞だし 実現してないこと、できないことまで息をするように紛れ込ませる 特殊言語を最高の汎用言語のように語っても端から見たらゴミカスでしかないから早く消えてほしい すげーw
そりゃお前と同様に頭のおかしいRuby厨がいたら、それは同様に成り立つに決まってる JS厨が連日妄想を並べて糞スレ化してるのはただの事実でしかない
内容に具体的に反論できてないことを笑ってるだけw
JS厨は具体的な話をしてるつもりなのだろうか… だとしたら、自己反証可能なはずだからやれば? 雲を掴むようなマンセー妄想じゃなくてね
ちげーよw お前がどのレスに対して話しているのかってことだ。 内容がなくただ文句を言ってるだけだから他の言語にしても成り立つんだぞ。
お前以外には成り立たねーよw
JS厨を連呼するだけのうんことasm.jsで妄想してるうんこがいるのは理解できる
JS厨が暴れる限りずっとこの流れだよ
全部JS厨が悪いんだ
その二人、話かみ合って無いからコテでもつけてじっくり語り合ってくれ
asm.jsで妄想してる方は、JSなんて中間言語としてしか残らねえって言ってるやつだろ? そいつをJS厨と呼ぶのはJS厨さんに失礼なんじゃないですか
JS厨が言ってるのは、JSのおかげで未来はあーなるこーなる そうあう不確定な要素に対して具体的な批判をしろ、ということ 具体性を欠いてるのはどっちだ。ただの詐欺師。こんな馬鹿げた話はない
JS厨の言ってることは一切信用できない 上で言われてるようにスマホアプリにしたってブラウザアプリである必然性が既にない 現時点でズレてるわけだ
そう、iPhoneならね から丸パクリした決め台詞でドヤ顔したJS厨を見たら臭すぎて無理だと思った
>>676 言葉は武器なので
相手の武器にお願いをするのは平和ボケか偽善
>>679 いや、武器に見えないんだろw
へなへなした紙ちらつかせてそれで相手がビビるとでも思ってるのかい?
でもさ、意味不明なことを言っていても ワーワーうるさいとキチガイっぽくて怖くね?w
>>616 むしろ、型付けが弱いって言われる条件みたいなもんじゃね<<文字列と数値の暗黙変換
>>681 そうやって差別するだけで勝てると思ってるのが駄目なんだ
油断しても何の得にもならないのに
>>682 型付けが弱いって言われる言語は
基本的な動作としては実行時にデータ型不一致のエラーを出すものだと思う
それだと不便なんで暗黙的に変換するような仕組みが入った
ほら、型付けの強弱と静的動的の区別が付かない馬鹿が現れた。
〉In computer science and computer programming, a type system is said to feature strong typing 〉when it specifies one or more restrictions on how operations involving values of different data types can be intermixed. 〉The opposite of strong typing is weak typing. 普通はこう考えられてるからね
PHPより型付けが弱いJSは 中間言語がお似合いだな
中間言語こそ型付けが重要だろ asm.jsはその欠陥を誤魔化すためのバッドノウハウを集めて中間言語として規定したものと言える
数値の比較は==で文字列の比較はeqのように使い分けるのが明示的 ==しかないのは暗黙的
==による動作が数値と文字列でそれぞれきっちり定義されていれば、 暗黙的ではあるけど、暗黙的な「変換」ではないだろ
言語仕様的にはまず変換することになってたはず
どこから特定の言語の話になったんだ
セキュリティに詳しい人いる? ファイル名をPOSTしてもらってjsonファイルを書き出して返すっていうwebアプリで危険なところある?
ファイル名はエスケープ処理してない場合
教科書的なセキュリティホールだな 他のファイルを除かれる危険性がある
>>695 うん
その除かれるやつをためしたけどNullバイト攻撃はPHP 5.3.4以降では成立しにくくなったって記事読んで%00とかいれるとエラーが起きて除けない
こういう場合ヌルバイトのほかに攻撃手法ってある?
ほかに突破する方法ってある?
ファイル名「test」送信
test.jsonと返ってくる
Java8の更なる延期が決定し、ますますオワコン化激しい昨今ですが Javaプログラマが新たにスクリプト言語を覚えようとしたとき、 オススメの言語は何になるでしょうか? なお、プログラミングできない方の意見は1ピコグラムの価値も無いので、 「どこどこの会社が使っている」などの伝聞は不要です。
自分で判断できない人はJavaを使い続けるのがオススメ
>>697 スクリプト言語の質は言語仕様ではなく実装で決まる
使う人のメリットだけで判断すると、作る人がなぜか作るのをやめてしまう危険があるから
両者のメリットの総和を考える必要がある
実装を見るにはCの知識がある方がいいからCがおすすめ
作る人が作るのをやめるって それ、作る人が一人とからじゃね? だから標準化してオープンソース化して 沢山の人で作るようにしなきゃ
>>697 それこそjavascript一択
Javaってことはwebアプリでしょ
現場、webアプリならjavascriptはまず避けて通れない
馬鹿丸出しw
>>700 標準化しているスクリプトて何があるかな?
とりあえずECMAScriptは標準化されてるな。
>>700 人数を増やしても、やめた一人だけが生き残って他が全滅するパターンはあると思う
正答率が高くないと多数決は使えない
作者やコミッタが全滅して言語が死亡する可能性なんて 真面目に考える価値があるのか?
負の情報量ってあるのかな 二択でも50%以上外れるとか
strtus2 vs spring MVCの構図があって、grailsがあるspringに賭けよう ruby?PHP?node.js?何それオイシイの?
railsって、何かこう豚も煽てりゃに近かったよね 皆ほら、中高生だろうけど物事は冷静に見ようね
>>652 大方、時間の問題で一気に変遷すると恐怖していたものが、
思っていた以上にあちこちの互換性がなくってもたついてるだけで
技術革新によってそれらが廃れる恐怖がなくなるわけではない
710 :
デフォルトの名無しさん :2013/04/30(火) 09:41:31.65
ペルシャ湾で天然真珠調査 世界遺産「復活」に協力 2013年4月30日 09時20分
http://www.chunichi.co.jp/s/chuspo/article/2013043001001486.html 日本の養殖真珠の生産により20世紀前半から天然真珠産業が衰退したペルシャ湾で、
日本がバーレーンと協力し、真珠貝の生息調査に乗り出すことが30日、分かった。
日本の水産技術を使って真珠貝を増やし、伝統産業を復活させるのが狙い。
独立行政法人水産総合研究センター西海区水産研究所(長崎市)などが5月中旬から現地調査を始める。
真珠産業はクウェートやアラブ首長国連邦(UAE)などの伝統産業として知られ、
バーレーンの真珠文化は昨年、国連教育科学文化機関(ユネスコ)の世界遺産にも登録された。
日本が真珠産業の復活を手助けすることは産油国との関係強化にもつながる。
(共同)
とはいえ、日本の方もperlの復活には割りと協力的だよね
ラリーと、その仲間たちがユネスコの世界遺産に登録されるのは何時だろう? オタクはダサいってなレッテルが貼られたままで居た方が、 結局の所、彼らはやりたいことが続けられていたんじゃないだろうか? 金が絡むとと途端にこれだ
>>701 AndroidはWebアプリだったのか、そりゃビックリだ
>>697 groovyかrhinoかnashorn
Javaがオワコンなのに、それは無い
一生、Web開発しかやらないなら兎も角、イロイロと考慮すると最初からjava以外に選択肢ないって それか、PHPとcの組込み、通信機器開発してるようなとこ探すか
選択肢ないなんて弱音を吐くのは、よく考えると珍しいパターンだよな いつものパターンなら、代わりはいくらでもあると豪語しそうなのに
てか、PHPよかjspの方が速いでしょ? 桁落ち、情報落ちだとか考えない高卒でも出来る仕事ならともかく、 それ以外の用途に動的言語って考えられないんだけど
桁落ちの話と動的型言語に何の関係があるのか分からないんだが……
slideshareでframeworkの性能と仕事数を確認しろよアホども
自分が低能だという自覚があるのなら、 仕事に就ける確率を少しでも上げるために よく使われてる言語を選ぶのはアリだな JavaとかPHPとかJavascriptはそういう言語
haskellってできる奴いるの?
phpでアンドロイド開発できる?
phpで一生喰ってける?
プログラムやってると確率が偏るのが不快になる どうせelseを想定しないわけにはいかないなら確率は半々でいい
on
>>726 VBやflashで一生喰っているける?と同義なぐらい危ないでしょ
重要なポイントは市場の変化や需要に耐えられるか、十分な後ろ盾があるかだと思う。
用途の限られた言語を使うとか将来を見通せない本物のバカ
>>727 slideshareでjava,web frameworkって入れりゃ腐るほど資料出てくるだろカス
個人業者ってレベルで何かやるとなると、play framework, grailsあたりか? 流行ってないだろうけど、spring rooが無難だろうな
>>722 そうだね、君は好きな言語を使えば良いと思うよ。
アドバイスすると、それは単なる下手の横好きでしかないけどね
>>731 play frameworkはRails風で生産性が高いって話で実際やってみたが
MVCが完結に書けるというだけで動的型付けができない以上、全くと言っていいほどRailsと似てなくて見事に踊らされたわ
人数が少ないとHTML・CSSと同時にビジネスロジックもゴリゴリ書くからコンパイルが鬱陶しいし、LiveReloadも効かないから一人あたりの守備範囲を広げられない
Pythonはラムダの役立たずぐあいと、 関数内関数の変数スコープの変態仕様のダブルパンチを なんとかしろ。
>>734 は普段どんだけ糞コードを書いてるんだw
具体例を挙げてみろ。200%お前が間違ってるから
まずはPythonが全てにおいて綺麗な物だという 洗脳を解くところからスタートしなければならんようだな。 Pythonは変数宣言を代入で代用しているあたりが汚い。 宣言と代入は別のものなのだから文法も分けるべきだったな。
動的型付けのLL言語相手になにいうとるん?
動的型付けで宣言に型の情報が要らないからといって 変数の宣言まで必要ないとは限らない。 変数宣言には型の指定とは別に、 変数スコープの指定という重要な役割もある。 Pythonは型の指定が必要ないからといって 変数の宣言を代入で代用しているから スコープがへんなことになってしまった。
Pythonだから綺麗ってワケじゃないのは同意だが その理由を変数宣言に求めるのはちょっと浅いな そんなもん仕様次第で何とでもなるでしょ
変数のスコープがネストする言語では、 たとえ動的型言語であっても、 スコープを決定するための変数宣言は必要。 Pythonにもスコープを指定するためのnonlocalがある。 動的言語であってもスコープ決定のために宣言が必要ということは、 そこに型名を書いてもかまわないわけで、 そうすると静的型言語にたいする動的型言語の優位性は揺らぐ。 宣言自体が面倒だという人もいるかもしれないが、 どうせ変数は初期化してからしか使えないのだから、 初期化のついでに宣言をしても手間は変わらない。
じゃあ Perl でいいのではまいか
myがダサすぎるのでlocalを愛用している
関数型言語ほど潔癖にやらないにしても、再代入なんて避けた方が良いに決まってる 宣言のたびにvarをタイプするのに比べたら、nonlocalなんて殆ど使わないから よく使う方を省略可能にするのは正しい
Pythonはウンコなロジックで書こうとすると ウンコなコードになる つまりPythonを嫌ってる人間は……ってことだ
グラヴィティデイズってゲームやってたらグイドおじいちゃんが出てきた
>>744 一理有るけど、nonlocalなんて酷いネーミングから見て分かるとおり、
セオリーを無視した無理がたたっている。
nonlocalは本当に醜いネーミングだが、 外側のスコープの変数に再代入するという邪悪なコードは 醜く見えるべきだからnonlocalでも良い気がする
>外側のスコープの変数に再代入するという邪悪なコードは 他の言語では当たり前に行われている行為だよ。 例えばif文の中のスコープから外の変数を書き換えたりな。 まぁPythonのif文はスコープを持たないんだけどな。
>>733 RailsっぽいってのはCoCのことだろうけど、とりあえず動的片付けによる生産性なんて幻想だろ?
PHPなんて、次のバージョンでわざわざ型を導入って聞いたぞ
というか、一人当たりの仕事量だとか楽さ加減を追求するんであれば、node.jsでいいでしょ
そもそも、Railsにアドバンテージなんてあったの?
> 例えばif文の中のスコープから外の変数を書き換えたりな。 最近はif文で再代入なんてダサい方法じゃなく if式で値を返す方法が主流 まあPythonのif文は値を返せないけど(if式もあるけどね)
if文で茶々が入るなら、繰り返し文でもかまわんよ。
具体例を挙げろって言ってるのに。 1)ラムダが使えない、2)関数内関数のスコープ云々 って明らかに 1)関数として分割すべき、2)nonlocalで明示することを知らない だけだからなあ
銀の弾丸ってframeworkのレベルな話で、文法レベルの問題じゃないよね プロトタイプ作るのに動的言語が幾らはやかった所で、 その後での保守・改修を考えたら静的言語の方がマシだしさ
for文でnonlocalが必要なら最悪だけど、不要だからなぁ だからif文やfor文にスコープが無いことを十分にdisってからでないと 説得力が無い でも、if文やfor文にスコープが必要な程 長い関数を書く奴が悪いって流れになりそう
nonlocalってダサすぎだろって話。 しかも最近までそれすらなかった。
いまでも広く使われてる Python2 には nonlocal 入ったんだっけ
>>756 そうだね。理由を説明しようとすると論破されちゃうから
これからは感情的にダサいって連呼すれば良いよ
必要なところで明示すれば、他のすべてで宣言が不要になる さらに、そんな明示をするような処理自体、あまり書かない方が良いというスタンス
宣言が不要になったところで、初期化は必要だから 結局コストはかわらんというのに。
実際、まともなコード書いてれば問題ないので 具体例を出されないとわからん コストが変わらんのなら宣言しなくていいんだよね。無駄。
Python3をずっと使ってて、時々Python2に戻ると 地味に便利な記法が使えなくてイラッと来るな こういうのとかさ x, *y, z = [0, 1, 2, 3, 4] print(x, y, z) #=> 0, [1, 2, 3], 4
無駄なことはない。 処理系の実装によりマッチした文法になることで表現の幅が広がる。 インタプリタ内で宣言と代入では別の動きをするからな。
それコードだけでは結果がわからんし 使いどころもないだろ
>>764 みたいな極めて抽象的な絶賛を見ると
ああ、またあのキチガイJS厨か、レスして損した。と思う
仮に代入が邪悪だとしても初期化は悪くないので 勘違いで悪者扱いされる心配のないデザインが望ましい
闇に隠れて生きるってのを思い出した 正義か悪かという問い自体が隠れてしまうので勘違いも起きない
はやく人間になりたい
こうやって見ると、Pythonユーザも中々のモヒカンっぷり 具体的なコードを出す事すら出来ない低能がdisるには少々荷が重いな
773 :
デフォルトの名無しさん :2013/05/02(木) 08:58:29.82
2ch見てると日本でもPythonファン多いと勘違いしてしまう
でも周りにいないよね
それはお前が低脳集団の中にいるからだろ
777 !!!
LispやJavaScriptなんかで良く使われる下のような手法を多用する人たちからすると、 nonlocal宣言とか受け入れがたいんじゃないの? function foo() { var a,b,c; return function() { //a,b,cを参照更新する処理 }; }
すこし文字数が多いのとダサいぐらいで死にはしないから平気 ただ nonlocal がたぶんない Python2 でも平気なのかは知らない
別に?
クロージャはOOPに無関心、つまり政治に無関心と見なされる
さらにfoo()が単独のクロージャを戻すんじゃなくて、 複数のクロージャを格納したリストやオブジェクトを戻すとしたらどうかね? function foo() { var a,b,c; return { vvv:function() { //a,b,cを参照更新する処理 }, www:function() { //a,b,cを参照更新する処理 }, xxx:function() { //a,b,cを参照更新する処理 }, ... yyy:function() { //a,b,cを参照更新する処理 }, zzz:function() { //a,b,cを参照更新する処理 } }; }
python2ではリストで代用してた ミュータブルなオブジェクトをよからぬ所で変更するのが危険なのは プログラミング初心者でも知ってるから普通は避けるし リストで代用してる時点でなんかヤバいことをしてると気付く nonlocalも極力使わないのが流儀だろう
ハッシュテーブルも政治に無関心
nonlocalはあまり使わないようにというが、 そのわりに繰り返し文や分岐文がスコープを持たないという謎仕様。
それで問題になるのって何? 繰り返しや条件分岐を外部関数として分離しなければならない時? まあ、そんな時があるならそうすれば良いだけだが
何言ってるのかよくわからない
>>779 Pythonにはgeneratorがあるから無問題
再利用可能な関数内の変数はローカルだけど あくまで制御フロー内のブロックに対してはローカルとする必要がないというだけ
JS厨は愚かな操作のためにそれ以外の大多数の普通の変数にいちいち意味もなくvarを付けてたのか。無様だな
nonlocalよりはましだろ。
ローカルでないとう警告的な明示の方が圧倒的に有益だわ
おいおい、何か凄いことを言い出したぞ。
しかもnonlocal付けなくてもwriteできないだけで readだけなら可能なんだよね。 代入の有る無しでスコープが変化する、まさにカオス。
外部のミュータブルな変数を不注意に変更するクロージャが 危険だということに反論できんの?一般論だと思うが
JSというかLispで昔から使われてる手法なんだけどね
安全性から考えて参照することに問題はない ファイルのアクセス権とか見ても普通のことだろうに
>>795 そのくせ繰り返し文や分岐文にスコープ無いんだよな。
外部の変数さわりまくり。
クロージャが危険っていうならレキシカルスコープを採用すんなよw
pythonが万全という意味じゃないよ。動的スクリプトとして利便性は重要
ただJSは無駄な宣言方式で無意味に危険なクロージャということと
pythonへの批判が的外れすぎってだけ
>>798 関数の内部でありローカルではない
ローカルである必要性を端的に説明しろ。無理だろ
関数と繰り返しを一緒くたにするセンスが理解不能
JSはどんだけ無駄で汚い設計してるんだ
まともな言語を勉強したほうがいいぜ
自分の好みの言語を作ればいい
代入が無ければグローバルを参照? 代入があると参照もローカルになる?
なんでJSが出てくるのか不明だが。 >関数と繰り返しを一緒くたにするセンスが理解不能 スコープの範囲は出来る限り狭い方が良いに決まってるだろ。 なにをいまさら。そんな基本的なことを否定してまでPythonを擁護するとは愚か。
>>803 ・副作用はできるだけ避けるべき
・副作用が必要なら、できるかぎり局所化するべき
という基本的なことすら守れず、
>>782 みたいなクソコードをドヤ顔で出して
誰も否定すらしないスレで何言ってんの?
いや、「良いに決まってる」っておかしいだろ 決まってるならヤバい例を出せ
>>782 のコードは、オブジェクトのプロパティa,b,cに対する副作用を伴う操作を
その下に並んでる関数に限定するっていう、わりと有用な手法なんだけどね。
Lispの時代から多用されてる。
長い記述のループがネストするなら関数を分けた方が良い(これは一般的にそう) また、ごく短い記述で、関数分割するまでもないループなら内包表記を使う (これは内部スコープあり) さあ、反論をどうぞ
lisperかつJS厨かつプログラミング下手って救いようがないな
Lispが関数型言語の仲間に入れてもらえない理由が良く分かった
JavaScriptの有名なライブラリは、ほとんど
>>782 のコードの延長的な手法で書かれてるんだけどw
>>806 構造体と関数ポインタを用いていた時代をぶち壊す努力をしてきた人に
その時代を認めるように言っても
聞く耳を持つわけがない
ちょっと前にJSはバッドノウハウが一杯と言われてたのこれか
>>805 どう考えても変数のスコープは出来るだけ狭い方が良いだろ。
本当にそんなところに疑問を感じてるなら相当間抜けだぞ。
>>813 それで問題ない。
>>782 のやり方の有利な点はクラスを定義するよりオーバーヘッドが少ない場合があることかな。
>>813 クロージャを使えばOOPができるということでしょ。
言語や人によってどっちを使うかというのはあるけれど、
OOPのほうが分かり易いように、自分は感じる。
オブジェクトのプロパティへの直接アクセスを制限する方法が無い言語で、
その制限を
>>782 は簡単に実現できるね
>>814 クロージャと一緒くたにする必要はないよ
繰り返しや条件分岐は変更が見えるから
ただの制御フローでフロー内の変数を変更できないとデメリットの方が大きい
もちろん複雑化したら関数化するが、それでもクロージャは避ける。当然だろ?
>ただの制御フローでフロー内の変数を変更できないとデメリットの方が大きい そこで宣言の出番だろ。C言語なんかでは当たり前に出来ること。
Cでも変更すべきでない変更を変更できるよね そのブロックでしか使わない変数なんて上書きして使い回しても問題ないし Cで宣言すれば安全って何を想定してるのか
訂正:変数を変更
>Cでも変更すべきでない変更を変更できるよね ローカル変数を外からアクセスできませんよ。 スコープを狭めることで可読性もあがる。
>>773 悪いファンを追放している印象しかないんだが、いつどこでファンが増えるんだ
ひとり頭のおかしい奴が常駐してると思っていたがPython厨だったのか
>>822 何言ってんだ?Cはforブロックの外側の変数を弄れる。
関数にはnonlocalが必要なのに、繰り返しは
外側の変数を変更できるのはおかしいという
>>798 とか
Cの宣言で安全という指摘は的外れ。CはPythonと同様に副作用を使ってる
Cと違ってブロック内で死ぬはずの変数が
Pythonではブロックを抜けた時に生きてた場合に危険と言ってるのなら話は別だが
そんな場合があるのか疑問だしnonlocalからの文脈からするとおかしい
外側の変数変更の危険性を考えたら global宣言、nonlocal宣言がいかにまともな仕様かわかるな JSの無意味なvar宣言と無宣言での破壊はアホ
Pythonの繰り返し文や分岐文にスコープがないのがダサいといってるわけで。
スコープが狭いに越したことないのは自明だろ。 覆せないからといって適当なあおりをするなよ。
スコープが狭い方が良いというより、定義と使う場所の距離が近い方が良いんだよ ブロック内で使う変数なら最初に代入すれば何をやってるのかは自明なので問題ない 問題は変更をあちこちで繰り返すこと。省メモリの話ならまた別だが
ループと条件分岐を適当に含むアルゴリズムを 実際に書いてみれば、スコープの必要性が分かる 検証してみようぜ
Python厨は実際のコードを書かないんだよな 日本語不自由なんだから実際のコードで示せばいいのに
口で言うばかりじゃなくてPythonで問題が生じるコードを示してくれ。直してやるから
動けばよいというだけならどうとでも直せますがな。
個人的に「ダサい」って言ってるだけだからなんの問題もないんだろうな
nonlocal宣言でPythonをフルボッコしに来たJS厨が見事に返り討ちにあっててワロタ JSの危険な糞仕様が露呈しただけ Pythonにはscipyというチート級の便利なライブラリがあることも明らかになった
なぜJSが出てくるのか。
参照と更新でスコープが違うっていうのが受け付けないな さらに、変数がオブジェクトを指している場合には、内部の更新に参照スコープが使われるんだよね?
JSのクロージャの糞仕様を叩くと「nonlocalよりマシ」と言い張り続けるから どっちが正当かは明らかなのに
>>840 理解の仕方が間違ってる
Shadowingのある言語を使った事無いの?
なんという被害妄想w JS厨はPythonのnonlocalなんて知らんと思うがw
参照はできるが書き換えはできないという概念が理解できないプログラマはいないはずだけどなあ 例えば定数を考えればその有益性もわかるだろ
ただJSの糞仕様はnonlocalを正当化するのにちょうど良かったよ こんなんをどや顔で支持できるとか逆にすごいわ
>>844 本当にreadオンリーならそうだが、実際にはメンバの更新は可能だからその理屈はおかしい。
実際には、代入を宣言に代用したから機能に対して文法がブッキングしただけ。
nonlocal宣言してない場合、 外部スコープの変数は書き換えられないけど、 外部スコープの変数が指すオブジェクトの中身は書き換え可能なんでしょ?
>>837 scipy使わなくても余裕だった
from numpy import *
def kmeans(data, K):
xs = arange(len(data)) % K
random.shuffle(xs)
while True:
ms = array([data[xs == k].mean(axis=0) for k in arange(K)])
ys = array([argmin([linalg.norm(p - m) for m in ms]) for p in data])
if allclose(xs, ys):
break
xs = ys
return xs
numpyもすげー
なんで?
scipyにはscipy.cluster.vq.kmeansっていう そのままの関数があるから禁止する意味分かるけど、 numpyを禁止する理由が分からんw
>>837 の御題はJavascriptだと実装が大変だけど、
Pythonだと簡単に実装できてしまうからフェアじゃない。
>>852 だって簡単に解かれちゃったので悔しいじゃないですか…
>>833 JS厨は実際のコードを書かないんだよな
日本語不自由なんだから実際のコードで示せばいいのに
ループと条件分岐にスコープを持たないJSとPython同士で何やってるんだw
そうなんだ。だからJS厨はJSマンセーからCでは云々に切り替えたのかwアホだなあ
面白いというかC言語で書かれたライブラリを呼んでるだけじゃないか
>>846 >>847 Pythonには数や文字列やタプルなどのimmutableなオブジェクトがあり、
これらは書き換えられないことが保証されてて
読む方もそれを期待して読むけど、再代入されたら変数の指す先が変わってしまう
だから外部スコープの変数に対して
再代入するときにnonlocalを明示するのには一理ある
>>859 内包表記やスライス記法や演算子オーバーロード等の構文要素も駆使してるけどね
名前付き引数とデフォルト引数も使っているね
>>860 現実的に考えろ
そんな言語だれも使わない
>>860 nonlocal宣言つけないデフォルトのスコープ(更新の影響が及ぶ)が狭くなってるのが安全と言っておきながら、
nonlocal宣言つけなくても外部スコープのオブジェクトを更新できてしまう場合があるのが矛盾してると思うのだけど、
自分の理解が間違ってるのかな?
>>864 あれ?Javascriptにはimmutableオブジェクトが無いから
>>860 に書いた事が理解できないの?そんなこと無いよな?
そんなことより
>>837 を解けよJS厨
お前等が言い出したんだろ?
それとも具体的なコードは何も書けねーのか?
>>782 みたいなゴミは頼まれなくても書くくせに
JS厨はAmachangを早く召喚するんだっ!!
JSだとNumpyが提供してるような機能を用意するのが面倒だからな それに言語仕様的に特別なものが用意されてるわけじゃないから、 ifとかforとか組み合わせて書くだけで何の面白みも無い
プログラミングスキルよりも言い訳スキルのほうが高いようですね
>>869 それが日本企業で出世するために必要な能力だから仕方ないさ
>>865 Javascriptにimmutableオブジェクトはあるけど、そんな面倒な区別をつける必要は無いな
>>868 プログラムを簡潔に書いたり、簡潔に書けるライブラリを用意したりする
言語機能はJSには無くて、そういうのと全然関係無いところで
延々と議論してるわけ?アホなの?
JSの人は大体朝に書き込んでるから朝まで待て
>>864 間違ってる。意図せずそんなことすることはできない
だから単に危険なクロージャのもっと醜い明示にしかならない
Node.jsをちょっとした自動処理に使おうとしたら面倒臭すぎた CommonJSってPHP/Python/Perl/Rubyの標準ライブラリとは違って あくまでインフラなんだな…
でもリストでのクロージャは醜いことを除けばJSのそれに近いのか あるはずの定義(代入、var宣言)がないとクロージャということになる これは機械には自明だが人間には怪しい。nonlocalの方が良い仕様だな
うむ、python3良いな
>>873 "朝にも"じゃなくて?
一日中書き込んでるように見えるが
>>876 Javascriptとnode.jsは汎用言語とその実行環境ってよりは
emacsとemacs lispのようなアプリとアプリ拡張言語の関係と思った方が正しい
>>877 リストでのクロージャというのは何ですか?
>>879 同じ人が一日中自分に粘着してると感じ始めたらお薬を飲んだほうがいいと思うよ
>>880 再代入はimmutableなオブジェクトを指す変数すらも変更できる
でも、nonlocalつけないと再代入できないから
うっかり外部スコープのimmutable変数を上書きする危険は減る
ってことだろ
>>883 じゃあこの時間帯にいるJS厨は
コード書けない低能の方か
>>884 Pythonにはmutableなオブジェクトっていうのは無いの?
外部のスコープに存在すればそれもimmutableにしてくれるの?
有能な方のJS厨待ち
ローカル変数を宣言したつもりが、 気付かないうちに外部スコープの変数とバッティングして書き換えてた みたいな、ありがちなバグが減る訳だね
JS以外の参加者も募集中だぜ Ruby、Perl、PHP
>>886 >>888 を読んで
一方、外部スコープの変数に対する破壊的操作を
気付かないうちにやるというのは、およそ在りそうもない
>>889 おれは自分の知らない言語の仕様を質問してるんだがw
>>890 むしろJS以外が見たい
そしてJS厨はコード書くまで黙ってろと言いたい
>>894 PythonとPHP以外はだいたいわかるよ
Perlは最近の事情は知らん
>>895 なおさらなんでそんな質問するのか理解できない
これから不毛な言い争いを避けるために実際にコード書かせることにしようぜ これだけで馬鹿を排除できる
仕様上、意図しない破壊は行われない、明示的破壊も避けるでFA
それに対して外部変数の破壊を当たり前とするアホ
>>734 がいちゃもん付けただけ
意図を勝手に汲んでくれるとかすごい言語が現れたなw
アクセスして欲しくないメンバにアンダースコアを付ける習慣もそうだが 不自然な方法でしか実現できないものは意図しない限りその状況にならないのだから安全と言える
>>897 馬鹿フィルターね。
機能するなら良いんだけど、馬鹿だからその日本語も読めないよ。
俺が馬鹿だったwこの人に説明させちゃダメだなw 自分で調べとくわw
>>899 でも、メンバ変数は破壊できるんでしょ?
不自然だよね。
自分で調べても同じ答えしか出ないよ
>>905 「破壊しようと思えば」、破壊できる
逆も然り。すごく自然だろ
ローカル変数のメンバ変数は何もせずに書き換え可能なのに、 ローカル変数自体の書き換えはnonlocal無しで出来ない。 しかし、読み込みはnonlocal無しでもOK。 なんて煩雑な言語なんだろうね。 変数のスコープってコード解読する上で凄く重要なのに。
あ、メンバ変数ってリストや辞書の要素のことを言ってんの 俺が言ったアンダースコアを付けるメンバはクラスのメンバな 読み込みが出来てどんな問題が? 未定義のリストや辞書の要素にアクセスすることはないだろ 現実的に考えろ。どんな問題があるのか一切言えてない 具体的なコードを晒せ
参照しても書き換えができないことで安全性が確保される。まずこれが理解できてない あとローカルで定義してないリストにインデックスを指定してメンバ変数を書き換えるという ありえない状況しか想定できないから馬鹿なんだよ 一瞬でもそれがどんなコードなのか理解しようとしたのだろうか
> 参照しても書き換えができないことで安全性が確保される。 動的言語とは真逆の考え方だな。
ぶっちゃけ、今日のやり取りで価値があったのは numpyすげーって分かったことだけだなw
このpythonのスコープdisってこのパートスレで今回が初めてじゃなくて 一言一句お経のように同じだからたぶん同一人物の十八番なんだろうが それで批判になってると思ってるらしいのがヤバい まともなプログラマならまず問題にすらしない点だろ。実用上問題ないうえに自然な保護なのだから
>あとローカルで定義してないリストにインデックスを指定してメンバ変数を書き換えるという >ありえない状況しか想定できないから馬鹿なんだよ ごめん、俺はありえるわ。 外のスコープのオブジェクトのメソッド呼んだり普通にするわ。
JS厨が普段糞コードを量産してるという事実が残るだけ
JS厨は未定義のリストの要素を意図せず書き換えるw
>自然な保護なのだから だったらメンバ変数の書き換えも保護すれば? そうなってないのは、これが保護が目的じゃなくて、 単なる文法の都合上の産物だから。
>>914 > 外のスコープのオブジェクトのメソッド呼んだり普通にするわ。
それを、外のスコープにオブジェクトが存在することを知らずに
うっかりやるのか?
別に自覚的にやる分には、そして必要なら破壊的操作だろうが代入だろうが好きにすれば良い
再代入は、外のスコープに同名の変数が存在する事に気付かずに
うっかりやることはあるけど、それはnonlocalで保護される
x = 100 y = [1,2,3] def f(): x = 200 # これはローカル変数の更新 y[0] = 4 # これはグローバル変数の内容の更新 この辺の動作が直感的でないってことを言いたいんじゃないの?
>>918 「意図して」テクニカルなクロージャが実現できる
馬鹿には無理
>>920 その操作か不自然だと言ってるんだが
関数内の変数は普通ローカルだ。yはどこから来た?
それが意図しない結果だとしたら、本当はどうなって欲しいんだ?
Numpyがあるから、昔はFORTRANでやってたようなことを Pythonみたいなスクリプト言語でやろうと考えるわけかね
>>924 自分で書くかどうかならともかく他人の書いたコードがそんな感じになってたら
xもyも両方ともグローバル変数の更新だなって誤解する奴は多いだろ
>>925 numpy, scipy, matplotlibをインストールすれば
数値計算からグラフ書くところまで一通り揃うからね
ベクトル・行列演算はBLAS等で最適化されてるから
スクリプト言語の遅さ関係ないし
関数内で定義してるものをグローバル変数とかありえないだろw そういうレベルを考え出したらもうどうしようもないわ
>>926 それはPythonを書ける人間がそう思うってこと?ありえないよ
>>925 ,927
一発ポンと行列計算しただけで終わりの計算なんてあんまり無いぞ
結局Pythonがネックになる場合は多い
>それを、外のスコープにオブジェクトが存在することを知らずに >うっかりやるのか? うっかりもなにも、a=0で名前が被るのも、a.m=0で名前が被るのも 「a」さえ被ればよいのだから同確立だよ。 前者だけ守られて後者が守られないのは、 これが保護目的じゃなく単に宣言を代入で代替した文法上の 制約でしかないから。変なところに夢見るなよ。
>>930 巨大な行列だと計算量のオーダー的に行列演算の比重が大き過ぎて
他は無視できる
ただ、うまく行列演算の組み合わせに落とせないときは
Cで頑張るか(numpyのarrayは変換コスト0でCの配列として扱える)、
Cythonで頑張ることになるね
やっぱり手軽さだよ。全てpython内で完結するのが良い
sympyで数式処理できるのも面白い
普通の変数と区別するためのシンボル宣言が面倒だから
数式を微積やその他の変換したいだけのときはmaximaとか使うし
シェアウェアほどの強力さはないけど何よりお手軽
>>931 何言ってんだ?マジで想定外の結果になる具体的な動くコードを挙げてくれ
>>931 お前は外部スコープにaという変数が無いと思ってるのに
a.m = 0 って書くのか?外部スコープにaが無ければ未定義エラーだが
本当に、もう少し考えて書いた方が良いんじゃないか?
巨大な行列を扱うならいいんだけど、3次元ベクトルを別個に大量に扱ったりする計算だと numpyが速くてもほとんど意味ないんだよな pypyでも全然ダメ
>>929 俺は間違えそう。
省略可能でいいからローカル変数であることを明示できる宣言があればいいのにと思う。
pypyは面白いけどまだ、というかずっと?おもちゃ程度にしか使えない
>>934 前々から言ってるように、可読性の問題だ。
読む方から考えてみ?
代入の有る無しでスコープが変わって、
しかもnonlocalが有れば外部スコープ。
スコープ調べるのに代入のあるなしを調べるなど煩雑この上ない。
>>937 失うものの多さの割には実際大して速くないからなあ
普通にOCamlやHaskell等のshadowingがある言語を使ってると Pythonのshadowingも「ああそうだね」としか思わないが。
>>939 >>920 のxはローカル変数でyはそうじゃない
これはf()の内部を見るだけで把握できる
曖昧性は無いし、f()内部を局所的に読むだけで理解出来るので可読性も高い
(あと、y[0] = 0 を見て変数宣言だと思うアホがいるなら、向いてないからプログラマ辞めた方が良いと思う)
>>940 速くて数十倍、たまに遅くなったりして平均して二倍くらいになれば良いかなって感じか
面白いので改良は続けて欲しいがライブラリがついてくることはないだろうな
>>939 スコープが変わるって考えに囚われすぎ。普通に読めよ
>>941 Haskellとは違ってPythonでは普通の代入が変数をシャドウイングするのがダメなんじゃないの?
>>944 Haskellとは違ってって、お前Haskell知ってんの?
>>942 なぜ変数のスコープを調べるのに代入のあるなしを調べる必要が有る?
不自然だよ。
>>946 なんだ?可読性の話はやめて、自然かどうかの話にするのか?
不自然だから可読性が落ちるんだろ。
>>946 心配しなくても代入がある場合は参照に先行するから調べる必要ない
お前は具体例もなく変な妄想を恐れてるだけ
そんなことより、いいかげんJS厨は
>>837 を解いてくださいよ
既に10回くらい書けそうな分量の日本語を書き込んでますよ
それだけ時間があれば書けたんじゃないですかねぇ?
>心配しなくても代入がある場合は参照に先行する その代入のあるなしを調べる必要があるじゃねーかw
>>848 これ、クラスターが空になったらどうするの?
空のクラスタは中心が原点になってるように見えるけど
レスからJS厨のレベルの低さを察してやれよ…
>>951 調べる必要ない。上から読み下せばわかるから
調べなければいけないと言い張るなら例を示せ
そろそろコード頼むわ… 飢えてきた…
>>954 上から読み下していくのは調べるのとどう違うんだ
>>955 待て、朝になったらコード書ける方のJS厨が来るらしいぞ
それまでスレが持つか分からんが
>>952 meanでnanが返ってくる
でも、変数msはargminで使われてるだけだから、全体がnanに汚染される事は無い
本当はargminじゃなくてnanargminを使った方が良いけど、
そもそも御題のリンク先を見てもクラスタが縮退したケースについて何も書いて無いから
プログラマ観点でいえば、その場合は未定義
>>956 なんの積極性も苦労も混乱も生じない
お前がびびりまくってるコードを見せてくれ
結局ライブラリの違いだよな。 どうせnumpy.jsがあればJSでも同じように書けるんでしょ。
あるの?ライブラリが貧弱な言語は流行らないだろ
JavaScriptはインデックス演算子のオーバーロードができないからお話にならない
あらら
Javascriptってインデックス演算子どころか四則演算もオーバーロードできないだろ? 論外だからnumpyがあったら〜とか言わない方が良いよ
数値計算はインデックスを多用するからな pythonのインデックス指定は非常に強力で、numpyでもフルに活用できる その点においてjavascriptはFortranにすら劣る
演算子のオーバーロードなんてちょっと記述が簡潔になるだけじゃないのか? そんなに論外なのか?
+-とかはどうでもいいけど インデックスの範囲指定を使ったループの省略は行列操作をやる上で結構便利だよ
おお、
>>837 面白そうだな
確かにJavascriptはちょっと長くなるだろうが
Pythonはリスト内包でジェネレータが書けるのもポイント どっかのコーヒーと違ってメモリ食わない
今日はまだ予定ないから、ちょっくら書いてみるわ クラスタリングとか懐かしいな
やっぱ結構複雑だな
var _ = require('underscore'); var sy = require('sylvester'); function kMeans(data, K) { var xs, mean, ds, i, j, k, d, x ,sum, min, minIndex, ZERO; ZERO = $V(newArray(data[0].elements.length, 0)); xs = newArray(K, []); for(i = data.length; i--; xs[i % K].push(data[i])); console.log(xs); do { newXs = newArray(K, []); mean = newArray(K, 0); for(i = K; i--; ) { for (sum = ZERO, j = xs[i].length; j--; sum = sum.add(xs[i][j])); mean[i] = sum.x(1 / xs[i].length); } for(i = K; i--; ) { for(j = xs[i].length; j--; ) { var x = xs[i][j]; for(k = K, minIndex = k - 1, min = mean[k - 1].distanceFrom(x); k--; ) { d = mean[k].distanceFrom(x); if (d < min) { minIndex = k; min = d; } } newXs[minIndex].push(x); } } } while (!isEqual(xs, newXs) && (xs = newXs)) return xs; }
function newArray(n, e) { for(var r = [], i = n; i--; e.slice ? r.push(e.slice()) : r.push(e)); return r; } function isEqual(l, r) { var i, j; if (l.length !== r.length) return false; for(i = l.length; i--; ) { if (l[i].length !== r[i].length) return false; for(j = l[i].length; j--; ) if (!contains(l[i], r[i][j])) return false; } return true; } function contains(l, e) { for(i = l.length; i--; ) { if (_.isEqual(l[i], e)) return true; } return false; }
せっかく書いてくれたのに批判的なことを書くのは心苦しいけど、 正直これならCで書くレベル
まあcでも別に良いと思うが どっちでも慣れてる人なら大丈夫だろう
どっちでもいいならCで書くわな CommonJSに比べたらまだCの標準ライブラリの方が使いやすいし
>>848 は実際もう少し短く書けるし、Pythonとの差は大きいね
from numpy import *
def kmeans(data, K):
xs, ys = random.randint(0, K, len(data)), zeros(len(data))
while not allclose(xs, ys):
ms = array([data[xs == k].mean(axis=0) for k in arange(K)])
xs, ys = array([nanargmin([linalg.norm(x - m) for m in ms])
for x in data]), xs
return xs
975が良いことを言った コードを書かせるのは心苦しい 書かせれば万事解決すると予想していたのなら尚更
いや、問題は解決はしたよ 実際のコードではJSのほうが圧倒的に可読性が低く冗長だと明らかになった
981 :
デフォルトの名無しさん :2013/05/03(金) 09:51:34.71
心配しなくてもいいぞ わりと楽だったからw まあforで直接ロジック書いてるからpythonより長いけど 決まり文句的なところがあるし言うほど大変でもない
ちなみに俺Pythonが何やってるのか分からないんだが これ、可読性が高いのか?
ちなみに俺はK平均法というもの自体がわからないんだが(住民代表)
確かにw
初期値としてランダムにクラスタを割り振り、 ループ内で各クラスタの中心を求めて、中心に最も近いクラスタに割り当て直す クラスタの割り当てが変更されなかったらループ終了 ロジックがそのまま記述されてるから、凄く分かりやすい
>>985 しかし現実は
「allclose?mean?axis?arrayで囲ってる?xsとys交換してから比較?linalg?norm?」
Pythonのコードは知的教養レベルが高い人が抽象的な言葉でわけのわからん議論をしてるのに
似てるw
ただ、その割には他の言語でもたいして大変じゃないんだよなあ
>>986 お前はコード書いた
>>973 >>974 じゃなくて、コード書けない方のJS厨だろw
自分は書けなくて逃げてたくせに、書ける奴が現れたら
> ただ、その割には他の言語でもたいして大変じゃないんだよなあ
って恥を知れ馬鹿ww
>>987 俺はそんな暇人じゃないんでね
お前こそコード書いてないくせに偉そうに
while文と内包表記を混ぜないでどっちかに統一すればいいんじゃないかね
こうなってくると、C言語とHaskell見たいな
>>986 Python(numpy, scipy)は知的教養レベルが高い人が使うもので、
Javascriptは底辺Webドカタが使うものってことだね
数式だって分かる人には読みやすいが、馬鹿には暗号になってしまうし
人に因って可読性が違うのは仕方ない
>>985 ,990
おまいらありがとう。たぶんわかった
K=2 ならある類似性を持ったクラスタ 1 に属する要素と
クラスタ 2 に属する要素に分類するわけね
>>992 これは有り難い
でも最初にこれ見ちゃってたら自分で考えようとしなかっただろうな
>>993 せいぜいイディオム勉強してPythonの知的教養レベル上げて満足してろよw
俺は暇人じゃないんで、そんなバッドノウハウいらんし、
応用が効いて分かりやすいJSでいいわw
意外とcやjavascriptのベタベタな古臭いコードで何とかなるもんだな。
997 :
デフォルトの名無しさん :2013/05/03(金) 11:28:27.35
とりあえず埋めときますね
>>994 >でも最初にこれ見ちゃってたら自分で考えようとしなかっただろうな
同意
既にモチベーション無くした
リスト内包は集合論とかの数式を見慣れた人には分かりやすいよね
999
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。