【Lisp】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ48【pl,rb,php,js】 [転載禁止]©2ch.net

前スレ
【Python】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ47【pl,rb,php,js】
http://peace.2ch.net/test/read.cgi/tech/1417333026

Webもスクリプトも趣味でやってるうちが華です

>>1
勝手にLisp追加してるんじゃねーよ
ボケカス
しね

Python（numpy, Cython）が最強すぎてバトルにならなかったからね
外したくなる気持ちは分かるよ

>>1
断りなくスレタイを変えるべきじゃない

【Python】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ48【pl,rb,php,js】
http://peace.2ch.net/test/read.cgi/tech/1425065275/

【】内はオマケみたいなものだから別にどうでもいいでしょ。
スレを二重で建てるほうがどうかと思うが。

こんなゴミスレ建てるなボケが

>>1
勝手に名前を変えない、なんて、基本中の基本だろ。マジでこの類のスレ・板に近寄るな。

別にいいじゃん。少しくらい変えたって

pythonは無名関数がlamdaみたいな貧弱なものしかない時点でお話にならない

Lispてバトルに参加する資格ないよね？(´･ω･｀)

Rubyもメソッドの引数以外のところで無名関数使おうとすると似たようなもん

>>12
eventSource.onXXX のようなイベントハンドラ登録で無名関数は使わないの？

Pythonはそういう場合Javaみたいに律儀にリスナを実装(ダックタイピングだけど)するのが普通だし
Rubyだと設定より規約(笑)とかいってメソッド名で勝手にバインドするような発想になるでしょ

pythonの場合はわざとしなかっただけだよ

この程度でお話にならないってｗ

Rubyは関数内関数が書けないから
proc{}やlambda{}に頼るしかなくて、
結果的に関数呼び出しが()になったり[]（または.call()）になったりと
本質的でない使い分けが必要でゴミすぎる

def f(x)
  ->(y){x + y}
end
p f(1)[2] # ()と[]の使い分けがウザイ



def foo(x)
  def bar(y)
    y * y
  end
  x + bar(x)
end
p foo 10
p bar 10 # barがfooの外側から参照できる。よってこれは関数内関数じゃない

関数がクラスに属すという考え方の Java 世代の言語と、
第一級関数をサポートするその次の世代の言語との差かな。
後付で対応した言語は、どうしても汚くなる。

lambdaや[]は百歩譲って目を瞑るとしても->だけは許せないわ
これ考えた奴は一体何のためのアローだと思ってるのか

(y)->{x + y} の語順ならよくあるけど、 ->(y){x + y} なん？

->はλと読め、らしい

マスコミが絶対に触れない事実
注）自民党以外が在日から帰化したスパイ、またはその影響下にあると仮定してご覧ください。

よく言われる
失われた２０年　→　約２０年前　初めて自民党が単独過半数を割る（小沢の新生党が与党介入）※
失われた１５年　→　約１５年前　自公の連立政権が始まる　　（公明党の与党介入） /

※このとき、初めて８０円/ドルという超円高誘導されて、日本の製造業は衰退・空洞化
　＝中国・韓国が台頭し始める。日本の技術者が、大量に韓国などに引き抜かれるようになる。
　イオン（民主党・岡田家）や大型パチンコ店が、地方経済や商店街を食いつぶすための、
　大店立地法が成立。在日パチンコ屋のCM・チラシが解禁・大型チェーン展開が始まる。
　日本の学力低下が目的の「ゆとり教育」の本格導入。（後ろ２つは、１７年前。）
※このときの羽田首相（新生党）の顔がモロに半島顔。
※このとき、小沢の新生党を全力で選挙支援したのが、創価学会といわれる。
※このとき、自民「単独」政権（公明抜きの単独２/３議席）の復活に、圧倒的不利な
　比例選挙制度へ法改悪↓

2014総選挙の比例当選率　
政党名 　　　　自民　　公明　　民主　　維新　　共産
比例区　　　　　　68　　　26　　　　35　　　30　　　20
合計数　　　　　 291　　　35　　　　73　　　41　　　21

比例当選率　　23%　　　74%　　　48%　　73%　　　95%　　←※

共産・公明・維新は、比例制度を廃止すれば消滅ｗ
(公明の小選挙区は、選挙協力の見返りとして、自民党は候補を立てられない上に、
自民党員は公明へ投票させられるという出来レース)　　
続く

続き　日本に借金を抱え込ませたのは小沢一郎（たぶん在日帰化）。

小沢が４３０兆円
村山（旧社会党：この人も帰化？）内閣がプラス２００兆円　
トータル６３０兆円
（詳しくは日米構造協議で検索）

今ある借金は、これとその利息では？

小沢は、自民党時代に日本に爆弾を抱えさせた上に、そのバラマキ公共投資で得た
支持基盤をごっそり自民党から引き抜き（仲間を引き連れ離党）、
自民を単独過半数割れに追い込んだ。
そして、第３極政党（新生党→公明党）を介入させ、韓国や在日へ利益誘導してきた。
日本を借金大国にしたのは自民党だ！と、自分で仕込んだ火種を野党側から
追求する自作自演劇によって、民主党への政権交代につなげた。
※自民党以外の議員は、日本姓を名乗る帰化朝鮮人か、その影響下にあると仮定。

という流れではないでしょうか。

せめてそこはLispじゃなく今最高に輝いてるSwiftさんにしようや＾＾

Swiftはスクリプト言語？

1つの言語やframeworkを作ることで、
どれだけの経済効果が生み出せるかが分かったらヤメラレナイよね

いちおうスクリプト言語みたいに扱える

matzはstreemでも ->(x){} を提案してたけど、誰にも賛同貰えてなくてワロタ

https://github.com/matz/streem/issues/55

逃げよ逃げよ、すべてのジュネーブから逃げ出せ
黄金のサチュルヌは鉄に変わるだろう
巨大な光の反対のものがすべてを絶滅する
その前に大いなる空（天）は前兆を示すだろうが
諸世紀 9章44番

>>11
参加したら優勝決定しちゃうからね（´・ω・｀）
バランス壊すから（´・ω・｀）

Dartもインタプリタだからスクリプト言語だよね。

Swiftのどこがスクリプト言語なの？
標準ライブラリの機能として実行時にコンパイラが使えるってこと？

>標準ライブラリの機能として実行時にコンパイラが使えるってこと？
ならC#はスクリプト言語だな

真面目な話としてCやJavaなんかよりはスクリプト性高いな。
Unityのスクリプトとしても採用されてるし。

>>30
てっきりPythonのことだと思ってた　ワロた

Lispはマイナーでライブラリもしょぼいから
まだ勝負になるんだよ

C#は.NETのオープンソース版が軌道に乗れば
Java喰えるかどうかはともかくGoみたいなのは完全に用済みだな

スクリプト言語を選ばずコンパイラ言語を選択するときの「一番の理由」ってなんだろう？

スピード？
それとも規模の大きさによって判断することが多いんだろうか

>>38
静的型チェックの安心感はそれなりに大きい。 特に複数人数で開発する場合は。
あとは、コンパイル時にインライン化されることを期待して、ちょっとしたラッパーだとか構造体をコストを気にせず使えるところ。

>>38
マジレスすると人材調達の都合
そこそこの規模の開発に土方として参加したことのある人っていうと
必然的にJava土方になる
ある程度の規模になると言語自体の良し悪しと生産性ってあまり関係ないよ

>>40
違うよバカ

実行モジュールの改変しにくさと情報漏えいしにくさが最大の理由だ。
そのために難読化ツールなんてものが存在する。

たとえば３月３日以降は専用ブラウザでの２ちゃんねるのアクセスが禁止になるが、
スクリプト言語や JAVA はソースコードが丸見えになるので禁止されている。

>>39
これはあるよな

>>15
今どき、まともに無名関数が書けないなんてモダンな言語としては問題あるでしょ
javascriptでイベントやコールバックにわんさか使われてるし、
関数型言語としてもいくらでも使い道がある
Java8でも追加されたのに

>>43
そりゃJavaScriptは基本的に外部からのイベントを受けて動く受動的な言語だからな
Pythonは自分でmain書いてバッチ処理などの能動的な処理を行うことが主に想定されている言語だから、
コールバックはそれほど多用しない

無名関数が簡単に使えないのが正しいこととは思わないけどね
非同期なコールバックは仕方ないとしても、Rubyは無意味なコールバックが入り乱れてカオス
それに比べてPythonはライブラリなどがすごく綺麗なのは無名関数が使いにくいお陰なのは確か

Swiftがスクリプト言語というのは、ScalaがLLというのに似た感じ

>>44
大多数の開発者のレベルというか嗜好が変化して、無名関数を使うのが自然なコーディングになったのなら、
それを言語に取り入れるのは当たり前だと思うよ。 できなければ死語になっていくだけ。
Javaも一時は進化を止めてしまって、バカにされていた時代もあったよ。

>>47
今も昔もPythonの用途はバッチ処理がメインでしょ
レベルや嗜好の問題じゃない
いくらWebが流行ろうがバックエンドのバッチ処理が無くなることはないし、
ソフトウェア開発が本業でない人にとってのスクリプト言語の用途なんてほとんどはバッチ処理だ

>>38
業務システムで、他人の書いたfooとbarが何を指してるか分からないし、
少し修正したら気付かないまま大変なことになるから
BootCampはバグが残ったまま走らせても問題ないわけ

ちがった、basecampだ
業務システムや組込みシステムは工業的なんだよ

