トップページ⇒tech
1001コメント326KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2015/02/28(土) 00:33:07.88ID:6Lhyreb3
前スレ
【Python】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ47【pl,rb,php,js】
http://peace.2ch.net/test/read.cgi/tech/1417333026
0657デフォルトの名無しさん2015/04/07(火) 21:02:42.18ID:JncqmOow
>>656
無名関数の扱いに関してはその中じゃjsが一番まとも
0658デフォルトの名無しさん2015/04/07(火) 21:46:15.70ID:ybH01qJK
しかも、ES6のアロー関数などでjsはさらに簡潔にかけるようになる
仕様は肥大化するけど、実際にベストプラクティスとして使われる部分は
入れ替わって肥大化しないしバッドノウハウも不要になって
むしろ実質的に簡潔になると思う
0659デフォルトの名無しさん2015/04/07(火) 21:54:32.20ID:WdIlWePY
今でもtypescriptでアロー使えるし
なによりインテリセンス気持ちいい
0660デフォルトの名無しさん2015/04/07(火) 22:20:37.79ID:KgkX2Lqd
ES6で一通り欲しかった機能は実現される
型が欲しいならTypeScriptもいいかも
スクリプト言語はJSだけでいい
0661デフォルトの名無しさん2015/04/07(火) 22:31:09.63ID:oxNKb4WX
tiobeのrank。Rubyはf#やperlにすら負けてるね
0662デフォルトの名無しさん2015/04/07(火) 23:07:27.23ID:c1nb8jwP
>>655
悪いがjsほどシンプルイズベストとから遠いものはない
0663デフォルトの名無しさん2015/04/07(火) 23:08:12.12ID:pcXxBfoS
>>662
禿同
0664デフォルトの名無しさん2015/04/07(火) 23:12:03.78ID:zhYZjedr
俺がJSでアロー関数は使う理由は簡潔に書けるからではなくーーというか特に簡潔に書けるわけでもなくーーミーハー気分からでしかない。
0665デフォルトの名無しさん2015/04/07(火) 23:29:44.94ID:ybH01qJK
シンプルイズベストからそんなに遠いとも思わないけどね
ScalaとかC++ほど肥大化してるわけでもなく、
バッドパーツは使われてないから、意識しなくてもいいし
jsonはxmlほど複雑とも思わない
あとアローについては少なくともfunctionが=>になって、returnという単語が無くなるから、
客観的に明らかに文字数が少なく、簡潔と言わざるを得ない
0666デフォルトの名無しさん2015/04/07(火) 23:42:37.38ID:oxNKb4WX
PHPのarray()が、ずっと気持ちわるかった
0667デフォルトの名無しさん2015/04/07(火) 23:46:02.21ID:OkADpsKf
何かの言語で統一しなければいけないと思うんだよね。

誰なのこんな馬鹿なコンピューターサイエンスなんて作ったやつ
0668デフォルトの名無しさん2015/04/07(火) 23:49:12.14ID:WdIlWePY
>>662
具体的にjsのどこが複雑でbadなの？
0669デフォルトの名無しさん2015/04/08(水) 00:58:25.59ID:5zTvLXHe
計算機科学はずっと、ALGOLとlispだと思うけど
0670デフォルトの名無しさん2015/04/08(水) 05:01:15.99ID:zFC/xPHH
これからのJSが簡潔かと言うと微妙だな。だって仕様書は抽象的で読みにくくしかも多言語より大きいし。（ES6）

JSは互換性を保ってる言語として、極めてスマートだとは思う。
Webの言語だったこともあって、今回のES6,7でいろいろ追加されるまでなんと20年、
JSの進化が模索されだしてからでも10年はかけられたのだから、後悔の少ないベストに近い汚くない拡張になったと思ってる。

そしてWebではExtensibleWebが注目を集めていたり、世の中が専用APIではなく低レベルからの解決を目指す動きになってきて、
それはJSの策定にも良い影響を与えていると思う。
例えばコレ
https://github.com/rwaldron/tc39-notes/blob/master/es6/2015-03/Composition%20Functions.pdf
もし仕様策定を急いでasync/awaitを入れてたりしたら後からこれを入れるのは大変になっていたところだけど、
やっぱり時間を掛けるってのは大切だと思ったね。

まあES7以降でこういうのとか、演算子オーバーロードとかいろいろ入って、
それこそGoogle提案の静的型付クラスベースmodeの動向も見てから、JSがスマートかどうか見極めたいね。
Webのアセンブリには着実に近づいて言ってるのは確か。
0671デフォルトの名無しさん2015/04/08(水) 07:08:32.85ID:j3bjzkVr
仕様書が抽象的で読みにくいのは、覚えなくてもいいような細かいことが
正確にたくさん書いてあるだけで、プログラマがLintに則って良い作法で使う
部分に限定すれば、それほど複雑ではないと思う
たとえば、==はとても複雑だが、同じ型同士を比較する分には
それを覚えなくてもいいし、良い作法とされているように、===を
好んで使ったりしていれば==はほとんどの場合使わないだろう
そういうものが多いと思う
0672デフォルトの名無しさん2015/04/08(水) 07:21:53.08ID:j3bjzkVr
ちなみに仕様書ページ数
ES 5.1・・・245
ES 6 RC4・・・593
TypeScript 1.4・・・154
Scala 2.9・・・183
Java 8・・・768
C++(n4296)・・・1354
C(n1570)・・・683
C# Version 5.0・・・511