>>47
代入を含む（つまり、関数内で変数に名前を付けたくなるほど長い）関数には名前を付けましょう
という方針なだけじゃん
変数に名前を付けたいのに関数には名前を付けたく無いとか、そりゃ何の宗教だよ？

それに大抵はコールバック受けてるコードより
ジェネレータを返すコードの方が読みやすい

>>48 >>51
何をそんなに興奮してるのかと思ったら、Pythonを批判されたと勘違いしているのか。
別にPythonはlambdaも書けるし、無名関数が使えない言語だとは思ってないぞ。

まぁ、必ずしもバッチ処理だけではない、もっと汎用的な言語だという認識だし、
一つでも代入をした瞬間「長い関数」扱いになるのは、setXXX()の呼び出しとの差が疑問ではあるが。

＞一つでも代入をした瞬間「長い関数」扱いになるのは、setXXX()の呼び出しとの差が疑問ではあるが。

意味が分かりません

ラムダでsetterを呼び出すのに違和感を感じないなら関数型のセンスないわ

結局、Pythonはインデントを使う構文の関係上、
関数の引数に、（普通に書くと）2行以上に渡るような処理を書かせたくないってことだよ。
代入1個だけなら何とかなったかもしれないけど、「代入と何か」をさせようとすると2行になるから構文的に難しい。
メソッドチェーンならいくつ続いてもOK。
別にsetterに限った話でもないし、イベントやコールバックでsetterを使うのに違和感は感じない。

JSはコールバック地獄とか馬鹿にされてますよ

つpromess, defer
templateならejs以上に効率の良いものないよね

>>55
メソッドチェーンもPythonじゃ殆ど使われないよ。構文的には制限されてないけど
だから可読性に対する考え方の違いなんだよ

本人主義のJSやってるとさ、Pythonのやり方は１つ主義やRubyの可読性なんかの主張が理解しづらい。

>>59
じゃ他人のライブラリも読みにくくて、オープンソースも理解しにくいんだろう

>>60
打ち間違えたｗ
本人→放任　だｗ

なんじゃそりゃーーー！！！

......でもそんなに変わらない

まあ読みにくい、理解し難いってのは確かだろうが、
逆に捉えれば、他人にコードが新たな発見や勉強になるってことだし、
自然のワイルドな状況で全体の「良いJSの書き方」が磨かれて行くのは嫌いじゃない。

コラッ　往生際悪いぞｗ

感覚の違い。
強いて言えば勉強が嫌いでさっさと使いたい人には向いてないのかも。

むしろJSはベストプラクティスとか気にしないで汚いコードでも変なやり方でも
さっさと目的を達成しようとする人に向いてる
神経質な人や真面目な人がこれでいいんだろうかとか気にしだすと泥沼にはまる

謝れ！モダンperlさんに謝れ！

>>66
逆に聞くが何か目的を達成するためにあえてJSを選択するか？
もちろんブラウザの標準言語という点は何より魅力だが、
それは除いて初心者に純粋にNodeとPython、どっちのインストールを進めるかといえば自分は後者だ。
計算科学でPythonがよく使われているのを見ると、やはりPythonが最もやりたかったことを忘れないうちにさっさとコードにできる言語なんだろう。
その点ではやり方に縛りがないというのはプラスにならないからな。

まあ話は変わるが、「深く知る」ということが言語仕様の流れから理解することとすると、
JSの仕様書の多さと読みにくさは問題だと思う。

>>65
冗談のつもりだったが、まさかここまで酷いとはな......

jsは一人ヨガリな奴しか使えない言語って結論で良いか？

>>69
独りよがりな奴しか使いたがらない、じゃね？

>>55
インデントを使う構文な上に、2行以上の無名関数を多用する
CoffeeScriptという言語もあるけどね
結局、不自由な言語で書いてる人は自由な言語の良さが理解できない
Lisperが他の言語を馬鹿にするのと同じ理屈だね

>>69
このスレではいかに業務において使いやすいかより、
いかに俺スゲーできるかが味噌なんだから、
独特でマニアになれる言語仕様ってことは＋なんじゃないの？

>>68
自分はESに仕様書を読み解けるようになるまで１年はかかったね。
でもまだどこもかしこもすんなり読めるって感じじゃない。
そうなるにはもう１年かかると思う。

>>72
そもそもあまり業務において競合してない
分野が分かれてる
Webのサーバーサイドは若干競合し始めているが

JavaやC#以上に使いやすいよね。何処の環境にも入ってるし、
ちょっとバッチ処理を書く分にはOOPなんて理解しなくても良いしさ

>>71
簡単にlambda内で変数束縛できるけど、誰もやらないだけ
できるけど、やらない


ret = next
val = lambda *args: args if len(args) == 1 else (args,)

f = lambda x, y: ret(x + y + a + b + c + d
                     for a in val(x + y)
                     for b in val(10 + a)
                     for c, d in val(a+5, b+3))

>>71
この界隈で自由/不自由と言ったら、オープンソース/プロプライエタリの意味に誤解されそう。

言語の制限という意味の不自由なら、制限がつくことが望まれる場合もあるとは思う。
Pythonは「書きづらいなら、それは書かせたくない書き方だからだ」って散々レスされているし、
ES6はclass構文という不自由を導入したから、独自実装クラスの氾濫を収束させられるんじゃないかな。

>>77
>言語の制限という意味の不自由なら、制限がつくことが望まれる場合もあるとは思う。
>Pythonは「書きづらいなら、それは書かせたくない書き方だからだ」って散々レスされているし、

もしその Python の設計思想/哲学が優れているなら、他の言語も追従していくはず
でも現実には、無名関数の無かった C++/Java/Perl/PHP も使えるように進化してきたし、
新しく登場した C#/Swift といった言語では最初から無名関数を備えている
結局、
　　「Python だけがポツンと一人、関数型プログラミングの世界から取り残されている」
というのが、現在の状況な訳だ

まあ Python 厨からすれば「世界が Python から孤立している」と見えるのかもしれないが....

それは誤解。
class構文はある意味ではただの便利な糖衣構文。
そしてある意味では機能が不足していて従来型との組み合わせが避けられない未完成品。まだES7,８で治していく予定。
JSが不便だったのは制限がなかったからではなく、変な制限がかかっていたから。
その点ES6ではようやくプロトタイプベースが開放されるので、まともなPBOOPができるようになる。
そちらは完成品。

>>78
まともなファーストクラスの関数が無いRubyの方が
よっぽど取り残されてるよ>>16-17

Rubyの無名関数は用意されたものを使う分には優れてるよ
まさに土方をレールに乗せて単純作業をさせるのに最適

Rubyは【楽しさ】を追求した言語だからね
松本神が楽しくないと思う機能は入らない
そこに文句や批判は許されない

ドカタが好き勝手にラムダ使ったりしたらカオスになるのは目に見えてるから、
ブロック引数という形で制限してるのはある意味Pythonのようにスタイルを統一する役割を果たしていて
結果的には良かったのかもしれない
松本神からすれば「楽しくない」となる不本意なところなんだろうけど

それはある意味であって、大多数には不利益をもたらしてると思う。

>>78
関数型といえるほど大した使い方かはともかく、無名関数は一般化してしまった。
だから、それに制限がかかる言語に移ると、使いづらかったり、古臭く見えたりする開発者はいそう。

将来、ジェネレータや async/await が一般化したら、また評価が変わるかもしれない。
ループの内外が入れ替わるだけの場合もあるけど、その書き方が美しいとされる言語もあるだろうし。

それらはJSerにとっては今日明日にも欲しい機能なわけだけど、他の言語界での認識はどうなの？
CGI的な用途だと必要にならないかと思う

>>79
糖衣構文かどうかや、未完成品かどうかは関係ないよ。
よくある静的なクラス構造なら、皆なるべくclass構文を使えってことでしょ？
それはPythonの「たったひとつの冴えたやりかた」を求める姿勢と似たものに見える。
もちろん、開放されるというプロトタイプベースが多用される状況になったら、考えを改めるけど。

>>87
それはなんとも言えないな。
従来型で出来なかったことや難しかったことができるようになるわけじゃないから。
元々はclass構文はクラスを作ることよりも、「ビルドインクラスを正しく継承できない」という問題を解決するものとして注目された。
でもドラフトが更新されて、class構文の特殊性はどんどん削られていって、ほぼただの糖衣構文とかしている。
一方従来型でもsuperやメソッド定義など新しい機能が使えるようになって、表現力は向上しているんだよ。
だから便利に使えるものではあるけれど、「たったひとつの冴えたやりかた」とまでは言えないと思う。

>>86
Pythonにはジェネレータ（とyield）が既にあるし、
async/awaitはデコレータとyieldを使ってライブラリレベルで実装可能って認識

Rubyで非同期やるならreactive programmingの方が馴染みやすいだろうな
なんだかんだC#は影響力凄い

Rubyはつまらないし
技術的負債なんだよなあ

実際はWordPressとRailsしか選択肢なんてないんだよね
WordPressはMVCのframeworkとして形態を取らなかったから小回り効かないし、
CakePHPってコミュニティがRailsと比較すると貧弱なんだよね
かといって、MEANやMeteorには導入・運用したいような出来合いのものもない