他と比べてそれほど大きいようには思わない
むしろ5.1はとてもシンプルな部類
6はそれほどでもないが、依然他の言語と比べて
特に大きいわけでもない
それに、実質的には
プロトタイプベースがクラスベースに置き換わったりすると考えれば
過度な肥大化とも思わない
ベストな側面に限定すればそれほど複雑化していないと思う
0673デフォルトの名無しさん2015/04/08(水) 08:01:44.37ID:AhPQaRgb
仕様書の厚さで語られてもなぁ
0674デフォルトの名無しさん2015/04/08(水) 08:28:28.69ID:aehDYe+y
>>665
俺は特にと書いたわけだが何故その意を解釈できないのかね。
じゃあそういう国語ができない馬鹿向けに微妙なニュアンスを避けて白黒はっきり書こうか。
単にfunctionを省けるだけで追加の=>があるので簡潔に書けないと言っておこう。
returnの省略はJavaScript1.7で瞬間的に実装された事の焼き直し。というか省略は式の時だけだろ馬鹿が。
しかしthisの相違こそが目的なのだが、これに慣れるまでまたはそもそも元々のthisに不慣れであれば煩雑さの追加でしかないだろうな。
0675デフォルトの名無しさん2015/04/08(水) 08:34:11.40ID:PieVlODi
Rubyの仕様書は0ページだけどクソ複雑だよね
0676デフォルトの名無しさん2015/04/08(水) 08:43:39.84ID:aehDYe+y
>>665
JSONはその名の通りJS発生の物を更に簡潔化一般化したデータ形式でそもそもNN2の頃から読み取りで構文は存在しNN3/IE4でスクリプトのリテラルに追加された。
しかしJSから見たら流行時期的にresponseTextなどの文字列として受けてもデメリットであるという微妙に不便な仕様。だから即座にJSONPという名前でスクリプトそのものを埋め込む形が主流となった。
XMLはJSの独壇場と断言出来るほど素晴らしく地道で愚直な実装だわな。
このスレで対象とする他のスクリプト言語を見てみろ、要は、難解膨大な仕様を理解せず即席実装したモジュールのオンパレードだ。ホンマにゴミ。悪いのはXMLじゃなくPerl/python/rubyに蔓延る聞く耳持たない傲慢な姿勢だ。
0677デフォルトの名無しさん2015/04/08(水) 08:54:18.75ID:j3bjzkVr
>>674
なぜ理解できていないと思うの？
functionが=>になったら客観的に見て議論の余地なく明らかに文字列が減っているし
式の時にreturnが省けて0文字になるのもその通りだといっただけ
「特に」などという、曖昧な感覚的言葉に逃げる必要もなくね
まあ、簡潔かどうかなんて確かに最終的には感覚なんだけども
できるだけ説得力をもたせようとしただけ
0678デフォルトの名無しさん2015/04/08(水) 08:56:11.60ID:aehDYe+y
ここ数年pythonを書いていて玩具感が湧いてくるのはJSが本格的に飛び抜けてきたからに他ならないと思う。
腰の低さに尽きると思う。面倒な事をベンダーが愚直に遂行してくれる事の積み重ねだと思う。
最近の代表例はURL周りで、そもそもJSで初めからある実装を言葉を変えて仕様としたに過ぎないのだが、そんなものまで愚直に実装を試みている。
バッドノウハウ的にHTMLAnchorElementを作ってhrefプロパティなどを読めばより意のままの値を返してくれるのに敢えて重複実装を試みているわけだ。
こんな怠い作業はJSでしか見られない。謙虚なんだろうな。だからとうとう圧勝しつつあるわけだと思う。
0679デフォルトの名無しさん2015/04/08(水) 08:56:16.54ID:j3bjzkVr
>>676
難癖つけたいのは分かるが、responsetextの文字列として
幅広く使われていて、なおかつ簡潔であるのは事実
簡潔さが受け入れられて幅広く使われているのだと思う
0680デフォルトの名無しさん2015/04/08(水) 09:02:55.72ID:j3bjzkVr
pythonはpythonで科学計算分野では、RやMatlabを食って圧勝しつつある
多くの分野に侵食しつつあるJavascriptもこの分野に限って言えばまだ遠く及ばない
PythonとJavascriptはそれぞれ異なる分野で勝利を収めつつあると思う
Rubyもサーバーサイドに関してはまだ頑張っている
0681デフォルトの名無しさん2015/04/08(水) 09:41:00.88ID:LUeH7/wa
>>671,672
抽象的ってのは細かくないということなのに、抽象的なのは細かいからってどういうこと？
例えばこういう問題を仕様書から解決するのが難しい。
http://ja.stackoverflow.com/questions/2544/javascript-%E5%85%B1%E6%9C%89%E6%B8%A1%E3%81%97
それは実マシン上での動作まで踏み込んでないのと、言葉の定義が不足してるから。

それと仕様の一部は他のECMA標準に分離されてるから実際はもう少し大きいと考えていい。
ES5→ES6で倍以上に増えたのも、仕様が簡潔とは真反対の方向性だろう。
ES7では分離仕様合わせて1000ページに届くかもしれない。

あと、
＞＞それに、実質的にはプロトタイプベースがクラスベースに置き換わったりすると考えれば
そんな予定は全くないが、これは一体何のことについて言ってるんだ？
0682デフォルトの名無しさん2015/04/08(水) 09:46:17.30ID:WNj9G+8D
正直ruby、pythonよりperlの方が好き
0683デフォルトの名無しさん2015/04/08(水) 09:46:55.34ID:LUeH7/wa
>>676
JSONPはJSONをSOPを乗り越えて受け取るためのもので、
JSONへの批判ではなくXHRへの批判だよ。
0684デフォルトの名無しさん2015/04/08(水) 12:25:46.84ID:j3bjzkVr
>>681
まあ確かに抽象的ってのは細かいって分けじゃないね
ただ、それなんかはいい例で、共有渡しだろうが値渡しだろうが
オブジェクトの変更が呼び元にまで影響することを知ってればあとはどうでもいいわけ
プロトタイプベースとクラスベースのどちらのオブジェクト指向も
仕様には含まれているから、単純に考えてその部分は二倍に膨らんでいるけれど、
これからユーザーが選択するのはほぼクラスベースの記法だから
結局、実質はクラスベースだけ使えばどうでもよくなるということ
その意味で、仕様が膨大でも実際に使う部分は簡潔だという主張
0685デフォルトの名無しさん2015/04/08(水) 12:37:03.90ID:pjXzbj9Z
>>684
つまり、上のようなことを気にする人は、全く意味のないことを考える大阿呆だ、死ねばいいと言いたいわけか。
自分はとてもそうは思わないけど、まあ価値観の違いかな。
それとES6ではクラスベースは入らないよ。
0686デフォルトの名無しさん2015/04/08(水) 12:42:22.76ID:rvXuIGOO
>>672
Scalaが異様にすくないな
0687デフォルトの名無しさん2015/04/08(水) 13:57:21.64ID:5zTvLXHe
仕様書なんて真面目に読んでいたら、真面目に読むヤツらと
関わりあいたくないなと思っていたらPHPerになりました。
0688デフォルトの名無しさん2015/04/08(水) 14:11:29.91ID:AhPQaRgb
>>680
最近また科学計算分野でもRがモリモリと盛り返して来てる
国内とかほぼRが席巻してるは＾＾
0689デフォルトの名無しさん2015/04/08(水) 14:12:57.55ID:563zCrK1
>>686
Scalaの仕様書見た
形式的記述を多用してるから短いのと、実行時の振る舞いに関する記述がほとんど無い
TypeScriptみたいなもんだね
0690デフォルトの名無しさん2015/04/08(水) 15:22:11.02ID:5zTvLXHe
6って不吉だよね。perl6とかphp6とか、Windows9とか。ESも6か
0691デフォルトの名無しさん2015/04/08(水) 15:33:42.67ID:pjXzbj9Z
一応最終名称はES2015になる予定
0692デフォルトの名無しさん2015/04/08(水) 15:54:53.95ID:AhPQaRgb
プロは黙ってC/C++、Java、C#、Swiftのどれかでメシ食ってるわな
0693デフォルトの名無しさん2015/04/08(水) 16:34:41.71ID:PieVlODi
その中でSwiftは空気読めてないわ
ドカタがiPadとか使ってなんか作るならWebベースだよ普通
0694デフォルトの名無しさん2015/04/08(水) 16:55:34.70ID:pjXzbj9Z
語弊を恐れずに言うとSwiftはES6に似てる。
0695デフォルトの名無しさん2015/04/08(水) 18:33:36.10ID:5zTvLXHe
SIerで何年務めた処で、最期にはWordPressのもとへ還るんだ。
0696デフォルトの名無しさん2015/04/08(水) 20:44:03.05ID:as1UpX9P
jser/swifter/wordpressor三つ巴の争い

イマイチなものばっかり
0697デフォルトの名無しさん2015/04/08(水) 21:02:06.36ID:WuoyyETy
おそらくES9くらいでsweet.jsみたいな構文マクロと汎用的なASTAPIが入って、
JSはあらゆる言語を再現できるようになると信じてる。
0698デフォルトの名無しさん2015/04/08(水) 23:43:26.34ID:jXtiSI97
ES9なんて30年ぐらい後の話じゃん
その頃には今の現役はほぼプログラマ引退してるよ
0699デフォルトの名無しさん2015/04/09(木) 00:25:53.40ID:K0p3fTYv
ES6以降は約２年毎に次を出す予定だから６年くらいだよ。
0700デフォルトの名無しさん2015/04/09(木) 00:57:21.61ID:AT9UeNxe
生まれる前に、貴方が過ごしたプラットフォームへと LAMPに還りなさい
巡りあうためRailsバブルは起こるよ何度でも　魂のルフラン
0701デフォルトの名無しさん2015/04/09(木) 04:24:00.23ID:ZZNh5XRE
>>697
既に中間言語だから今でも似たようなもんだろ
0702デフォルトの名無しさん2015/04/09(木) 05:33:11.59ID:PU3/MD7e
64bit数値演算やSIMDなんかはES7で入る可能性高いけど、
問題なのはマルチスレッディングの動向だよね。
これはどう解決したらいいんだろう？
他のスクリプトそのために言語はどんなものを用意してる？