WordPressを言語やフレームワークとして取り上げるのをやめろ。
たんなるブログソフトだ。
そうでなくなるには開発者が機能をライブラリ、フレームワークとして分離してからだ。
いまのところ、PHPの実装だがソフトウェアとしてみたとき、perl、Javascript、C言語で実装されても挙動が同じなら同じソフト。
C製の言語がJavaVMやDOTNETで実装されると同じ。

そういえばCSSはいくらか前に変数を獲得したけど、
最近コミュニティが機能拡充に向けてまた盛り上がってきてる。
CSSがスクリプト言語の仲間入りをする日も近い。

wordpressは、何かをする上で、もう立派なプラットフォームだから

>>94
プリプロセッサの類でいいじゃん

>>95
考え方が逆だよ。
プリプロセッサで可能な範囲ならプログラミング言語ではないということだ。

せめて、scssやlessのマニュアルぐらい眺めてからいえよ

海外ガーとか言うけどぶっちゃけお前ら一生国内土方でそ？w
だったら大人しくjsかRubyかSwift、もしくは3つ全部使いこなせれば食うのに困らんしそこそこの小金も稼げる
特にRuby使いは福岡行けば当分安泰

普通に C/C++ で十分だわ
簡単なツールとかだと、C# でいいし

理論的に美しいRxを蹴ってasync/awaitを入れるセンスはさすがC#だわ
これがScalaなら安易に継続モナドとか入れてカオスになるところだけど
モナドのような言語内DSL的なハックはクソであり、自然に言語本体に組み込むべきだ
という一貫した姿勢はPythonにも通じる

SIerの作った簡単なJava,C#のツールならjsの方がマシ

C#いいな〜

さあこれから仕事場のためにVB6の勉強をはじめるか(泣)

>>98
Ruby chanの絵柄の気持ち悪さに日本を感じるよね
whyのfoxやzombieみたく、世界を意識したデザインセンスの欠片も見当たらない

>>97
お前こそ日本語理解してから言えよ。

Perl, python, Ruby がイマイチで低空飛行し続けているのは、たまにキモヲタ臭にやられるから。
寡占目指して技術的な問題を必死に議論する以前に、そもそもそこを取り締まらないとダメだが、単にその言語が使えるだけの馬鹿ばかりだから気付かない。
割と真面目に言っているんだが、多くの人はキモヲタ臭を不真面目さと看做してムッとするわけよ。
Java, PHP, JS といった、寡占経験のある物には、そういうおふざけが皆無だから、ムッとさせられたりはしない。

でもこのスレ本当に言語を愛してる人がだいぶ減った気がする。
その言語をそこそこやってて慣れてる程度の人ばかりに感じる。
例えばその言語で完全なその言語の実行エンジンを作った人が何人いるか？

そういえば Perl と PHP は擁護派も否定派もあまりこのスレには現れないな
Perl はもう古語だから仕方ないが、PHP使いは職業軍人だから良し悪しには拘らないってことか

PHPはもはやVBみたいなもんじゃね。

たしかにphpディス減ったなぁ

技術や言語なんてたかが道具であり、それに過剰に拘る奴は無能
プラットフォームやミドルウェアなどもっと低レベルなところの開発でもやってるんならともかく、
スクリプト使ったWebアプリなんて他人が作ったオモチャで遊んでるだけなのに何職人気取ってるの？

俺達だって道具だしな！

時代が変わったことに気付かずにSOAPやJava,VBなんて触ってる人たちが可哀想で仕方ないよ
職人的なノウハウを貯めこむならコミュニティの支援がある所でないとダメなんだ
今のベストな選択肢がWordPressとRailsだけ
プラットフォームやミドルウェア作りみたいな開発なんてリスキーだし、
何のバックボーンもなしに個人では誰もやれないからね

今Railsがある意味でベストと言うのは、Railsが停滞してるからだよ。
だから世間が追いつけただけ。
昔のRailsは時代に乗っているどころか、時代を作っていくものだった。
BossがRailsを止めたと言うまで完全に終わったわけではないが、
もはや今のRailsに新たな時代を作っていく力は感じられない。
今新しい技術ばかり語ってる人達は、Railsも出始めはそうだったように、
そんなもの業務では使えないと笑われるだろうが、その人達のお陰で未来がある。

Microsoft、クロスプラットフォームのモバイルアプリ開発でJavaを推進
http://itpro.nikkeibp.co.jp/atcl/idg/14/481542/020900074/?mlm

結局本命はいつの時代もJava一択なのね(´・ω・｀)

エンタープライズとサービスは別物として考えたら？
自分で客さえ取ってこれたら、わざわざ古臭い言語を勉強したり、
痴呆予防のリハビリが必要なジジイ共に御布施する必要もないんだけどね

トラスコやん。

半年前に生まれた最高のフレームワークで作ります！
実績はないけど一ヶ月で作れます！
半年後にまたリプレースします！
誰が仕事頼むんだよw

え？そんなアホな営業してるの？マジで？

仕事の数ならPHPがダントツだし、将来性はJSが保証されてるし、もう今さら言うことなくなったんだろう

>>114
Java　-->　JUniversal　-->　C#
Java　-->　JUniversal　-->　C++/Objective C++
Java　-->　j2ojbc　　　　-->　Objective C

C#からまた別の .net 言語に変換できるのかな？

> JUniversalは現時点ではUIをサポートしていない。
> UIはネイティブに作成するという考え方だ。

やっぱそーなんだね。

UI は Web で作った方が手軽かな。
じゃあ JavaScript でやれば変換の手間もいらないかな。
でも部分的な高速化のために、ActiveX が使えるといいかな。
UI の高速化は GPU の支援受ければいいし。

GPUの支援て。
スクリプターはお花畑な発言する。
それがどれだけ大変なことか。

ActiveXって、韓国の銀行系でよく使われてたんだよね。まだ、使われてるの？
silverlighやWPFって言葉を聞かなくなって、もう何年経つのだろう

>>121
ttp://www.slideshare.net/jarrednicholls/javascript-on-the-gpu
君には無理でも、それに取り組む人は世界中に居るよね。

>>115
これエンタープライズだけじゃないんだが？(´・ω・｀)

部分的な高速化と言っても、結局ミリ秒オーダーで終わる処理なら
ネイティブ関数呼び出すオーバーヘッドの方が大きくなる。
実際に最近は実装もセルフホスティングになってきてる。
暗号化とか、文字コード変換とか明らかに重いのはすでにあるし、

もっとネイティブライブラリを開放して欲しい（とくにJS界隈）話なのか
スクリプトで重い処理をしたい（画像処理とか）の話なのか
論点がずれてないか確認したほうがよさそう

特にJSは、ブラウザというサンドボックスの世界だから
ネイティブなら既にあるものを再実装する話になりやすいし、
いかにそれを呼び出すかだけでも大騒ぎになる

emscriptenという便利なものがあるのだよ少年

VB6万歳！

GUIなのにマルチスレッドないVB6万歳！

スクリプトなんぞruby、js、swiftで十分だろjk
センスがあれば大金持ちにもなれる

>>127
GPUの支援の話だったと思うのだが、emscriptenはその効果があるのかい？

そのセンスってビジネスや商売のセンスであって、断じてプログラミングセンスではないけどね

営業を介さない、多重に請け負いに関わり合わないって立派なビジネスセンスだよね

>>130
emscriptenはOpenCL→WebCLもサポートしてるよ。

JSもSharedArrayBufferでようやくマルチスレッドの道を歩み始めた感。

WebCLってホストAPIのJSバインドだけで、カーネルはOpenCL Cそのまま<script>に
埋め込むだけじゃね？
どっちにしろカーネルを自分で書かなきゃならんなら最初からWebCLで書く方が
JS使いには楽だろうな。

>>129
だからswiftはスクリプトではないっしょ

しかも選び方がかなり偏っててかぶってる

同期コストやJavaScriptの遅さを考えると大抵のケースでカーネルの実行時間自体はほぼ無視できるはずだから
GPUの意味はほとんどないだろうね
単にカーネルが静的型で書ける分速いってだけだな
結局それだけならasm.jsの方がよほど筋が良い

GPU支援とは言うけど、デコードやらにCUDAやOpenCL使っても同クラスのCPUと殆ど能力差は無いんだけどね。
結局は余ってる物を活用する程度でしか無いし、千差万別の環境が利用するWebアプリにおいて活かせるのかは疑問。

>>138
特定用途では GPU 支援は CPU よりも威力があるようだ、d.net をみていると

>>138
本気のGPGPUって数日かかるような計算を
Xeon計64コア+Tesla4枚とかでやるからね
次元が違いすぎる

バイオテクノロジーとRubyの奇跡の出会い

おっ急に過疎ったな

GPUって普及モデルだと倍精度がクソ遅いからなあ
>>140みたいなガチな環境でない限りは結局画像関係くらいにしか使えんよ

UI は画像関係だから問題ないけど
なんで UI 以外の計算で GPU を使う話になっちゃったのか分からない。

スクリプト言語でブラウザでも実装する気なの？
そうだとしても今のCPUとJSの速度ならGPU支援に頼らなくても実用的なものできると思うけどね。

UIといっても単純な作業しかGPUでは無理だろう。
VRAMにデータおいちゃうとCPUから直接アクセスできなくなるってのも大きい。

ttp://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx
angular.jsがtypescriptつかいだしたってさ
企業まで乱交紛いにソフトウェアを作りだすおかげで、webはますますエッチになる

相変わらずGoogle先生の一貫性の無さはすごいな
Dart(笑)