JSでは一応共有Bufferが使えるようになるけど、これはただそれだけであって、
排他制御なんかは全部自前で実現しないといけない。
意外とそれでも十分なのだろうか？
0703デフォルトの名無しさん2015/04/09(木) 06:52:42.24ID:pk8VIDLm
>>685
クラスベースの記法が入るよ
まあ分かってシンタックスシュガーにすぎないといいたいんだろうし、
議論とは関係ないけど
0704デフォルトの名無しさん2015/04/09(木) 06:55:02.62ID:pk8VIDLm
>>702
そういう数値演算はCなど他の言語で作ったライブラリを呼び出せば
いいと思うんだけど、わざわざjavascriptでやろうとしてるのか
0705デフォルトの名無しさん2015/04/09(木) 07:06:35.55ID:kbiH5k/G
PythonやRubyには、マルチスレッドを使っていても
インタプリタのコードが同時に複数スレッドで動かないように排他する仕組みがある
そもそもクソ遅いスクリプトでCPU主体の並列処理をする意味はないので、
IO待ちなど長時間のブロックを行う外部コールのみを並列化すればよいということだ
Perlのマルチスレッドは環境をコピーするだけのなんちゃって実装
他のメジャーなスクリプトで正式にマルチスレッドをサポートしているものは無い
壊滅的と言っていい状況
0706デフォルトの名無しさん2015/04/09(木) 07:22:24.53ID:f62ozbN6
>>699
ESのリリーススケジュールが守られたことなんかないのによくそんなの信じラられるな
0707デフォルトの名無しさん2015/04/09(木) 17:33:11.31ID:X8EWI3Hg
>>703
「どちらのオブジェクト指向も仕様には含まれている」は間違いでしょ。
クラスベースっぽい記述というだけなら元々new演算子なんかもそうだし、
単に新しい構文が入るから仕様書の量が増えたわけではない。
ビルトインコンストラクタとAPIの増量による影響が一番大きい。
0708デフォルトの名無しさん2015/04/09(木) 18:21:52.52ID:7HoQQxID
擬似コードみたいな簡単なのがコンパイルでもスクリプトでもJITでも動くってのがあればいいんだろ
0709デフォルトの名無しさん2015/04/09(木) 18:29:44.94ID:3AeMccD9
jsに64bit整数型とか諸々入るといいな
そうすれば中間言語としてより使いやすくなる
0710デフォルトの名無しさん2015/04/09(木) 18:34:40.31ID:X8EWI3Hg
今のところ
「 n = 123L 」のように末尾にLをつけることで実現できる予定。
他にもサフィックスを自由に定義できて「 10px + 20px // 30px 」みたいなのもできるようになる予定。
0711デフォルトの名無しさん2015/04/09(木) 20:22:03.27ID:+8az4MHk
jserは他の大人が昔からやっていことが自分にもできるようになって喜んでる子供なんだよ