Angular2は元々「TypeScript＋アノテーション等」のAtScriptでするということだったろ。
この話はDartとは関係ないよ。Angular.dartは別で開発されてる。
むしろAtScriptが同じくGoogleが推すSoundScriptと被るのが気になる。

DartなんかChromeに入れると言っちゃった手前もう引っ込みつかなくて
名前だけズルズル残してる状態だろ
誰が見てももう終わってる

Goはどう？将来性あるのかな？

あるわけねーだろ

仮に将来性があるとしても、Googleはまたすぐに投げ出して新しいオモチャ作るよ

GoはDocker書くのに使われてるけど
Dartには何も無いよね

ぶっちゃけプログラム言語開発はMSの信頼性には遠く及ばないねggr
まだAppleの方が全然いいし、webに関してもMozillaがセンス上

Googleの言語って目先のことばかりで将来のビジョンがないよね
良く言えばアジャイル的なんだろうけど、プログラミング言語はやり直しが利かないからね

DartVMの開発はV8の高速化にも繋がってるし、SaneScriptにも影響を与えてる。
というかぶっちゃけSoundScriptってDartみたいなもんだろう。

すごいプログラミングを考えた！どうよ？
http://fox.2ch.net/test/read.cgi/poverty/1425651890/

ああ、ばかばかしい。忌々しい。死ぬまでWordPressで十分だな

ケンカはやめて＞＜

何だかんだとiOS開発者にささっと転身した奴等は年収も多く人生謳歌してて、Androidに執着し乗り遅れた漏れ悲惨過ぎてワロエナイ(´；ω；｀)ﾌﾞﾜｯ

死ぬまでWordPressで十分なんて人生やだな〜

はやくバトルロイヤルしなくて済む時代が来て欲しいな（´・ω・｀）

>>163
それは今後もないね
結局のところ適材適所なんだが、視野の狭い一部の人間は「この言語さえやっておけば安泰」と叫び続ける

ソフトウェアに銀の弾丸は決して存在しないし、また視野の狭い人間が消えることも決してないので、
バトルロイヤルはいつでも盛り上がるということ

このスレにとってはいいことだよねｗ

ぶっちゃけ今どきソフトだのスクリプト()だの云々言ってるのは情弱よ？
これからはソフトハード含めたモノづくりの時代
ヒントは微細加工×バイオ

>>164
でも、実際javascriptさえやっておけば安泰だろ

底辺ドカタとして食いつなげれば良いという最低ラインで考えても
JSやっとけば安泰かは微妙なライン

node.jsには、WordPress規模のエコシステムなんて出来ないから
せいぜい業務アプリの簡易版。そんな状態でフロントエンドに力注いでどうするわけ？
WordPressなら導入、運用するだけで済むんだよね。たまにプラグイン作るとかして。

>>164
プログラマの生存戦略？WordPressだけで十分だろ
node.jsでWordPress規模のエコシステムが形成されたら、形成されてから移ればいい

底辺ドカタはWebで買い叩かれるくらいならCOBOLやっとけ
詳細仕様書(笑)を機械的にコードに翻訳するだけの簡単な仕事だ
きっちり定時に帰れて金もそれなりに出る
新しいものを学ぶ必要もない

はぁ？なんで買い叩かれる必要があるんだ。ボレばいい

自分のメインの言語を１つきめたいんですけど何がいいでしょうか

私はiOSアプリ開発からプログラミングをはじめたので、今のメインはObjective-Cです。
研究室の教授にある計算の課題を出されたときは、Objective-Cでやってたんですが、
やはり環境に依存してしまいますし、使い勝手が悪い気がします。

同じように計算の課題をだされたときのために、
もっと汎用性の高い、かつ将来性のある言語を習得したいです。
pythonがいいかなと思ったんですけど、日本語の情報が少ない気がしますし…
何かお勧めを教えていただけないでしょうか？

まず、英語のドキュメントを嫁カス
オマエの数値計算の課題なんて社会に出てから通用するレベルじゃないからな

>>172
っ国産言語Ruby
日本語の情報多数、書籍多数、国/行政の後ろ盾

>>172
決めるな
言語なんか道具だ
目的や環境に合わせてなんでも使えて当たり前

日本語の書籍に頼らざるを獲ない時点で、情報産業に関わるべきじゃないんだ
そもそも、そんな状態じゃ大学生が大学を出ただけの価値のあることなんて出来ないんだ

>>173
いや、英語が読めないとは言ってないっすよ・・・
日本語のほうがとっつきやすいってだけです。
アプリ開発のときはもちろんAppleの公式ドキュメント読んでます。

>>174
ありがとうございます。Rubyで前向きに検討してみます。

今のメインがObjective-Cで汎用性と将来性なら圧倒的にC
スクリプト言語？好きなの使っとけば？

数値計算はアカデミックだとPythonとPerlが多いよ
スクリプトはバッチの制御とテキスト処理にしか使わないと割り切る人はPerl、
なるべくスクリプトで書きたいって人はPython
Rubyは情報専門のキモオタ御用達

Rubyに大して汎用性はないと思うが。
同一マシーンなのにRubyバージョンが違うと動かないとかあるが。
C言語もコンパイラやマシン依存していて非常に小さい基礎部分だけしか一致なし。

数値計算なんて、octave,matlab, Rぐらいしか使わないだろ
Ruby?バカジャネーノ？電通、博報堂の回し者？

>>181
がっつりC書くシミュレーション系だと補助に汎用スクリプトも使うよ
Rubyはまず無いけど

言語環境と拡張モジュールがマルチプラットフォーム化されてて
どのPCでも同じ動作が可能なほうがいいってことだろ?
モバイル、マック、リナックスの状況もくわしくないがPythonとかJavaでは?
あとはC#のマルチプラットフォーム化のmonoやwinapiのマルチプラットフォーム化のwineとかあるがどれだけ使えるか不明。

LLVM用スクリプト言語のjuliaはどうか?


Julia : スクリプト言語最速? 手軽さと速さを求めた科学技術計算向け言語
http://yohshiy.blog.fc2.com/blog-entry-246.html


Julia (プログラミング言語) - Wikipedia
Juliaは、 一般的なプログラミングから高水準の科学計算処理まで対処するよう設計された高水準言語及び動的プログラミング言語。
LLVMコンパイラフレームワークを用いてC言語、C++、Schemeで組まれており、標準ライブラリの殆どは独自に実装した。
実装の最も注目すべき特徴は性能に有り、完全にC言語で最適化されたコンパイル言語分野での優位性が見られる。

企業側はさ、エコシステムを乱したいんだよね
でないと、自分たちのプロダクトが商品にならないから

>>184
＞ 新しい言語はシャアの低さやライブラリーの少なさが気になるところです。

まあでもNode見ても分かるけど、ライブラリはすぐ集まると思うけどな。

そのライブラリやフレームワークって、どの程度の堅牢性なの？
何かあったときに自身でfixできるの？

>>172
自分のやる分野がわからないことには言語を一つに絞るなんて無理無理
プログラミングは「この言語さえできればOK」なんてことは一切ないからね

ということで、
> 自分のメインの言語を１つきめたいんですけど
この発想をやめることが、一番最初にやるべきことだと思うね

「この言語だけはできるからOK」と言ってる奴が本当にその言語できてるのを見たことがないな
本当に一つの言語を理解してれば他の言語も使えるからね

企業に入って首輪を付けて飼い慣らされたいならJava、c++だけど、
身の回りのことを片付けるなら、javascriptだけでいいよ

JavaScriptはブラウザ限定だからね
本当に身の回りのことを片付けたいならPerlがいい

基本書き捨てだけど、必要なことを最小限の労力でできる

ラクダの美学なら、mobileとnode.jsの普及と共にjavascriptがかっさらたよ
今、Web APIやSDKのバインディングにperlが用意されてるのを見たことないんだ

それは片付けたい範囲が違うんだろう
「身の回りのこと」と言うのは人によって違うだろうからね

perlが身の回りなんてサーバ管理ぐらいだろw
行き遅れのジジイ共は、さっさとクタバレよ

JavaScriptという名前の言語が真理ということは間違いないとして、
その言語をいかに良くしていくかに話を絞ったほうが良さそうだな。

やれやれ本当のPerlを知らないだな
明日きてくださいよ。本当のPerlをお教えしますよw

という冗談はおいておくとしても、JavaScriptはバインディングの対象言語としてはまだまだもいいとこだよね
そういう場合に用意されるのは大抵PythonかRuby（あるいはその両方）だし

altJSやES6なんて、ほっとけよ。Good Partsだけでいいから。
そんな知識すら最期には役に立たない。

バインディングならJSは負けてないと思うけど。

jsで何でもできると思ってる奴って視野が狭いだけでしょ

他の言語はできない人が選ぶ言語

コード的にも知識的にも、資産性はTypeScriptが一番だな。
嫌でも使わざるを得ないJSが身に付く + トランスレータの将来性がある。

TypeScriptは吐かれたJSが非常に綺麗なのもポイント
最悪、生成されたJSをベースにしてメンテを続けることができるのはTypeScriptだけ

俺は Ruby 好きだけど人に勧めるなら Python だな。スクリプトでなければ C#
js は他言語からでも、とっつきやすさから、気を付ける所さえわかればすぐできるようになる

正直、たのしんで仕事出来れば何でもいいまである
他人の欲しいものを作り続けるだけじゃモチベーション上がらない

プログラミング全般に興味があっていろんな世界が見てみた人にはJSいいんじゃないの。
Pythonはあくまで必要で選ぶ感じ。どれでも選べる状態では勧めないかな。というのもインデントが特殊すぎるから。

楽しむに重きを置くならRuby1択っしょ

JS: interesting
Ruby: funny

Webドカタの世界しか見えないよJS
それが世界の全てって奴もいるけど

webを極めたいならES6
しかし多分もうwebが復活することは恐らく無いと思うんよ

WebとES6はそんな関係ないし、ES6程度じゃ極めてることにならないと思う。
ES7のObservableはいくらか貢献するかもね。
まあExtensibleWebの流れで行くと、超低水準のAPIでフレームワークを作る人と、
そのフレームワークを使って実際はJSにはあんまり深く嵌らない人に分かれそう。

ttp://www.windows93.net/?#!bytebeat
すごいよね。JavaScriptの連中。
もう自身の限界を悟って、WordPressしか触る気はしないけど。

>>211
なんやこれ？

こんなもの誰が何に使うの？

これがすごいならwindowsもlinuxもすごすぎだし、
アセンブラやC言語の方がはるかにすごいな

こんなのキーとマウスの入力が取れて任意の場所に色塗れたら後は何でも一緒だからな

すごいのはハードとブラウザ(=アセンブラ/C/C++)の進化だよな
やっぱスクリプト言語でブラウザ実装までいかんと

他人が作った基盤の上の、さらに狭い基盤の上で、
既出のものを後追いしてるだけなのが......

確かにCanvasを見たときは、せっかくブラウザがレイアウト処理を実装してくれたのに
そこまで先祖返りするのかよとは思った。

だな

もう、データベースから取ってきた文字列表示するだけじゃ、仕事にならないんだぜ？
ぞっとしない？

Canvasはともかく、WebGLは何に使うんだろう

>>220
ゲームとかFlashアニメっぽいもの

しかしブラウザゲーは未だFlashだしスマホゲーは完全にネイティヴ回帰

あれ？w

Rubyが楽しいとかいうデマ誰が言い始めたのか

>>219
UIとかデザイン的なことを言ってる？

冷静に考えると、WebFrameworkとかで作るものより、
GUIアプリ+ネットワークの方が高機能で速く、使いやすく作れるんだけどね

javascriptがブラウザしかできないと思ってるのはjavascriptの
最近の進化を完全に舐めてる
nodeによるサーバーはもちろん、
Node WebKitやatom shellでデスクトップアプリも作れるし
そもそも、ブラウザアプリがchrome appで凄いことになってきている
もともとWeb作っとけば、モバイルで動いていたけど、今では
nativescriptというものが出てきてモバイルのnativeアプリすら作れるようになった
react nativeというものも近々公開される予定
Googleスプレッドシートのマクロ言語もjavascriptだ
Asem.jsやwebglである程度高度なゲームもできるようになってきた
流行りのAiもディープラーニング実装などが出てきてる
gulpやflightplanなどによるタスク自動化などユーテリティも充実
githubはほとんどjavascript一色だ

javascriptはやばい

恐ろしいのは、これらが現在進行形の最新情報だということだよ
1年前の常識がjavascriptには通用しない
1年前だったらモバイルのネイティブアプリをjavascriptで作れるなんて
言えなかったがここ数ヶ月で言えるようになってきた
進化が恐ろしく早い
早すぎてみんなまだ気づいてないんだよ
javascriptやっとけ
マジで

>>184
Julia を調べてみたけど、なかなか面白いね

Python ユーザに関しては、いずれ julia でも numpy/sicpy に相当する
高度な科学技術計算向けパッケージが登場すると思うけど、そのパッケージのでき次第では、
多くの Python ユーザが一気に julia へなだれ込む可能性がある

Python は手続き型言語として簡潔で優れた設計だけど、
たとえば >>78 で示したように表現力に大きな制約がある
この現状に満足できず、なおかつ科学技術計算向けのスクリプト言語として
たまたま Python を利用しているだけのユーザであれば、Julia はとても魅力的に映るはず
（しかも Julia から Python 関数をコールするパッケージが既に存在する等、相互運用性がある）

Ruby ユーザに関しては、「Ruby による関数型プログラミング」に慣れていれば、
Ruby と似た構文の Julia へ移行する事は難しくないし、いつでも移行できるだろう
とはいえ、今の Ruby と比較した Julia が絶対的に優位なのは高速な実行効率だから、
移行するのは性能が絶対要件である科学技術計算を主に扱う少数の Ruby ユーザにとどまるだろう
また科学技術計算向けには HPC Ruby プロジェクトがあるから、
このプロジェクトの実用化も Ruby から Juia への移行という流れに影響を与えるだろう

そのうちモノになるのがどれぐらいあるというのか…
node.jsですらどんなに贔屓目に見ても「地保を固めつつある段階」だというのに

>>226
wordpress,magentoは既に起きた

>>228
俺の見立てだと、webglはほぼ完全にものになると思う
nativescriptやreact nativeはまだわからないが、
react nativeは既にFacebookが使ってるという意味で、
将来がかなり約束されているように思う
日本にいる限りは確かにWeb土方で終わる可能性もあるが
アメリカではjavascriptエンジニアは平均で年収1000万超えるほど
物凄い高給らしいし、その傾向が少しくらいは日本に波及してくる
可能性もあるとみてる
何にせよ、やっておいて絶対に損はないし、これほど将来が約束された言語は他にないと思う

既にあるOSSのweb applicationってレベルで考えるべきなんだ
個人がjavascriptで作れるものって、せいぜいSPAぐらいだから

>>231
その認識が間違ってる
ゲームもネイティブモバイルアプリもデスクトップアプリも作れる
それに、そもそもSPAでアプリが作れる時代だからな

顧客が作って欲しいものってさ、既に出来てるんだよね。
後は導入、改修、運用するぐらいで。

> 将来がかなり約束されているように思う
node.jsですら出てから数年経ってるというのに「ようやく認められてきたかもね」という状態
しかも、現状は足踏み状態だと断言しても差し支えない状況

君の言う「将来」というのは、10年以上のスパンで見た話じゃないのかい？
だとしたら今すぐ手をつけるのはそういうのに興味がある人達だけで十分だよ

それ以外の人たちは、君の言う将来が現実として見えてきてから手をつければいい
「JavaScriptやっとけ、マジで」は未来には正しい言葉なのかもしれないが、今の状態では
間違いとしか言い様がない。なぜなら他にやるべきことがあるのだろうから

まあ、欠点は進化が早すぎていろんなものが登場しまくって
どんどん入れ替わっていくところかな
例えば、Facebookがreactを発表した途端、reactにインスパイアされた
ライブラリやら既存のフレームワークの新バージョンやらが発表されまくり
世界がガラッと変わってしまった
こういうことが頻繁に起こる

Juliaは良いねぇ…まだWindowsじゃ起動おせぇんだYO!!って投げたけど
Cythonは結局Cソース化してコンパイルしてるし、PyPyはコードによってまちまち
annotationを型チェックだけでなく変数の型にも使ってくれればPythonも速度出せそうだけど

同じLLVMベースのPystonはどうなることか…どれもまだ発展途上か

javascriptは、既にあっちこっちの企業が仲良しこよしでツルンでるけど、
まだ、何も出来てないんだよね。クラウドってインフラを使わせいだけなんだよ

>>234
nodeに関しては、サーバーとしてはそうかもしれない
けれど、フロントエンド開発においては、もう重要なツールの一つではないかな？
だって、gruntやgulpでaltjsやaltcssをコンパイルしながら開発してるところって
多いだろ？
browserifyは言うまでもなく、bowerにしてもlessにしてもnodeだし

>>237
何もできてないっていうか、フロントエンドではほぼ必須だし
むしろ、いろんなものが出てきすぎて困ってる上に、
何でもできるようになりつつある

javascript やるのはいいけど、お勧めのお手本ってあります？

僕としてはチートの手法がほしいんだけど。

フロントエンドっていうけど、何つくるわけ？TODO?カンバン？
顧客は本当に工数かけてまで、そんなもの導入したいの？

>>238
ツールとしてのnode.jpが普及することとJavaScriptやっとけという話とは違うよね
だって、ほとんどJavaScript書かなくてもいいんだから
npmの使い方を覚えればいいだけの話

LinuxのコマンドはCで書かれてるからCを覚えるべき、と言ってるようなもん

(それとは関係はないがC自体は覚えるべき言語であるとは思うけど)

>>240
チートの手法ってのが分からない
ゲームのチートかな？それともクラッキングの手法か何かか
まあ、その手の情報はググってみてくれ

一般的に言えば、フロントエンドのお手本はgithubにあると思う
英語のリソースしかないのが欠点
この分野では日本が遅れているのも、進化が早すぎることによる弊害だと感じる

>>242
まあある程度はそうなんだけど、例えばgulpfile.jsを書こうと思ったら、
結構本格的にjavascriptをやっといた方がいいと思うし、
そういうツールがnode上にあるってことは、やっぱりサーバーとしての採用にも
一役買うだろうし、将来が約束されていると思う一因かなあ

wordpressでも触っとけよ。codex読んでるだけ掛けてる基礎が補完できるから

>>244
gulpfileなんてWeb屋がある程度使うレベルのJavaScriptができれば十分

ブラウザが絡む開発をしてる人間ならJavaScriptからはどうせ逃げられないんだし
（君の言ったツール群もブラウザが絡む開発をしてないと使う場面はないしね）