可愛がってやりなよ
0712デフォルトの名無しさん2015/04/09(木) 20:35:17.45ID:eS1iBdrf
>>707
深く議論するつもりもないけど、クラスベースとプロトタイプベースの違いは
まさに構文の違いだと思うので間違いだとは俺は思わない
もともとの論点は仕様書が増えるかどうかだけど、
仕様書は構文とその動作を解説するのだから、明らかに
増えると思うけど
0713デフォルトの名無しさん2015/04/09(木) 21:36:23.16ID:YoNvu6dm
プロトタイプベースとクラスベースは別では?
前者はどんな変数もメソッドが付加されたオブジェクトに勝手になってる、にされる。
後者はユーザーが定義したものしかオブジェクトにならない。こっちは中途半端なオブジェクト指向では。
typescriptはプロトタイプベースでクラスもあるが。
0714デフォルトの名無しさん2015/04/09(木) 21:38:53.34ID:kbiH5k/G
>>712
宣言的か帰納的かの違いだよ
EcmaScriptの仕様書読めばよくわかると思う
後者は実装に制約を与えてしまいやすい
0715デフォルトの名無しさん2015/04/09(木) 21:44:42.12ID:3AeMccD9
拡張メソッドや特異メソッドなんてのがあるんだから
クラスもプロトタイプもどちらも必要なんじゃないのかな
だからこそtypescriptですよ
0716デフォルトの名無しさん2015/04/10(金) 00:05:30.01ID:kWY2SswQ
データベースとLPICだけで良いよね
0717デフォルトの名無しさん2015/04/10(金) 00:48:28.55ID:1gvf1Lsf
初期のJS、適当に仕様決めただけ
0718デフォルトの名無しさん2015/04/10(金) 01:21:41.19ID:UTBzSXHR
確かに適当だけど拡張性高くてpolyfillでなんとかできる事多いのはすごいと思う
0719デフォルトの名無しさん2015/04/10(金) 04:01:02.39ID:SdAjFeNn
>>712
微塵も分かってないね。
メソッドとコンストラクタをまとめたクラスと言うものを作るのは、
プロトタイプベースにおいても構造化プログラミングの概念上当然のことで、
プロトタイプベースは言語が最初に用意したクラスシステムに縛られないというのが重要なポイントなわけよ。
一方で言語が最初から一般的なクラスタシステムを用意してくれるのも自然であって、
Class構文があるからクラスベースだとか、そんな単純な話では全くないのよ。
JSのClass構文はクラスシステムを用意する際のオプションの１つでしかないわけ。
また、話の本筋である仕様書について、それが入ったから内部的に大きく変わって、
仕様書が大きくなる原因になったとかそういうわけでも当然ない。
0720デフォルトの名無しさん2015/04/10(金) 07:09:22.67ID:MMsSUjd2
>>719
うむ。よく分からん。クラスシステムに縛られないとか言われても
クラス構文(で出来ないこと)に縛られないと
言ってるようにしか見えん
オプションの一つでしか無いと言われても、両方構文があると言ってる
ようにしか見えん
構文が増えたら、増えた分仕様書が大きくなるのは当然であって
内部が実装とかそういう話であれば仕様書の範疇ではない
0721デフォルトの名無しさん2015/04/10(金) 12:26:53.88ID:BGIlANqs
今日は新しい歴史が始まる日
もっとも身近なパーソナルテクノロジーによってその扉は開かれようとしている
生命への新たなアプローチ

ビバ！Swift！
0722デフォルトの名無しさん2015/04/10(金) 16:22:34.07ID:kWY2SswQ
>>717
schemeを拡張しただけの言語だかんね
0723デフォルトの名無しさん2015/04/10(金) 17:05:14.57ID:WBKzV1HP
jsほど運の良かった言語は他にないよな。
0724デフォルトの名無しさん2015/04/10(金) 17:12:59.12ID:kWY2SswQ
プログラム言語が備えるべき機能は既にschemeの時点で完成されてたんだ
ただソレ以上に、()が読み辛いって問題は誰もが想像した以上に本質的な問題だったんだ
0725デフォルトの名無しさん2015/04/10(金) 17:28:49.14ID:1VxhqYwR
>>720
実装ではなく構文のベースとなる処理について言ってるんだよ。
もしプロトタイプベースだったものに並列してクラスベースを入れるとなると加筆箇所が膨大になるでしょ。
でも実際はプロトタイプベース上のクラスシステムが１つ増えただけだからそうはなっていない。
仕様書の量が倍増した理由は単にAPIや構文が沢山増えたから。

もう一度言うけど、プロトタイプベースにおけるクラスとは、構造化プログラミングをしていった上での自然な結果でしか無いのよ。
とは言え毎回自由にクラスシステムを各個人が作るのもアレだから、その最もベーシックな形を言語が最初から用意してくれてるわけ。
これはMathとかDateとかが最初から用意されているのと変わらないわけよ。
そしてそれらだけでは足りない場面が多くあるように、Class構文が入ったとしても、
実際はそれとプロトタイプベース的な継承の両方をうまく使っていかないとやりたいことはできないのよ。
0726デフォルトの名無しさん2015/04/10(金) 18:18:31.97ID:exAJrqYk
ASがJavaかPHP5みたいになっているのは黒歴史か？
classなんてとっくの昔からASで書いているよな。
0727デフォルトの名無しさん2015/04/10(金) 18:39:24.57ID:UTBzSXHR
jsは他人が作ったオレオレクラス定義でもすり合わせばなんとかなるゆるふわ言語だし
プロトタイプベースだから他人が作ったクラスにお好きにメソッド追加できたりするし
定義とかやだーって気分のときはオブジェクトにそれっぽいプロパティだけあればいいでしょって適当にやればいいし
スクリプトなんだからお気軽お手軽でいいんだよね
0728デフォルトの名無しさん2015/04/10(金) 19:55:49.23ID:EwSb4KYJ
>>717
3日で作ったって話し忘れてない？仕方ないような…
0729デフォルトの名無しさん2015/04/10(金) 22:55:06.92ID:EwSb4KYJ
デスマ化が常態化して２ｃｈなんか見るヒマがないとか
0730デフォルトの名無しさん2015/04/10(金) 22:55:35.74ID:EwSb4KYJ
誤爆
0731デフォルトの名無しさん2015/04/11(土) 01:22:03.49ID:hRe3cPjf
wordpressってフルスタックだよね
0732デフォルトの名無しさん2015/04/11(土) 02:24:11.22ID:hRe3cPjf
angular2のshadow domとreactのvdomって何が違うわけ
もうバカバカしくて、当分はPHPとMySQL以外は触らなくて良いんだなって思う
0733デフォルトの名無しさん2015/04/11(土) 02:50:26.09ID:uw2dHI6h
何言ってるの？
煽るにしてはレベル低すぎだし、冗談しては面白くないし
0734デフォルトの名無しさん2015/04/11(土) 03:07:49.80ID:VpCEyFbh
>>728
それは流石に冗談だよ。
そもそも仕様はES3になるまでかなり変わってるし、別にそれは関係ない。
0735デフォルトの名無しさん2015/04/11(土) 04:20:20.89ID:xPcAPUBj
>>732
全然違う概念。
shadow DOMはコンポーネントをブラックボックス化するための技術で、
virtual DOMはDOM操作を簡単に、かつそこそこ性能出るようにできる技術。
0736デフォルトの名無しさん2015/04/11(土) 04:38:28.79ID:VpCEyFbh
virtual DOMは表面に最適化レイヤーを追加するもの
shadow DOMはDOMのレイヤーを掘り下げる
0737デフォルトの名無しさん2015/04/11(土) 12:23:49.19ID:LAqhQeC5
元々得意な言語がある人、web主体じゃない人にとっては、
なぜよりによってjsなんか使うんだ？
という感覚
0738デフォルトの名無しさん2015/04/11(土) 16:07:50.36ID:grlxJ++X
最も理想的なプラットフォームとなろうとしてるWeb上で動く言語がJSだから。
0739デフォルトの名無しさん2015/04/11(土) 16:22:20.73ID:N1524vgj
フロント系の人の方が情報発信に積極的だし数も多いしSEOも上手いから
そいつらにとって馴染みやすいものの検索エンジンのスコアが高くなるのは当然
0740デフォルトの名無しさん2015/04/11(土) 19:43:08.20ID:LAqhQeC5
jserの相手するのって面倒に感じてくるんだよな
もう少し広い視野で話ができればいいんだが