で、現実としてはその程度のシーンでしかJavaScriptは使われていない
10年スパンで見た将来は知らんけど、そんなのはそのときに考えればいい
今の時点でJavaScript万能説は草�gダンス万能説と同じでネタでしかない

>>245
wordpressのようなものも有力ではあるし、Web開発では日本では今でも優勢だと思うが
javascriptほどの万能性と将来性はやっぱり感じないかなあ
javascriptほどのスピードと熱を感じない

フロントエンドに特化したオモチャ作るならともかく
LAMPの基礎さえ怪しそうな連中がnode.jsなんて触ってどうするわけ？

>>246
ブラウザが絡む仕事というのは、それだけで今現在一大分野だと思うけどね
その分野でjavascriptからは逃げられないというだけでも、大きな理由でしょう
ブラウザが絡まないとでてこないというのも厳密には間違いで
altjsでコンパイルする場面というのは、デスクトップアプリやモバイルアプリでも
出てきてるわけで
確かにブラウザ以外、現状あまり採用されてないというのはあるけど
例えば、1年後や2年後には状況がガラッと変わっていると思うほどではある
2年前、nodeは存在していたけど、Web開発で広くツールとして採用されるという
ここまでの状況では全然なかった

> 例えば、1年後や2年後には状況がガラッと変わっていると思うほどではある
だったら状況が変わってからやればいいだけの話
変わってないのに手を出すのはただの新しもの好き

そういう人間にJavaScriptを薦めるなら理解できるが、君の言いようは普及もしてないものを
「これから普及しますから」と詐欺まがいのセールスをやってる太陽光パネルの営業（うちにもよく来るわ）
と何ら変わらん

すごく小さなツールしか作れないし、それならPHPで十分だよね
フロントエンドなんて飾りです。偉い人には、それが（ry

>>250
いや、1年後と比べて状況がガラッと変わっていない現状でも
1年前と比べてガラッと変わってるわけよ
しかも、今の状況でもjavascriptは一大分野であって、
多くの人にとって手を出して得になる分野ではあるわけ

ただし、現状javascriptはホットすぎていろんなツールや方法論が
乱立しすぎて学習コストが半端じゃない
一言で言って学習が難しい
そういう意味では落ち着くまで待つというのは一つの選択肢なのは
認めるけどね
でも、早めに学習しておいたほうがいいという考え方もまたある

yeoman、angular, expressしかないから

>>228
ほんこれ

>>252
ブラウザ上で動く言語してのデファクトスタンダードはすでに確立されている
ブラウザ上の開発をやる人間にとっては覚えるべきというか覚えなくては何もできない
これについて異論を唱える人間はいないだろう
しかし、現状はそれ以上でもそれ以下でもない

>>251
例えば俺はatomエディタが物凄く小さなツールには見えないし、
作ろうと思えば大きなツールも作れると思うよ
他の言語と同じ
>>253
Yeomanって、bower、grunt、yoで構成されてるし、bowerじゃなくてbrowserify、gruntじゃなくて
gulpとか、yoのgeneratorからじゃなくて、Google Web starter kitやangular seedから
はじめたりとか
angularは2.0全く別のフレームワークに生まれ変わるとかreactも注目されてきてるとか
expressも開発チームはkoaに移ったりとかしてるし
そういうふうにね、ちょっとキャッチアップを怠るとすぐに古い情報になっちゃうわけよ

jsって言うけど、jqueryでちょこちょこやるだけと、prototypeから弄るのじゃ別物だから

>>256
どこのアホがReactで書かれたものを保守するんだw
2.0なんて、当分は使われないし、koaなんて誰も使わないから

全部既にあるもので、しかも本格的に作れない半端ばかり

ブラウザがOSに取って変わるわけでもなし

キミがもっと高度な物を作ろうとしたなら、jsを選ばないと思うけどね

>>255
どうだろう
モバイルアプリでも結構な割合がjavascriptじゃないかと思うんだが
ネイティブじゃないにしても、ハイブリッドは多いだろう
そんで、モバイルとブラウザが昔より重要になってきてるから
それ以下でもそれ以上でもないという状況も昔と意味が違う

>>259
飯のためにjsのであって、高度なものは言語に左右されない

>>258
angular保守するより、react保守する方が明らかに簡単だと思うんだが
2.0は当分先だろうけど、それでもぶっちゃけ1年後には出てるんじゃないかな
koaにしても、分からんよ
進化が早すぎてまじ読めない

>>260
それはブラウザの立場が変わっただけであって、JavaScriptがブラウザ上で動かすための言語であるという
部分には何の変化も加わっていない

ブラウザ上の言語としてJavaScriptは非常に重要であり、代替がきかないものであるが、それ以上でも
それ以下でもないことは変わっていない

>>262
Reactのfolk数ひくいから触ったこともなかったわ。
Atomも、もうReactなんて使わないでVanillaJSだろ。たしか。

>>263
何度も言うけど、それ自体が疑問
今はブラウザの枠を飛び越えてる最中だし、
昔はjspやらphpでもっとサーバーサイドに比重があったよ
そして、仮にその枠を飛びこえていないにしてもブラウザ自体の重要性が変われば、
javascriptの重要性も変わってくるだろ
どの言語をやるかという話をしてるわけなんだから

>>265
飛び越えてる最中って、node.jsが何年もかかって、現状のザマなんですが
飛び越えようとしてるけど停滞してる、というのが妥当な評価かと

>>263
このバカ、基本情報試験でプログロミングでも覚えたのか？

>>264
folk数だいぶ増えてるよ
というか、folkもいいけどstar注目しといた方がいい
angular以上の勢いで増えてるから
なんだかんだでフロントエンドのViewに関わるライブラリとしては
angular、backboneに次いで今3位なんだよね

>>266
nodeの開発は停滞しているけど、nodeのツールとしての採用が停滞してるようには見えない
というか、現状で既に広く採用されてるし、javascriptの有名なライブラリはもうほとんど
npm上にある
そうした環境としてはもうデファクトスタンダードだろ

面倒だから知りたくもないんだけど、
ReactでもAngularみたく既存のライブラリをモジュール化できるわけ？

>>270
モジュール化にもいろいろあって、javaのパッケージシステムのようなものを
イメージしているのであれば、単体では出来ない
ただし、多数派はbrowserifyやrequirejsなどと組み合わせてモジュール化するんだろうね
もし、モジュール化がコンポーネントを作ってカプセル化するという意味なら
まあ、viewの単位でそれをするのがreactだって感じ

>>269
それはツールとしてのnode.jsであって、その時点でJavaScriptを書く必要がある人間は
そのツールの開発者だよね、というのはもう指摘した話なんですけど
しかも、そのツールたちはブラウザ上のJavaScriptを管理するためのものでしかないし

結局のところブラウザ上の言語としてのJavaScript、という範疇は一切超えていない、と

>>272
それも厳密に言えば間違えていて、採用率が低いだけだよねというのは話した
だから、今飛び越えているところだと表現した
そして、ブラウザでの採用率から考えて、飛び越えるだろうという予想は妥当と思う

TYPESCRIPTやES6のようなaltjsを(es6はaltjsじゃないかもしれないが)使って
モジュール化するという方法も考えられるね
es6を使うという選択肢も、1年前は無かったかなあ
babelのような素晴らしいトランスパイラーが出てきたのは最近だからね

>>273
> 採用率が低いだけ
> 飛び越えるだろうという予想
こういう文言が太陽光パネルのうざい営業たちの文句とそっくりなんだよ

まず、飛び越えてから、その話をしようよ
飛び越えてもない状態で、飛び越えた後の話をしないでくれよ

根拠のない（というと君はどうせ的はずれな根拠を出してくるんだろうけど）予想に基づいた未来なんて
要らないんだよ
ましてその根拠のない未来に基づいたJavaScript万能説なんて詐欺でしかないんだよ

>>271
angular.module([],[])のようなものをイメージしてるんだけど、
Reactには似たような機能は既に用意されてるの？

>>275
詐欺だと言われても、最初から予想だと言ってるじゃんw
ちなみに今でも枠を少し飛び越えてるしな
ここは程度の問題でいろんな意見があろうが、少なくとも、全く飛び越えてないというのは違う
それに、枠を飛び越えなくても今でも十分すぎるほど万能だと思うんだが
ブラウザが昔と比べて万能になってきているのだから
>>276
ない
ただ、altjsとか、javascript次期バージョン自体の機能や、node、
他ライブラリにはあるのでそいつらと組み合わせて使う
これはどちらがいいかは意見が分かれるだろうね

fullcalendarやbootstrapを誰かが勝手にモジュール化してくれる
Angularコミュニティに参加して良かったと思う

>>277
とりあえずJavaScript万能説は取り下げてくれたようなので、俺はそれで満足だ

>>278
確かにangularのコミュニティーは大きくて素晴らしい
ただ、Fullcalendarは知らんが、bootstrapならreact−bootstrapはあるな
しかし、bootstrapも実は急速に注目を失いかけている
今はmaterial designだ
angularならangular-material、reactならui-materialだな
こういうところも、1年前と全く違う
reactがどこまで伸びるのか、はたまた他のライブラリが台頭するのか
全然読めない
困ったもんだ

>>279
いや、取り下げてないよ
これほど万能な言語は珍しい

>>280
そんなものは学習コストに見合わないから、最初に触ったものだけで良いだろ

>>282
そう言われても、世間がそれを許してくれないんだよ
最初に学んだのがjquery uiだからそれだけ使ってればいいだろう
と言ってもbootstrapやangularが出てきてそうは問屋がおろさなかったわけ
これは確かに大きな欠点
学習コストは現状は高い
でも、以外と既存の知識があればなんとかなるもんだけどね
angularのこれはreactのこれに当たるとかね

>>281
ブラウザの上で動かす、というレベルでは万能だと君は言っている
それ以外だとnode.jsのサーバ化は失敗もいいところだし、ツールとしてはユーザが意識する必要はないのも認めている

ブラウザ上の言語としてのJavaScriptは他に選択肢がないのは事実だし、それ以外の分野でユーザが書く必要はない
つまり、ブラウザ上の言語としてJavaScriptを書ければ大多数の人間にとっては十分ということだ

将来？将来の話は将来にしよう
どうなるかわからない将来の話を元にJavaScript万能説を唱えるのは詐欺でしかない

googleさんなら2.0以降でVDOMを取り込んでくれるよ

>>284
だから、何度も言ってるけど、ブラウザ自体がかなり万能だと
モバイルでも動くし、chrome appのように従来のデスクトップアプリのようなものも
ある
ゲームも出てきた
デスクトップアプリの代表のような存在だったofficeだって
Google docsとかスプレッドシートがあるだろう
この時点で万能だという説は成立すると思う

あとは枝葉末節だが、ブラウザ以外では、今は採用率は低いと認めざるを得ない。
しかし、ツールとしてのnodeはやってることはコマンドラインツールであって
ブラウザとは厳密には違う
やろうと思えば今ではモバイルのネイティブアプリもデスクトップアプリも作れる
「予想として」今後こういうシーンでの採用も増えるだろう

node.jsってもうc10k問題の特効薬みたいに言われてるけど、どうなの？

>>286
> だから、何度も言ってるけど、ブラウザ自体がかなり万能だと
別にそこは否定しないよ
ブラウザの使うシーンが増えることでJavaScriptが使われるシーンが増えるだろうね
ブラウザ上のJavaScriptフレームワークは百花繚乱だし、いいことだと思うよ

> やろうと思えば今ではモバイルのネイティブアプリもデスクトップアプリも作れる
作れるということとJavaScriptを（ブラウザ言語として以外で)覚えるべきということとは
まったく違うレベルのお話だよね
デスクトップアプリとしてのJavaScriptはひよっ子もいいところだし、その分野の言語として
JavaScriptを覚えるべきというのは(現状では)まったくありえない論理であるのは確実だ

つまり、ブラウザ上の言語としてJavaScriptを薦めるのはまったくもって正当であり、
逆にそれ以外の言語を薦めてるとしたら頭がおかしいとしか思えない
逆にブラウザ以外の言語としてJavaScriptをすすめてるならそれも頭がおかしいとしか
思えない。これが結論だね

ブラウザは既にJVM、CLR以上に万能な仮想環境だよ
そのまま、OSとしてスマートフォンに載るぐらい
おまえらのアホな長文とは裏腹に、これが現実。

>>288
そうでもないと思う。
ブラウザ以外の一大分野であるモバイルアプリで採用率はかなり高いと思う
objective-cやjava、将来的にはswiftほどじゃないにしても、その次くらいじゃないかな
デスクトップアプリもMicrosoftで採用されたし、多くはブラウザアプリと似てる
頭がおかしいとまでは言えない

「やろうと思えば」ってｗ

もともと他言語で実際やってたことを今までjsではできなかった

jsでできるようになって「自分にもできるようになったよ！」と喜んだ？

みんながWeb出身だとでも思ってるの？

>>289
だから、ブラウザ上の言語としてのJavaScriptについては何も否定してないよ

それをネイティブアプリとかそっち方面にまで話を広げようとするからおかしなことになってるだけで

>>291
jsでネイティブアプリ制作できるツールが出来てんだよ
で、その他言語ってプラットフォームに依存まみれなわけ
JVMやCLRの中間言語なんて誰も読みたくなかったし、
c++のコンパイルを悠長に待ってられなかったんだろうね

>>292
モバイルのこと？
ネイティブはともかく、ハイブリッドは結構あると思うぞ

jsが歴史的背景とブラウザベンダーに依存まみれで、スクリプト言語の構文としてイマイチなまま

選択肢が一つ増えたことはいいことだが、今の時点でこれまでのものと同等の質に作れるのか？

RとかLuaとかC#とか、それぞれの分野にあった良い言語があるわけで、どんなものを作りたいかに
よって適宜選べばよい
jsはたいしたものを作らなくてもよい場合に選ぶ言語

javascriptには細かいミスがたくさんあるのは事実なんだけど、
意外とそういうのはスタイルガイドなり、ツールなりaltjsなり、対処方法が結構ある

その上に、objectがstringをkeyとするmapで表せる点(それによってjson記法が普及した)と、
クロージャと無名関数、イベントループ式のイベント処理を備えていたのは大きくて、
それによって多くの用途で十分な言語になったのだと思う

簡潔な記法(json)、柔軟な抽象化(無名関数)、
簡単な非同期処理(シングルスレッド式のイベント処理)が揃った稀有な言語だったんだね

匿名関数な。無名と言い出した馬鹿はどこの誰だ？

IE5の時にasyncをfalseに出来た事がむしろ革命的だった。それまでは何もかもがロード待ちのイベントドリブンだった。

つうか、IE5の時にmsdnにhttpsocket実装した数千行のJSあっただろ、あれ保存している人がいたら、欲しいな、今のサーバーJSと比べたいから。
JSの歴史なんて剽窃の歴史。

Ie5の時代は、まだjavascriptの真の力は発見されていなくて、
今のような本格的な使われ方ではなかったように思う
Json、promiseが出てくるにつれてさらに本格的に使われだしたように思う

まともな物を作るならネイティヴはコンパイラ言語じゃないとね。JSは遅いしソースも抜かれるんじゃないの？

対処方法とかいちいち余分な手間は増やさなくていい

JavaScriptのミスって言ったら作者も認めてる、
グローバルスコープに容易に変数が定義できてしまう点くらいだと思う。
で、それはstrictmodeで防げるんだから大丈夫。

>>301
確かにその辺の懸念はあるね
どんな言語でもマシン語や中間コード解析されたら終わりだけど

>>302
まあスタイルガイド(コーディング規約)とかツールとか、新たな言語仕様を余計に覚えるとか
どの言語でも必要な事が多いけどね

>>303
細かいこというと、演算子による型の自動変換の振る舞いとか、
特に二重イコールの動作とか、thisの細かい振る舞いとか
withの振る舞いとか
いろいろ危険とされてる仕様はある
まあぶっちゃけ、回避はできることがほとんどではあるが

>>304
それはミスではなくてあくまで選択、特徴だと思う。
withだってProxyと組み合わせて面白いことができたりするし。

>>305
Withで指定したobjectの中に、withの中で左辺値として指定しようとした
propertyが定義されてないときの振る舞いの事ね
てか、strictモード使うんじゃなかったのかw

>>306
その振る舞いは妥当だよ。
特に関数スコープvarだけの世界だったJSにおいてあれ以外の振る舞いをさせようがない。
だから設計はミスではないし、だからと言って存在自体がミスと言えるほどだとは思わない。
strictmodeで禁止なのは必須の構文ではないのとパフォーマンスへの影響部分が大きい。

LuaはJavaScriptのミス修正版だから仕様を見てみるといいよ。
インデックスが1から始まるところだけはいただけないが。

>>307
でも存在自体がミスだった(より有用な別の仕組みが良かった)と
思ってる人は多いと思うけどね
こればっかりは、多いと思うとしか言えないんで
平行線なのは分かるけど

でも、結局のところ悪いとされてる使い方をしないというだけで
回避できるんだよね
それは結構簡単でコーディング規約に書いてあったりlintが
教えてくれたりする
他の言語でもそのくらいはするだろ

少なくともwith文という形であれ以外の挙動はさせようがないだろ。
エラーにするのはおかしいし、具体的にどんな挙動だったらよかったんだ？

Dartの..みたいなのがあれば良いということなら分かるが、with文の否定にはならない。

もう分かった分かった
Ruby、Swift、C#にjsも加えてやるよ

（´・ω・｀）人（´・ω・｀）ナカーマ

そこまで入れるならGoも入れてくれよ

>>98
> 特にRuby使いは福岡行けば当分安泰

朴槿恵 「大使斬りつけ事件はむしろ韓米関係を近づける機会になった。あと私も昔顔を斬られた」　 [転載禁止](c)2ch.net
ttp://hayabusa3.2ch.net/test/read.cgi/news/1425878976/
> 232 名前： ジャンピングDDT(福岡県)＠転載は禁止[] 投稿日：2015/03/09(月) 16:18:49.29 ID:VzGh6Ta00
> 　おまえらは米韓関係が良くなることがそんなに怖いのかｗｗ


福岡は地獄だと思う。

>>243
ゲームのチートですね。

せっかくゲームが javascript で書かれていてデバッグ環境も標準装備されているのに、
変数の値を見たりもできるのに、
自分のチートコードによってそれらを操縦する方法がわからなくて。

特にわからないのが、Click 操作がどう制御されているのか・・・
HTMLなら OnClick とかの関数名が書いてあるのに、
動的レイアウトではそういうのがどこに書いてあるのかわからなくて。