だから過疎るのか？
0741デフォルトの名無しさん2015/04/11(土) 21:18:20.55ID:R3PWpsLA
バトルの勝者決まっちゃったからね・・・
0742デフォルトの名無しさん2015/04/11(土) 21:38:29.96ID:vAoXrsjc
崇高な学術系分野には手も足も出ないスクリプターが哀れでならない
きたる4/24、俺は高次の領域を科学(プログラム)するよ
0743デフォルトの名無しさん2015/04/11(土) 21:52:05.52ID:hRe3cPjf
>>737
デファクトで時代の流れについてく必要があるから。それだけのこと
ただまぁ、殆んどの課題はWordPressの導入とカスタマイズで済むよね
0744デフォルトの名無しさん2015/04/12(日) 22:37:32.56ID:DuCQa3Tp
Swift
0745デフォルトの名無しさん2015/04/12(日) 22:46:06.20ID:a963lNxg
単なるブログツールにWPを使うって、かなりリッチだよね
static site generatorで済むものが、どれだけあることか
0746デフォルトの名無しさん2015/04/13(月) 16:52:45.72ID:KIdTNjEZ
>>704
基本的な考え方として、もうJSレベルの速さだと言語を跨ぐオーバーヘッドや最適化不能のコストの方が大きい。
例えばV8ではMathは大部分がJSと、インライン最適化可能なミクロなアセンブリ郡ファンクション(%_)で実装されている。
https://chromium.googlesource.com/v8/v8/+/master/src/math.js
https://chromium.googlesource.com/v8/v8/+/master/src/third_party/fdlibm/fdlibm.js
これからJSはどんどんセルフホスティングされていって、
Math.clz32みたいに本当に直接アセンブリに変換できるようなレベルの機能が増えると思う。
今はまだAPIに限るけれど、ES7で演算子オーバーロードがサポートされれば構文レベルのセルフホストも一部始まると思う。
0747デフォルトの名無しさん2015/04/13(月) 17:41:32.71ID:YB0nEuSG
仕様書を捨てよ町へ出よう
0748デフォルトの名無しさん2015/04/13(月) 18:23:39.46ID:72ToVErP
>>746
まとめるとなんなの？

ただプログラミング書くとき、コンピューターとお喋りするみたいにだらだらと文字を羅列するだけなら猿でもできるよ。

読み手の事を考えずに文字打てないのは良いプログラマーとは言えないな
0749デフォルトの名無しさん2015/04/13(月) 18:45:47.08ID:WlZ/Renz
まとめる必要はないでしょ。自明なんだから。
あえて書こうか？
そういう数値演算はCなど他の言語で作ったライブラリを呼び出すのは良くない。
わざわざjavascriptでやろう意味がある。
0750デフォルトの名無しさん2015/04/13(月) 18:50:10.27ID:YB0nEuSG
もはや営業もサービスエンジニアもイラナイないなw
0751デフォルトの名無しさん2015/04/13(月) 22:35:12.91ID:72ToVErP
>>749
最後の一文が日本語とは思えないほどバグってて草
0752デフォルトの名無しさん2015/04/13(月) 23:40:11.92ID:YB0nEuSG
airbnbや電子書籍の事例から既得権利をとったものの勝ちなんだって思う
つまりは、我々はRMSによって自由を勝ち得た
0753デフォルトの名無しさん2015/04/14(火) 04:19:56.11ID:LSv5OiEr
>>751
お前も最後の一文字おかしいぞ草
0754デフォルトの名無しさん2015/04/14(火) 12:41:35.13ID:rMpfgj52
>>753
W
0755デフォルトの名無しさん2015/04/14(火) 14:19:16.89ID:Vj73IOZr
>>753
0756デフォルトの名無しさん2015/04/14(火) 22:25:07.13ID:XJqe0/O2
今やjavascriptがマンセーされている世の中だけれど、非同期でどうこうしろ、
画面設計をどうこうしろってレベルの機能要求に見合っただけの金を出す顧客って、
どんな人たちなの？かえってバグの温床になって工数掛かるだけの気がするんだけど
■ このスレッドは過去ログ倉庫に格納されています