>>315
sinatraをforkしたframeworkとか使ってそうだよね。Rubyistたちの心の闇は深い

>>311
だからwith自体が間違いだったということ
具体的には、全くなくなるか、便利な機能だけ代替できる
別の構文で良かったんじゃないの
それ以上具体的にはどうやるかは知らんが
そのdartの..とやらもいいのかもな

ではもうCとか含めてプログラミング言語全部でバトルロイヤルしよう（＾ｏ＾）
そもそもなんでスクリプト(限定)バトルロイヤルなんだっけ（＾ｏ＾）？

>>319
コンパイル言語では C言語が完璧すぎて議論にならないからだろ。

>>319
コンパイル言語使うような奴はこんな不毛な争いはしないから

>>318
Dartの..はごく一部の用途にしか使えないし、
withのスコープへの介入できる機能はけして代替できない。
逆に、Dartの..で済むような用途にはwithは味がありすぎるというだけ。
withはメタプロの方面で活躍させればいいし、必要。

>>320
C言語は当時としては良い言語だったが
今となっては完璧とは言い難いよ

じゃ今Cより完璧なものって何さ？

Cと同等のポータビリティとモダンな文法をもち低レイヤーへのアクセスが容易な言語でしょう

それなんてjavascript?

>>325
だから何よ？

だから、javascriptだって。
javascript、assemblerでググれば企業やLLCが作ったツールぐらい出てくるだろ

Rust, ATS2

NimなんかはCのコードにコンパイルされるので
Cの出来ることを包含している、かつ、モダンな言語仕様と言って良いかと

Rustはポータビリティの面で劣るけど、そこを気にしないならCに勝る
llvmベースだから将来的にはポータビリティ高まるだろうし

>>324
C#、と言うか普及率で見てもC++でしょ
但しC++もC言語の負債を引き継いじゃってるから
D言語とかの「より完璧なシステム言語を目指すプロジェクト」も動いてるワケで
(C#は言語としては良くても、システム言語としては決して良い立場には立てない)

×普及率で見ても
◯システム書ける言語同士の普及率で見ても

ははっはっwwまじ参ったわwww
アップルがとうとうオープンソースフレームワークReserchKit発表しやがったわwww
いつかいつかと待ち望んたがやっぱり医療データ革命も最初はアップルかwwww
これからのイノベーションの源泉はテクノロジー×オープンソース×生物学(生命科学)から生まれライフを劇的に変えていくが、
俺は貧乏臭いチマチマとした土方スクリプターは卒業して、在野の科学者としてＤＩＹラボで生物学をハックする生命科学の最前線を進む道を選ぼうと去年から模索してた
そして今日深夜未明にこれだよwwwwっアップルwww
去年入院した時に肌で感じた医療の素晴らしさ、そしてだからこそ医療現場の最前線に少しでも助力出来ればと思ったあの日あのベッドの上
この思いを描いた目標をSwift×ReserchKitで早々に実現出来そうだ...
もう30半ばの中年だがこれで何かしらの成果物が出来たら、お世話になったあの看護師さんに思い切って会いに行こうと思っている

>>331
C++はある意味完璧だね
使いこなせさえすれば、の話だけど
そこのハードルが異常に高いんだよね

CもC++もダメだろ。普及してるから優れてるとは限らない。
元から優れてるなら、C++やその改訂版は出てこないはずだ。

C99 は改悪にしか思えない

>>333
iPod,iTunesでデジタル音楽革命、iPhone,AppStoreで携帯電話を再定義

次はiPhone,AppleWach,ReserchKitでデジタルヘルス医療革命か
このデジタル医療革命のキーはオープンソースなのは言うまでもなくアップルもこの辺りは流石に理解してるみたいだな
先日の安部発表によるアップルみなとみらい研究拠点設置といいやはり次の重要ターゲットはhealth分野か

恐らくSwiftもオープン、、、

黙ってSwift習熟に専念するは＾＾

Research kitなんてもんが出たのが
よくわからんが、頑張って癌が治るようにしてほしい

>>335
C++はダメだけど、Cは、特にC89になる前のCは神だよ？(´･ω･｀)

SwiftってlinuxとかWindowsでは使えないの？

じゃダメじゃん

>>340
そこは全く重要じゃない
重要なのは大きい市場と需要があるかどうかだけ
幸いSwift(obj-c)の先に在る市場はとてつもなく大きい、そして世界最高レベルの需要者たちが在り我々はそこに最高のプレゼンスを届けるだけ

恐らくプログラミング言語中最大の市場規模ではなかろうか

よく分からんけどすごそう！

おお！ことばの意味はわからんがとにかくすごい自信だ！

C++こそイディオムやベストプラクティスに頼らないと使い物にならないだろ
JSどころではない

結構分かってるじゃんお前ら！ならさっさとSwiftに専念することだな
在野の科学者として生物学学び直しつつトランスクリプトームの研究にRとRuby使ってたが、今日からiOSをプラットフォームにHealthKit×ReserchKit×Swiftも新たに加わった

PHPにオブジェクト指向をいれたようたフェイスブックの言語は?
ハックだったか。

PHPはもとからオブジェクト指向は取り入れてたな。ハックの特徴まちがえた。

Linuxで使えないのは困るな

でスクリプトのスレではなくなったということでＯＫ？

>>339
当時は神だった、の間違いだろ

そのうちJavaScriptで'use swift'ってできるようになるだろう。

そんなの要らんし出来るようになったとしてもiOSプラットフォームやReserchKit上でそんな糞遅いの使うかって話

×Reserch
○Research

本当に遅いかはおいておいて、速度でSwiftを選んでる奴はいないということだけは確か。

市場、市場っていうけど、
そこらの零細企業や個人事業者にでも自転車のタイヤを取り替える価格で
WordPressなりSurgerCRMなり導入するだけで良いよね

Pythonにまともなラムダはいつ導入されるの？
他の言語がどんどんラムダ取り入れてて、C++ですら導入しているというのに。
文法を拡張してラムダを導入することは簡単なんだろうが、
「代入があると外部スコープの変数
　参照だけならローカルスコープの変数
　ただし、nonlocal指定なら外部スコープの変数」
っていう糞仕様が牙をむき始めるから安易に導入できない・・・。

外の変数書き換えるようなラムダがまともなラムダ?
そんなトチ狂ったことを抜かす奴は関数型言語の一つでも覚えたほうがいい

　ヾヽヽ 　　　　　＿　＿　　　　､､
　(,, ・∀・） 　１　 丶|丶|　　ー-,　　-千-　__ 　 ヽ 　 　　|
　 ミ＿ノ 　　┴　./､|/､|　　　（　　　 ﾉ　　___|__　__ノ 　　ｏ
　　″″

　ヾヽヽ 　　 ヾヽヽ　　　　　　　＿　＿　　　　､､
　(,, ・∀・）　(,, ・∀・） 　⌒，　 丶| 丶|　　ー-,　　-千-　__ 　　-千-　__ 　 ヽ 　 　　| 　|
　 ミ＿ノ 　　 ミ＿ノ　　／ 　 　/､| /､|　　　（　　　 ﾉ　　___|__　　ﾉ　　___|__　__ノ 　　ｏ　ｏ
　　″″ 　　　″″　　￣￣

　ヾヽヽ 　　 ヾヽヽ　　　ヾヽヽ　　　　　＿　＿
　(,, ・∀・）　(,, ・∀・） (,, ・∀・） 　⌒， 丶| 丶|　　ソ　フ_　ニ　.|　十``
　 ミ＿ノ 　　 ミ＿ノ 　　ミ＿ノ　　￣）. /､| /､|　　て　´__)　ん　しα
　　″″ 　　　″″　　　″″　　￣

　　　　　　　.,,_　　_,,=-､
　　　　　 　'､ ￣_　　_.,!　__　　　　　　 .r-,.　　＿　　 r −､
　　　　　　_/　 _!」 .└ ､(　`┐　　　.,,=! └,　!､　.ヽ　ヽ　 丿
　　　　　.（.　　　　 ┌-'(　ヽ~ ,.-┐ `┐ .r'　　r.､''"　r' .／
　　　　　　゛,ﾌ　.,.　 |　　 ｀j .｀" .,/　.r'"　ヽ　　| .l　　'､ヽ、
　　　　 ,,-.'　 , 〈.|　 |　　i'　.__i'"　 .（ .､i　.{,＿ノ　ヽ　 ヽ　＼
　　､_ﾆ-一''~ ヽ　　 |　　＼＿`i　　 丶,,,,､　　　　　}　　ヽ_丿
　　　　　　　　 ヽ__,/　　　　　　　　　　　　~''''''''''''″

>>356
外の変数を書き換えられなかったらクロージャにならんから存在意義がない。

>>358
クロージャなら同意
>>355はラムダと言っている

JavaScript - 偉大なコーダーが推奨技術書まとめ
http://qiita.com/k--kato/items/0514f781def642980a29?utm_source=Qiita%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9&utm_campaign=a349fbe9d6-Qiita_newsletter_146_03_11_2015&utm_medium=email&utm_term=0_e44feaa081-a349fbe9d6-32912021

そういえばアスキードワンゴが新しくThe Art of Computer Programming日本語版を春に再販するとか言ってたけどどうなんだんだろ？

プログラミングの本、それも硬いものを日本語版で出版するってのがナンセンス
それらをしっかりと読みこなせるような層って、原著のまま読めるだろうし
どこぞのミーハーが棚の肥やしにでもするんだろ