15/09/30 13:15:48.72 /h7yi4VP.net
URLﾘﾝｸ(www.google.co.jp)
Yahooからステマ認定され広告を解約されたマイナビは低級言語を推してくる
"プログラミング言語別"の求人年俸額の順位、1位は「Python」で平均382万円
URLﾘﾝｸ(news.mynavi.jp)
ITも特亜に工作されているということだよ
ジャップは低級言語でいつまでももがいていろということだよ
3:デフォルトの名無しさん
15/09/30 22:51:45.25 bqsObMsV.net
低級言語ってのはマシン語やアセンブラのことだろ
Pythonなんておもいっきり高級言語じゃねえか
4:デフォルトの名無しさん
15/09/30 23:36:21.27 QOvaNotd.net
日本でitはバカしないないというのがわかるスレ
5:デフォルトの名無しさん
15/10/02 12:02:07.87 AKckLqEC.net
Ron?@CodeMonkeyZ
We are starting public development of 2ch's new javascript frontend.
Please follow here if you are interested:
URLﾘﾝｸ(github.com) …
6:デフォルトの名無しさん
15/10/09 12:14:34.38 4+L35LN5.net
"手続き型のダンジョン生成アルゴリズム"
URLﾘﾝｸ(postd.cc)
7:デフォルトの名無しさん
15/10/09 20:50:05.15 a6l66mp2.net
railsの何が凄いのか全然分からない
8:デフォルトの名無しさん
15/10/09 21:00:28.32 ELEmlsjj.net
コロンブスの卵的なすごさはもちろんあるだろうけど、これだけ「Rails系」と言われる
フレームワークが各言語で出ている現状でもまだトップを走っているのがすごい
9:デフォルトの名無しさん
15/10/09 23:34:57.01 0yJdvn1+.net
>>6
これ使われてる言語なに？
Lua？
10:デフォルトの名無しさん
15/10/10 03:39:03.65 9WMmqKq2.net
>>9
みたい
URLﾘﾝｸ(i.imgur.com)
11:デフォルトの名無しさん
15/10/10 20:55:43.82 wylVu18O.net
railsが評価されてんじゃなくてrubyが評価されてるだけだろ
PHPとrubyみて文法の良さでPHPが勝ってると思う奴なんていない
速度に関しては遅いってデマが嘘だと気づかれ始めてる感じはあるか
12:デフォルトの名無しさん
15/10/10 21:12:01.67 wZWPBuKi.net
そのRubyが3.0で静的型の機能を取り入れたいって言ってるんだから
静的型の有用性が明らかになってきたね
13:デフォルトの名無しさん
15/10/10 21:23:38.22 7qoXcIfa.net
Rubyが互換性捨てて静的型になったりしたら、
RailsはRuby2をRailsScriptとしてフォークしそうだな
そしてRubyもRailsも共倒れのパターンだ
14:デフォルトの名無しさん
15/10/10 21:52:28.29 B7+308rF.net
その時はRailsはRuby3.0を追っかけるさ
15:デフォルトの名無しさん
15/10/10 22:05:16.74 t3GFdbA2.net
互換性を捨てるわけじゃないだろ
現行の何でもアリ型は何でもアリ型というひとつの型で残すんだよ
整数型や文字列型と同様に型のひとつになるってだけだ
16:デフォルトの名無しさん
15/10/10 22:14:42.66 rHFZYJSj.net
そしてRailsのM,V,Cはいずれも何でもあり型にしかなり得ないわけだけど、
そういう歪な状態を意識高い(笑)rubyist連中が受け入れられるかどうか
17:デフォルトの名無しさん
15/10/10 22:28:42.96 wZWPBuKi.net
それは俺も思ってる
静的型の機能が有るなら、
型は出切る限り書くべき、その方が綺麗、って空気になると思う
静的型言語ではキャストはなるべく避けた方が綺麗ってのは常識だしね
静的型を導入するということはそういうことかと
機能が有るのに活用しないのもおかしな話だからな
しかーし、Rubyの静的型がまともに機能するのが前提だが
ジェネリックとかが無くて実質的に静的型がまともに使えない代物のなら
Rubyの静的型は偽者って言われるだろうし、混乱しそう
そのへんどうするんだろうね
しかもmatzはあまり静的型に乗り気ではないと想像してる
今までずっと動的型の優位性を説いてきたような人だからね
とはいっても周りがどんどん導入してきているからね
静的型はスクリプト界のトレンドだから
18:デフォルトの名無しさん
15/10/10 22:38:37.78 rHFZYJSj.net
静的型のメタプログラミングはScalaがやろうとして大失敗してるな
Rubyもああならないことを祈る
19:デフォルトの名無しさん
15/10/10 23:00:14.12 37NZking.net
Ruby3はTIOBEの順位を維持する燃料程度の役割しかなく、
たぶんまつもとによる実装は無理。
かつてのRite同様にベーパーウェアに終わるだろうね。
20:デフォルトの名無しさん
15/10/10 23:21:49.91 WT9ul4l1.net
まず、優れたソフトウェアがPythonで書かれてる事が多い、自然言語処理系や人工知能系、Deep Learningなど。
Common Lispの様なマクロを持った昔から使われている言語も重要だろう。
JavaScriptは今やMac自身Automatorなども動かせるし、フロントエンドバックエンドなども動かせる様になったのでそれを学ぶ意味ではとても便利な言語。
そしてオープンソース化が期待されていて、ハードウェアとソフトウェアの高い次元で上手く設計されるだろうSwift 2
妥協点ととっつきやすさ、今後のコンピューターの進展を見据えて設計されているだろうSwift 2に期待かな。
Swift 2と全く同じ事すれば言語としては流行るかもねw
もっとも後追いだし先に地雷踏めばSwift 2はかわして設計するだろうし、
良い設計をすればSwift 2にパクられておしまい。
新しい言語なんて作る必要も無いし、Rubyとか誰も本気出してないプログラム言語と心中する人の気がしれないね。
Python, JavaScript, Common Lisp, それとSwift 2やっとけばいいと思う。暇なときにC/C++という感じかな、時間の上手い使い方として。
それ以外の時間は英語やマーケティング、トレンドやデザイン、数学や物理やってた方がより良いソフトウェア使えたり面白い製品作れる可能性ある。
あれもこれもプログラミング言語使えてLAMP使えてスゲーしてるのってガラパゴス日本だけwwww
21:デフォルトの名無しさん
15/10/10 23:36:31.24 B7+308rF.net
メタプログラミングRuby 第2版
URLﾘﾝｸ(www.amazon.co.jp)
22:デフォルトの名無しさん
15/10/10 23:43:40.71 rHFZYJSj.net
静的型にする気があるなら「バッドノウハウRuby」に改名しろよ
23:デフォルトの名無しさん
15/10/11 00:53:57.26 8f2DNTjb.net
>>20
> まず、優れたソフトウェアがPythonで書かれてる事が多い、自然言語処理系や人工知能系、Deep Learningなど。
優れたソフトウェアの定義が狭すぎだねw
OSはC/C++だったりするし、PHPのwikipediaとか
TwitterやFacebookなんかもある。
君がそこにあげているのを見ると、優れたソフトウェアというより
優れているかどいうかは別として、科学技術の基礎研究用（＋成果のライブラリ）
という気がするね
24:デフォルトの名無しさん
15/10/11 04:03:23.39 06RK7D7v.net
その人偶に見かけるけど Common Lisp が入ってるんだよなあ
25:デフォルトの名無しさん
15/10/11 04:53:23.53 pSDbZ28N.net
個人的に一番感じる「優れたソフトウェア」とは言語エンジンそのものだけどなぁ
26:デフォルトの名無しさん
15/10/11 07:41:21.27 U3MJCY0J.net
OOP（といってもクラスベースよりメッセージングベースとして）、
GUI（マルチウインドウ、ポップアップメニューなどのノウハウ蓄積）、
からめてMVC（リエンスカウの古典から、MVP、MMVC、その先のDCIまで）、
さらにデザパタ（GoFはいうに及ばず、アレグザンダーいうところの無名の質まで）や
アジャイル（xUnitから、TDD、XP）などの開発手法が生み出された経緯、
メタプログラミングや遅延結合（URLﾘﾝｸ(metatoys.org) ）、
VM高速化技術（古典ではJITからJava HotSpot、近年ではSqueak CogやSpur）、
OODBに繋がるオブジェクト永続化技術（イメージベース、GemStone）とか
いろいろ遊べて学べるSmalltalkも、PGならコモンセンスとして備えておきたい。
URLﾘﾝｸ(zerobase.hateblo.jp)
Smalltalkをちょっとかじってみたい人のためのチュートリアルまとめ
URLﾘﾝｸ(qiita.com)
さすがにこれでスタートアップ、資金１億調達まで目指すのは苦行だけど^^;
URLﾘﾝｸ(twitter.com)
27:デフォルトの名無しさん
15/10/11 10:09:35.92 jdhTMeIt.net
高野さん、Smalltalkの会社に転職したんだ。
チャレンジャーだな…
28:デフォルトの名無しさん
15/10/11 10:18:19.81 gadIIZk0.net
>>25
言語処理系は情報処理の理論がそのまま実用になる数少ない分野だからね
やってることが非常に単純な割にはソフトウェア開発の重要な部分を占めるので、
技術バカの大好きな視野狭窄なクォリティ追求が許されてしまうし
29:デフォルトの名無しさん
15/10/11 13:32:15.53 AIIBuHzT.net
>>23
広告クリックさせたりする事が優れたソフトウェアやサービスとは思えないからTwitterとかFacebookとかクソだね。
SVの人達もそういう考えだし。
30:デフォルトの名無しさん
15/10/11 15:57:18.77 XJEeMP8F.net
>>29
やっぱり考え方が狭すぎだねｗ
31:デフォルトの名無しさん
15/10/11 19:15:14.88 5ati5bYz.net
Rubyに関係なく、素朴な意見として、
なぜ静的型を動的言語で？
最初から静的言語を使えばいいだろ
おわり
32:デフォルトの名無しさん
15/10/11 19:41:24.67 6jGim2k9.net
Pythonの型付けもそうだけど、一番はドキュメントとして型表記を利用したいんだよ。
別に一部で型を明記したところでそうでない部分との関係で対して最適化や補助は効かないけど
ドキュメントとしては価値がある。
33:デフォルトの名無しさん
15/10/11 20:25:48.63 XJEeMP8F.net
例えば、current_timeという名前の変数があったとして、
そこに何型が入っているかはわからんのだよね。
処理を読めが型は推測できるが、推測して判明するまで
時間がかかるのは、可読性が低いということを意味する。
名前からは何型かわからないが、処理は特定の型
専用のコードになっている。
変数自体は動的であっても、処理自体は動的ではない。
処理が動的じゃないのであれば、型も静的でいい。
34:デフォルトの名無しさん
15/10/11 20:58:32.42 6jGim2k9.net
まあRuby的には超賢いIDEができて推論した型を表示してくれるというのが理想なんだろうけどな
35:デフォルトの名無しさん
15/10/11 21:18:59.86 VUX4VOf2.net
無理無理
だって、メソッドの引数の型は、呼び出し元で変数を渡してもらって始めて決定する
未だかつてどこからも呼び出されていないメソッドの引数の型は解析も無理
36:デフォルトの名無しさん
15/10/11 21:48:52.37 gadIIZk0.net
それ以前にメソッドの有無すら実行してみるまで分からない
メタプログラミングを捨てずに静的チェックやるなら、
チェック時に全てのクラスの中身を一度実行してみて、
その結果できたクラスオブジェクトを解析するしかないんじゃないかな
解析する時と実行する時でクラスのコンテキストが変わるというのは、
クラスを書く人にとってはバグの温床になりそうだが
37:デフォルトの名無しさん
15/10/12 03:41:12.46 53GvI8rG.net
Perlみたいにコンパイルフェーズってのを作ってればよかったのにね。
だいたいのメタプログラミングってのは、実行時にやりたいんじゃなくて
実行前にやれば十分なんだよ。
例えばある標準クラスがあったとして、そこにメソッドを
つけ加えたいなと思った時、実行時につけ加えるじゃなくて
実行前に付け加えれば十分でしょ？
38:デフォルトの名無しさん
15/10/12 04:56:12.47 L9nzf7kh.net
>>35
別に完璧である必要はないじゃん
ある程度上品な書き方（MethodMissingとか動的なメソッド追加とか使わない）において
ある程度の情報が提供されればそれで十分だと思うけど
39:デフォルトの名無しさん
15/10/12 09:31:45.11 +zms5d6G.net
Swiftが美しすぎる
40:デフォルトの名無しさん
15/10/12 09:38:22.19 QcfJYyiX.net
Pythonには型推論して型を表示してくれる
超賢いIDE（jediとか）があるんだから、Rubyでもヨユーヨユー
41:デフォルトの名無しさん
15/10/12 10:24:06.79 kiUfesSB.net
C++を使いこなす余裕があればRubyもSwiftもいらねーんだよ
おまえらの仕事は余裕のない弱者を助けることだけだ
42:デフォルトの名無しさん
15/10/12 11:46:17.79 7BEPgWVx.net
C++のOOPは偽物
RubyのOOPは本物
動的なメソッド追加は本物の証
この解釈が撤回されたときC++は復活する
43:デフォルトの名無しさん
15/10/12 11:47:38.50 lzwRwYon.net
>>32
従来変数名でやってたことだね
それだけのことで静的型を入れようとかいう話になるの？
44:デフォルトの名無しさん
15/10/12 11:51:33.35 DSHcQooM.net
C++の静的型は本物
Rubyの静的型は偽者
って言われる日がくるかもね
45:デフォルトの名無しさん
15/10/12 11:52:06.13 GPJRvwrY.net
OOPに本物とか偽物とか言ってる情弱がまだいるとは…
Rails土方、恐るべしだな
46:デフォルトの名無しさん
15/10/12 12:06:39.18 DSHcQooM.net
そうそう、本物のOOPならマルチメソッドぐらい無いとね
第一引数だけを特別扱いしてレシーバとして前に出して記述するRubyのOOは偽者だよね
真のOOPならこうかけなきゃ
( obj1, obj2 ).method
もしくは
method( obj1, obj2 ) ←これで多態出来なきゃね
動的型言語の癖にこんな事もできないRubyは偽者だよ
47:デフォルトの名無しさん
15/10/12 15:19:12.41 83Q2zR6P.net
Railsを日本で広めようとしてる奴らは大体腹黒いやつなきがする。
あくまでも個人的な意見ね。
48:デフォルトの名無しさん
15/10/12 16:39:34.85 NwCMAomS.net
>>46
例えばJavaScriptでも
自動振り分けのラッパー噛ませた関数を出力するヘルパー作っておいて
共通プロトタイプと組み合わせて使えば、
もしくは適切な方に適切に振り分けるプロキシを共通プロトタイプにしておけば
スマートに実現できると思うけど、
Rubyでも出来るんじゃないの？
49:デフォルトの名無しさん
15/10/12 17:20:55.95 jcvepef5.net
let o = {
anch:[this.tag.dt, this.infobg, is_anch(e)]
}
で
(o.anch[2])? o.anch:"";
ができるんだな
50:デフォルトの名無しさん
15/10/12 17:21:47.20 53GvI8rG.net
>>48
工夫すればなんでも出来るんだよ。
例えばC言語でオブジェクト指向ができるように。
だけどそういうのは本物ではない。
51:デフォルトの名無しさん
15/10/12 18:52:10.29 7BEPgWVx.net
>>50
「C言語はオブジェクト指向言語」と宣言したら嘘で偽物だが
宣言しなければ嘘でも偽物でもない
宣言することがそんなに良いことなら自分ですればいいのに
他人に広めようとしてる時点で怪しいんだよ
52:デフォルトの名無しさん
15/10/12 19:02:59.91 DSHcQooM.net
つまりRuby3.0が静的型を正式に取り入れた、と宣言したのに
実物がいい加減な代物で「嘘」「偽者」だったって未来へ向けてのフリですね
53:デフォルトの名無しさん
15/10/12 20:49:27.38 ZTa/or21.net
Matzの戯れ言を本気にする人間っているんだな…
Rubyのことをちょっとでも知ってるなら、ただの燃料だということはすぐ分かりそうなものなのだが…
54:デフォルトの名無しさん
15/10/12 21:06:58.48 GPJRvwrY.net
>>46
少なくともケイのメッセージングOOP（が本物と言うつもりはさらさらない。為念）の考え方では
(obj1, obj2).msg なら (obj1, obj2) というタプルに対するmsgというメッセージ送信になるのでは？
そもそもこのパラダイムでは、msgというメッセージ送信によってセレクタmsgと同名のメソッドmsgが
コールされるとは限らないという仕組みにより遅延結合をユーザーに意識させるところがミソなので、
URLﾘﾝｸ(metatoys.org)
マルチメソッドを持つか（メソッドのオーバーロードが可能か）否かはいうに及ばず、
メソッドが静的型を持つかといった話とは別のような。
ケイ曰わく、
「型には反対しないが、複雑さに悩まされない型システムを見たことはない。動的型付けはまだマシだ。」
URLﾘﾝｸ(d.hatena.ne.jp)
55:デフォルトの名無しさん
15/10/12 21:58:43.99 DSHcQooM.net
別に俺はマルチメソッドに静的型が必要だとは主張していないが
56:デフォルトの名無しさん
15/10/12 22:01:06.33 lzwRwYon.net
Matzが静的型を導入したかったのか？
57:デフォルトの名無しさん
15/10/12 22:20:18.93 DSHcQooM.net
多分本音は導入したくなさそう
静的型に対してかなりモニョってる印象
しかーし、最近のスクリプト言語はこぞって静的型を取り入れているし
流行に敏感ってことにしたいRubyとしては取り入れざるを得ないんだわ
一体今更どういう風に取り入れるかは見ものではある
静的型を導入すると当然昔からの風習にならって
「なるべく型は書くべき」、って派閥が出来るだろう
しかしそれはRubyの世界観にアンマッチになるっつーかさ
しかも、もし、ジェネリックすらないような中途半端な静的型しか導入できなかったとしたら
まともに使い物にならないものを押し付けられる
使い物にならなければ使わなければいいわけだが、
しかし型は書いたほうが良いという古くからの風習もあり、
一体どうしたものかと途方に迷う事になる
58:デフォルトの名無しさん
15/10/13 02:05:16.01 3QE/NkoP.net
>>42
C++のoopはバートランド・メイヤーの流れをくむものじゃないかな。時期的にC++のが早かったとしても。
メイヤーのeiffelはあれはあれで良いものだぞ
59:デフォルトの名無しさん
15/10/13 02:17:53.92 O9bZKJjD.net
>>57
途方に迷うのではなく暮れるのさ
60:デフォルトの名無しさん
15/10/13 06:34:58.02 3LDxUoaZ.net
ブレてるねー
1年前にmatzが自分で動的言語信奉者だと言ってたのを聞いたことあるけど
これじゃ更に人気を落としてくんだろうね
61:デフォルトの名無しさん
15/10/13 06:48:50.37 cMOwnvUD.net
>>54
そうか、マルチメソッドはそのタプルクラスのメソッドと考えることができるのか
だったら配列クラスのメソッドミッシングメソッドを賢くしてやれば実現できそうだな
62:デフォルトの名無しさん
15/10/13 09:20:37.48 Rl12UR24.net
>>61
そうですね。あとはC#の拡張メソッド（実体は静的メソッド）みたいに構文糖をまぶせば
通常のメソッド呼び出し（メッセージングOOPのパラダイムならレシーバーへのメッセージ送信）の
書き方にできるはずです。
ただ、ぱっと見レシーバーに見えるオブジェクトが、実質はタプル・配列等の要素となってしまっているため、
その（あるいはそれらの）内部情報に対する当該メソッド記述中でのアクセスについては制限が加わります。
C#の拡張メソッドと同じですね。
CLOS等の総称関数のように割り切るか、従来のメソッドと同レベルの使い勝手や
メソッドのありかた（特定のクラスに内包される）にこだわるならさらなる細工が必要になるでしょう。
（Dylanがこの問題をどう解決しているかは調べてません。ごめんなさい）
あと参考まで、メッセージングOOPのパラダイムでは古典的にはダブルディスパッチというベストプラクティスパターンが
すでにあるので、構文までいじくり回してマルチメソッドやメソッドオーバーロードを実現する価値が本当にあるか
よく吟味する必要はあるのかとも思います。
63:デフォルトの名無しさん
15/10/13 09:44:43.93 IPzu3dLL.net
何を言ってるんだ?
タプルに対する拡張メソッドにしたところでマルチメソッドでもなんでもないだろ
>>46
64:63
15/10/13 09:45:46.79 IPzu3dLL.net
すまん途中で書き込んだ
>>46が言ってるのは複数の引数の型によるディスパッチであり
>>54
65:63
15/10/13 09:47:48.53 IPzu3dLL.net
何度も申し訳ない
>>54は議論をすり替えているだけ
66:デフォルトの名無しさん
15/10/13 11:00:06.67 E12GE1WX.net
まあ落ち着こうよ。
>>46については「本物のOOP」が指すのがケイの動的・遅延結合をモットーとするメッセージングのOOPなのか、
ストラウストラップ・メイヤー・リスコフらの抽象データ型をクラスで実現するOOPなのかをはっきりさせないと。
もっとも、前者なら>>54にあるとおりメッセージ（に含まれるセレクタ）と同名メソッドのコールを保証する義理はないし、
後者ならレシーバとかいう表現がでてくる時点で何を言っているのか意味不明になるから、どっちにしてもあれだけど。
Rubyを擁護する気はないけど、Ruby開発陣の技術力不足をすべて動的・遅延結合におっかぶせる論調はよくない。
67:デフォルトの名無しさん
15/10/13 11:19:38.71 aIVsWkps.net
よく分からんけど
それが出来ることによって何がどう役立つの？
68:デフォルトの名無しさん
15/10/13 11:23:22.41 BR4NEKph.net
極稀にあるパターンをわかりやすく記述できる。
69:デフォルトの名無しさん
15/10/13 11:37:53.98 eox7qbM1.net
マルチメソッドが必要な理由がはっきりするまでは放っておけばいい
第一引数を特別扱いしたら偽者、というのはマルチメソッドとは関係ない
第一引数に頼らないクロージャを使って書き直すだけでOK
70:デフォルトの名無しさん
15/10/13 11:58:16.93 LdSr9S5L.net
マルチメソッド自体の必要性は静的言語のオーバーロードや動的言語の醜悪な型チェックの大さを見れば明白
71:デフォルトの名無しさん
15/10/13 12:10:35.89 WPI+iK8W.net
単純な対象性に対する疑問でもある
引数は0個から無限大まで幾つあってもよいはず
その中で第一引数だけ特別扱いして
しかも前に出して記述するのは対象性の観点から見てどうなのか
引数は全て等しい扱いを受けるべきでは
ここをクリアしないことにはOOPは学問になれない
単なる経験則で終わってしまう
72:デフォルトの名無しさん
15/10/13 12:34:02.06 BR4NEKph.net
>>71
可読性というものはそういうことなんだよ。
コンピュータから見れば、どちらでも同じだが、
人間が見てどう感じるかが、重要。
73:デフォルトの名無しさん
15/10/13 12:35:50.72 aIVsWkps.net
>>68
確かに定義においては認めるけど、使用の際には、そんなごく稀な記法を特別に使わせるのは分かりやすくないと思う
74:デフォルトの名無しさん
15/10/13 14:24:13.32 WPI+iK8W.net
>>72
人間からみても何とも言えないような場合はどうするんだ？
75:デフォルトの名無しさん
15/10/13 14:31:26.07 i1awIWf/.net
>>74
何と何の話？
76:デフォルトの名無しさん
15/10/13 14:39:04.87 WPI+iK8W.net
何でもいいけど、例えば基本的なところで
1+2なんてどう？
Rubyは1に+2ってメッセージが飛んでくるってノリらしけど
数学的ではないしように思うし
人間的にもplus(1, 2)ってイメージなんだが
77:デフォルトの名無しさん
15/10/13 15:32:13.81 WPI+iK8W.net
だいたいなんだけど、Rubyの1+2で
「1」に「2」を足しこむ機能が備わっているって解釈はどうなんだろう
「1」に「整数の1」以上の意味は要らなくない？
単なる整数の「1」や「2」をどう使うかは、演算子の「+」が決める事では？
「1」が「+2」を処理するというよりは、「+」が「1」「2」を処理するのでは？
そっちのが数学的だと思うんだが
78:デフォルトの名無しさん
15/10/13 15:41:38.20 i1awIWf/.net
>>76
何を考えているのかさっぱりわからんが、
人生を思い返してみればわかる。1+2という数式は
小学校でならって体に染み付いている。
これが人間が読んだ時の可読性ということ。
可読性というのは、過去の経験から決まるものなんだよ。
例えば、1を○、2を△、＋を□に置き換えて、
○□△と書いたとしても同じ意味になるんだけど、
読みにくいでしょ？ そんな風に習ってないから。
79:デフォルトの名無しさん
15/10/13 15:42:38.37 WPI+iK8W.net
もしくはマルチメソッド風に、
「1」と「2」が両方力を合わせて「+」を処理するってノリならまだ分かるんだけど
「1」が「+2」を処理するってのは腑に落ちないものが有るね
1+2で、「1」と「2」に格差がありすぎる
それに「+」の演算の定義は「1」が決めずに「+」自身が決めれば良いような
80:デフォルトの名無しさん
15/10/13 15:44:45.88 WPI+iK8W.net
>>78
言葉が足りなかったね
表記は1+2で問題ないが、その解釈の問題
Rubyは1が+2というメッセージを処理するって解釈する
1に演算がぶら下がっている状態
単に1と2を足すという、ただそれだけの事に
それ以上の拡大解釈が必要なのかという事
81:デフォルトの名無しさん
15/10/13 15:49:04.01 WPI+iK8W.net
>人生を思い返してみればわかる。1+2という数式は
>小学校でならって体に染み付いている。
全くその通りなんだよね、体に染み付いている
1+2は単に1と2を「+」という処理をするって考える
1と2は単なる数で、+は両者間の演算を定義している
ところがRubyは1が+2というメッセージを処理する、と考えることになっている
これは小学校からずっと習ってきた事と違うし不自然だね
小学校で1+2を1が+2を処理する、とは習わないだろう
82:デフォルトの名無しさん
15/10/13 15:59:08.67 WPI+iK8W.net
とにかく1+2をシングルディスパッチで、1が+2というメッセージを処理する、と考えると、
「1」と「2」の格差が物凄いことになってしまう
「1」は足し算の処理をする主体そのもので、足し算の意味すら定義している
「2」は単なるデータ
ここは一つ、マルチメソッド風に、「1」「2」が共同で「+」を処理する、と考えるか
もしくは単に、「+」が「1」「2」を処理する、と考えたほうが、素直なのでは
83:デフォルトの名無しさん
15/10/13 16:38:33.72 lCXr92CT.net
メッセージングのOOPというパラダイム（考え方）にいったん乗っかった以上、
obj.selector(args) を obj への selector(args) というメッセージの送信だという
解釈は曲げてはダメでしょう。たとえ小学校でそのように習わなかったとしても。
84:デフォルトの名無しさん
15/10/13 16:49:10.34 lCXr92CT.net
3+4 という演算式を 3 に +4 というメッセージを送ると解釈するのが違和感あるというのはむしろ逆で、
アラン・ケイは、オブジェクトにメッセージを送るという操作ですべてを表現する世界線で
3+4 という演算も説明できるようにするには、3 に +4 というメッセージを送ると解釈すればよい
というアイデアに思い至ったわけです。
URLﾘﾝｸ(gagne.homedns.org)
By this time most of Smalltalk's schemes had been sorted out into …あたりから
85:デフォルトの名無しさん
15/10/13 17:08:12.66 QDO/4Imo.net
足す物と足される物の区別があるんだから格差があって当然じゃない？
たまたま3+4という表記に限ってはたまたま交換定義も成り立つしそう見えるかもしれないけど
86:デフォルトの名無しさん
15/10/13 17:32:14.96 eox7qbM1.net
格差が悪いならpublicとprivateの格差を無くせ
情報が漏れるgetterと
情報が丸見えのHashTableを使え
multimethodTable[obj1.getType()][obj2.getType()](obj1, obj2)
87:デフォルトの名無しさん
15/10/13 17:37:36.35 tExxK6rC.net
格さんが駄目なら助さんで…
88:デフォルトの名無しさん
15/10/14 12:51:47.73 Zx/eGv5t.net
>>62
Dylan のマルチメソッドを調べてみましたが CLOS 同様に単なる総称関数で特別な工夫はないようです。
そこで、>>46 に質問なのですが、本物のOOPにはマルチメソッドが必要だよ派、
あるいは、第一引数だけ特別扱いはNG派としては、マルチメソッドを記述する際に
どの引数（オブジェクト）の内部情報にアクセスできるようにしたらよいと考えていますか？
あるいは総称関数のように内部情報のアクセスに関しても特別扱いはしないという立場でしょうか？
89:デフォルトの名無しさん
15/10/14 13:07:10.70 oRHV6ndY.net
>>88
つまり、そういうこと
つきつめればOOは面倒な事が沢山起こる
統一理論のようなものは無い
全ては経験則
90:デフォルトの名無しさん
15/10/14 17:15:12.58 D87FbFvB.net
>>89
C言語が嫌いじゃないなら、C言語を統一理論にすれば全て丸く収まる
C言語が面倒ならどこが面倒か理論的に解明してからOOやらないと砂上の楼閣になる
91:デフォルトの名無しさん
15/10/14 20:06:32.48 EqVBJrGR.net
>>90
？
92:デフォルトの名無しさん
15/10/14 21:17:42.32 dBNBVrr+.net
みんなそんなに暇じゃないよ
93:デフォルトの名無しさん
15/10/14 21:25:49.86 oRHV6ndY.net
まぁ真のOOPにマルチメソッドが必要かどうかはおいておいて
第一引数だけ特別扱いするのは対称性の観点から気持ち悪いのはおいておいて
ともかく当面は
RubyにC#並みの静的型のシステムが組み込まれるかどうかだな
当たり前だけど、中途半端な静的型は、有るだけ邪魔で使い物にならない
ジェネリックも何もなくてC言語程度の静的型の機能しか導入されなかったら
今の時代に使い物にならないし、
当時そういう柔軟性の無いC言語の静的型システムが不便に感じたから、こその
Rubyだったわけだから、今更C言語程度の静的型ではダメなのは当たり前、何にもならない
やはり今更静的型を導入するなら動的型言語に負けず劣らずな柔軟性をもった?
C#レベルのを導入しない事には、使い物にならないだろう
それに、中途半端な静的型を実装したら、他の最新の静的型言語と比べられて、
静的型に関して優劣を付けられ、Rubyが不利な立場になってしまうかもしれない
もし、動的型言語で柔軟性が売りのはずのRubyが、静的型の機能や柔軟性で
あの堅物のC++にも劣っていたとしたら、良い笑いものになってしまう
なので、最低限ジェネリックと型推論と、できれば共変性と反変性ぐらいは必要かと
94:デフォルトの名無しさん
15/10/14 21:27:31.95 RZLA+pyr.net
第一引数だけ特別扱いするのは対称性の観点から気持ち悪くても
英語の文法の観点から見れば、極自然なことです。
95:デフォルトの名無しさん
15/10/14 21:29:58.48 RRpWZ3GK.net
日本語でプログラミングしたい派からしても、第二引数以降を前に持ってきて欲しい
96:デフォルトの名無しさん
15/10/14 21:35:31.38 fHrqAp5M.net
プログラミングにわざわざ日本語を持ち込むバカ居るんだな。
プログラムは以下に車輪の再発明を避けて生産性を上げるか、人に再利用しやすいコードを書くか、バグを減らせるか。
こういったことが核になる事なのに、その核をダメにする要素をわざわざ自分の怠慢と劣等遺伝子で持ち込む理由がわからない。
そんな事する位ならプログラミングしない方が世のためになるんじゃ無いかな。
97:デフォルトの名無しさん
15/10/14 21:40:23.30 aRVLWehY.net
プログラミングはプログラミングセンスの欠片もない連中を統率して
なるべくマシなクソを作り上げるゲームだよ
98:デフォルトの名無しさん
15/10/14 21:42:31.55 oRHV6ndY.net
>>94
英語の文法は必ずオブジェクトを一つとると決まっているわけではないと思いますが、どうでしょうかね
第3文型は SVO では、確かにオブジェクトは一つですのでシングルディスパッチですね
プログラミングでは、Cもオブジェクトと考えても良さそうなので、
第2文型の SVC もシングルディスパッチでしょうかね
第1文型の SV はただの関数、静的メソッドですかね
しかし、
第4文型の SVOO はオブジェクトを二つとりますし、これはマルチメソッドが良いんでしょうかね
第5文型の SVOC はOを主体としたシングルディスパッチと捉えるか
Cもオブジェクトと考えてマルチメソッドと捕らえるかは、人によるんですかね
どちらにしても英語の語順は、動詞→目的語、の並びなので
func( arg );のスタイルは英語の語感に合ってるんですよね
obj.method()は寧ろ日本語的な並びですね、～を～する っていう
99:デフォルトの名無しさん
15/10/14 22:33:52.89 aRVLWehY.net
逆だろ
主語と動詞を明確に意識するのはいかにも英語的な感覚だ
引数で述語を修飾しているだけのfunc(arg)の方がむしろ日本語的
100:デフォルトの名無しさん
15/10/14 22:47:46.19 JkkT4x6h.net
>>98
アラン・ケイの「『ソフトウェア工学』は矛盾語法か？」URLﾘﾝｸ(metatoys.org)
にある、「新しいアイデアを学ぶとはどういう事か?」あたりと食い違ったことを改めてここで主張する理由は？
いちおう彼は、OOPの「obj msg」という記法を発案し、英語を母国語とする人なのだけれども…
101:デフォルトの名無しさん
15/10/14 22:48:09.97 D87FbFvB.net
自己責任論の時代に他人を統率するゲームって
102:デフォルトの名無しさん
15/10/14 23:12:04.10 oRHV6ndY.net
>>99
それはないわ
func(arg)はどう見ても命令文じゃないですか
命令を並べて書いておけばバッチ処理してくれるっていう
手続き型の基本じゃ無いですかね
この場合命令する相手はコンピュータなので主語は分かりきっているから
書く必要ないんです
ちなみにobj.method()のobjは主語じゃなくて、どちらかと言うと目的語じゃないですかね
SVOのOってObjectのOでしょ、一応
オブジェクト指向って名前だし、主語指向って言いませんし
103:デフォルトの名無しさん
15/10/15 00:12:43.73 MzOq+ouz.net
>>98
ひゃーこれ分かりやすい。
なるほどオブジェクト指向の文法ってそうだわと膝を打ったので、思わず外野からコメント
104:デフォルトの名無しさん
15/10/15 06:45:48.10 T2FVuNbU.net
上から目線のプログラマが多いね
ユーザのために便利な道具を作る立場なんだけど、勘違いしてるダメな奴
105:デフォルトの名無しさん
15/10/15 07:20:39.98 7x3qta5X.net
×ユーザのために便利な道具を作る
○ユーザーの業務を人質に取って搾取する
便利な道具を作りたかったら特定のユーザーからは距離をとることだ
106:デフォルトの名無しさん
15/10/15 07:22:51.89 lgLg0FTk.net
>>103
こういうのが毛の壁の関数型本とかを「わかりやすい！」とか絶賛するんだろうな…
107:デフォルトの名無しさん
15/10/15 07:41:39.67 7x3qta5X.net
>>100でもはっきり書かれているように、
一般的にオブジェクト指向のレシーバはsubjectだね
奴等の脳味噌には主語と動詞が絶対的な存在として君臨している
主語のないジャパニーズの思考回路で理解しようとしてはいけない
108:デフォルトの名無しさん
15/10/15 07:54:59.40 DZU/K3fq.net
>>102
俺もオブジェクトは主語に喩える方がスッキリすると思う
どうせ比喩の世界だから「オブジェクト」指向の字面に拘る必要はない
そう言えば、むかしエージェント指向なんてのもあったね
109:デフォルトの名無しさん
15/10/15 08:12:38.93 UBpGI0vG.net
ネイティブの奴等は常に主語と動詞がセットでないと気が狂うらしいし受動的な表現を嫌うからな
レシーバは普通に主語だよ
110:デフォルトの名無しさん
15/10/15 09:14:21.36 gCkyElll.net
Smalltalkのセレクタ見てたら主語はともかく動詞ってのはどうかと思うけどな
動詞のようなものもあるけど他の多く（？）は何と言うんだろなこういうの
例：
URLﾘﾝｸ(www.gnu.org)
add: value ←動詞
atAll: keyCollection ←atって何だっけ？
copyFrom: start to: stop
↑こういう複数のやつだとどう考える？fromとtoは無視して動詞と言い張る？
value
↑こういうのはメソッドじゃないから動詞じゃなくていいとする？
それとも都合よく(get value)みたいなのの省略だと考える？
111:デフォルトの名無しさん
15/10/15 09:50:58.72 BaxKs2Tu.net
>>110
>>98 を全否定しているわけではないのだから、まあ、落ち着こうよ。
Object は Object でも、OOPのOは文法要素の目的語であるところのOとは別だというだけ。
とりあえずまず、発案者のアラン・ケイの言う>>100の参照先をベースに話を進めないか？
もしどうしても Smalltalkをベースにしたいなら、やはり彼の書いた The Early History of Smalltalk
URLﾘﾝｸ(gagne.homedns.org) の
「By this time most of Smalltalk’s schemes had been sorted out …」のあたりからがいいだろう。
Smalltalk はちょっとかじったことがあるから、彼の文章でわかりにくいところがあったら訊いてください。
112:デフォルトの名無しさん
15/10/15 10:10:59.25 YhiK7HuV.net
Smalltalk系の「オブジェクト」とは「ソースではない」という意味だ
ソースをemacsで書いてコンパイルする言語とは違う
emacsがなくても動的にメソッドを追加したりできる
113:デフォルトの名無しさん
15/10/15 10:17:49.04 BaxKs2Tu.net
>>98 派がリンク先にアクセスしたら死ぬ病気の人だといけないので、>>100の参照先をコピペしておくよ。
▼新しいアイデアを学ぶとはどういう事か?
このような柔軟な機能はどれだけ複雑である必要があるだろうか? 文法上は決して複雑で無くてもよい。
なじみ深い英語の語順である主語、動詞、目的語(よく前置詞や、たまに暗黙の主語を伴う)があれば
全く十分だ。オブジェクト指向の言い方で言うと、主語はメッセージのレシーバであり、文の残りはメッセージだ
(ここでは「動詞」を強調※して書く)。これで次のような読みやすい形式になる。（※強調は _ でくくった）
3
‘this is some text’
pen _up_
3 _+_ 4
3 _*_ ( 4 _+_ 5 )
car _forward by_ 5
{1 2 3 4 5 6 7} _collect_ [ n | n _odd_ ]
_Repeat_ (1 _to_ 100 _by_ 2) _do_ [ ******* ]
そして大切なのは、この単純な決まりに従って必要なだけ新しく読みやすい記法を作る事が出来る事だ。
これは、ユーザが文法と意味の関係を一つだけ念頭に置いておけば良い事を意味する。
レシーバ メッセージ -- レシーバが意味を把握している事を意味する。
という事で、オブジェクトはただネットワーク上のピア・ピア・サーバのように考えられ、使われると考える。
(これは偶然ではなく、六十年代後期におけるARPAnet から Internet にかけての開発にさかのぼる
アイデアを起源とする)。
従って、動的なオブジェクト指向プログラミングを行うという事は通信しあうオブジェクトでシステムを設計し
構築する事になる。もしもわたしたちのオブジェクトシステムの内部がそれ自体オブジェクトから出来ている
とすれば、必要な構造上の知識は全て知っている事になる。
114:デフォルトの名無しさん
15/10/15 10:35:30.54 a474rjS3.net
確かに、本当に通信し合うオブジェクトを扱うErlangは大規模なサービスで使われてるね
昔はマイナーだったけど、やっぱり本物は残るんだね
一方ニセモノのオブジェクト指向のSmalltalkは死んだね
115:デフォルトの名無しさん
15/10/15 10:56:29.02 YhiK7HuV.net
Smalltalkはコネがない
大抵の言語はC言語のコネがある
ErlangはPrologやSQLのコネがある？
116:デフォルトの名無しさん
15/10/15 11:19:27.13 BaxKs2Tu.net
>>115
現在よく使われ名前が知られた言語等との“コネ”ということなら、Smalltalkにはないはずですよ。
なにせ作られたのが、ここでコネ元として挙げられているC言語と同時期の1972年頃ですから。
強いて挙げればSIMULA67、LISP、Logoですが、これらが今よく知られ使われているかというと
難しいところです。
117:デフォルトの名無しさん
15/10/15 11:31:04.82 BaxKs2Tu.net
>>114
ちょっとググればわかりますが、Smalltalkはまだ死んではいないようですよ。
Squeakやそこから派生したPharoなどのコミュニティは比較的活発ですし、
ゼロックス謹製のSmalltalk-80の直系であるCincom社のSmalltalkでVisualWorksという
商用の処理系もあるようです。ファンお手製のGUIを持たない変わり種のGNU Smalltalkや
altJSとしてのAmber Smalltalkもあるようです。
もっともアラン・ケイはもうすでにSmalltalkへの興味を失っていて、Rubyの生みの親のMatzにも
そんなことを漏らしていたようで、Smalltalk(er)を目の上のこぶみたいに煙たがるMatzが大喜びする
一幕もあったようです。URLﾘﾝｸ(www.rubyist.net)
ちなみにアラン・ケイはGUI付きのOSを２万行程度で記述できる次の言語の実験に取りかかっているようです。
「Smalltalk 勉強会@名古屋 STEPS プロジェクトご紹介」
URLﾘﾝｸ(d.hatena.ne.jp)
「STEPS プロジェクトご紹介その２」
URLﾘﾝｸ(d.hatena.ne.jp)
118:デフォルトの名無しさん
15/10/15 11:50:07.59 N9hEQVX6.net
> GUI付きのOSを２万行程度で記述できる次の言語の
OSを作る人は極僅かなんだから、別の研究すればいいのに。
にしても、OSは行数2万行です。ただし言語にドライバが含まれています。
とかそういう落ちだったりしてｗ
119:デフォルトの名無しさん
15/10/15 12:03:22.06 BaxKs2Tu.net
>>118
> OSを作る人は極僅かなんだから、別の研究すればいいのに。
OSを含め、自分たちが利用するソフトウエアの仕組みを知り、自由に改変・拡張でき、
できれば最初から作り上げることすらできる世界が彼の理想であり、主張するコンピューターリタラシーな
わけですから、そこはDynabook、その暫定OSとしてのSmalltalkのときからぶれていませんね。
> ただし言語にドライバが含まれています。とかそういう落ちだったりしてｗ
リンク先を読んでもらえばわかりますが（他人のリンク先読むと死ぬ病気の人？^^;）、
ミソはPEGベースのパーザーでDSLを手軽に作れるようにして、階層的にコードの抽象度を上げるところらしいです。
120:デフォルトの名無しさん
15/10/15 12:31:43.88 BaxKs2Tu.net
>>112
> Smalltalk系の「オブジェクト」とは「ソースではない」という意味
気になったのでちょっと調べてみましたが、Smalltalk のオブジェクトは、SIMULA67の言語機能としての
オブジェクトから来ていて、そのSIMULA67のオブジェクトは、ホーアのレコード・オブジェクト
URLﾘﾝｸ(archive.computerhistory.org) [PDF注意]
1. Basic Concepts
1.1 Objects and Records.
A fundamental feature of our understanding of the world is that
we organise our experience as a number of distinct objects (tables and chairs,
blank loans and algebraic expressions, plynominals and persons, transistors
and triangles, etc); and our thought, language, and actions abased on the
dsignation, description, and manipulation of these objects, either indivisually
or in relationship with other objects.
のオブジェクトから来ているので、C言語とかのオブジェクトの意味合いよりは、文字通り「物」としての
オブジェクトに近いみたいですね。
121:デフォルトの名無しさん
15/10/15 12:46:45.96 N9hEQVX6.net
>>119
> ミソはPEGベースのパーザーでDSLを手軽に作れるようにして、階層的にコードの抽象度を上げるところらしいです。
いえ、そんなのはどうでもよくて、ドライバを誰が作るのかって話ですね。
ドライバの行数はOSに含まれています。
あと言語が多くのライブラリを提供するのであれば、
そりゃOSの行数は減るでしょう。
122:デフォルトの名無しさん
15/10/15 12:53:29.51 YhiK7HuV.net
>>120
we organise our experience as objects and language
オブジェクト != 言語 という前提があるよね
123:110
15/10/15 13:23:04.01 E/Ij5YUU.net
>>111
> >>98 を全否定しているわけではないのだから、まあ、落ち着こうよ。
> Object は Object でも、OOPのOは文法要素の目的語であるところのOとは別だというだけ。
なんか人違いしてない？>>98を否定もなにも
俺はむしろ目的語のOのほうがなじみが無いんだが
かつてぼんやりobj.methodを主語＋動詞みたいに考えてた
けど今はobj.methodはやっぱ単にobj+methodだなって思うだけ
あえて言うならobjが主語ってのはまだわかるが…ってのが>>110
124:デフォルトの名無しさん
15/10/15 17:17:29.28 BaxKs2Tu.net
>>123
それは失礼いたしました。
唐突に Smalltalk のコードをひっぱり出してきて疑問符を連発されていたので
てっきり >>98 派がファビョってきたのかと勘違いしました。ごめんなさい。
125:デフォルトの名無しさん
15/10/15 17:25:35.28 BaxKs2Tu.net
ちなみに念のため、アラン・ケイはメッセージ式 rcvr msg の msg が動詞でなければならないとは
ひとことも言っていないと思いますよ（>>113 ）。SVO の S を rvcr、VO 以降を msg に当てはめると
すっきり書けて読みやすい、というような趣旨のことはいっていますが…
ですから、メッセージが atAll: keyCollection でも copyFrom: start to: stop でも
value でも、必ずしも動詞のみでなくても、さらに動詞が含まれなくてもかまわないと思います。
126:デフォルトの名無しさん
15/10/15 17:35:42.93 BaxKs2Tu.net
>>125
メソッド名をどのようにしたらよいかという観点からは、ケント・ベックがいろいろと試行錯誤しているので
興味のある向きは彼の著作を読んでみると面白いかと思います。
「ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集」
URLﾘﾝｸ(www.amazon.co.jp)
同書原書のドラフト 「Smalltalk Best Practice Patterns Volume 1: Coding」
URLﾘﾝｸ(stephane.ducasse.free.fr) [PDF注意]
同書をJava向けに書き直したもの 「実装パターン」
URLﾘﾝｸ(www.amazon.co.jp)
127:110
15/10/15 18:47:55.64 USDIK8mq.net
>>125
> ですから、メッセージが atAll: keyCollection でも copyFrom: start to: stop でも
> value でも、必ずしも動詞のみでなくても、さらに動詞が含まれなくてもかまわないと思います。
うん。メッセージ、という表現だけで十分だと思う
英文法をモデルにするより巧妙な抽象化だと思う
そこにどんな品詞が来たって平気だし
実際すでに来ちゃってるんじゃないのかな
obj.methodのmethod部分にすらも
128:デフォルトの名無しさん
15/10/15 19:45:08.84 whFEoHyO.net
アランケイの妄言なんかどうでも良いだろう
普通メソッド名は動詞にすることが多いんだから、動詞的な何かでよいだろう
実際に実行するわけだからイメージと合う
ところで実際に実行するのはコンピュータなのでオブジェクトを主語に見立てる必要性はまるで無い
「オブジェクトが実行する」と考え直すことで、何か問題が解決されるわけでもないし、
静的メソッドやC/C++に見られるような何にも属さない普通の関数は、
オブジェクトが無いのに、一体誰が実行していると考えればよいのか？
という新たな問題を生み出すだけなので
単純に、実行するのはコンピュータでオブジェクトが実行する内容を知っている
とでも考えておけばよいだろう
実際のコンピュータの動作に則した考え方なので、破綻が無い
129:デフォルトの名無しさん
15/10/15 19:57:15.22 whFEoHyO.net
オブジェクト指向はオブジェクトが自身の振る舞いを知っている、という考え方をする
実際に振る舞いを実行するのはコンピュータとかCPUとかスレッドとかの外的なもので問題なく
単にオブジェクトは自分の振る舞いを知っていさえすればよい
130:デフォルトの名無しさん
15/10/15 19:58:24.13 J9V5fg8t.net
uyが昔書いたrubyのOSはコア部分2000行です
2万? バカには無理
131:デフォルトの名無しさん
15/10/15 20:45:22.36 J9V5fg8t.net
PHP7が従来のPHPの2倍速になってるらしいけど
他のLLが速度そのままなら今って速度的にはPHPが一番速いんじゃ？
執拗にrubyを回避してPHPばかり高速化させてる池沼エンジニアたちの正体って何なの？
132:デフォルトの名無しさん
15/10/15 20:56:47.79 6DA7kr5U.net
>>130
uyってまだいたのか
133:デフォルトの名無しさん
15/10/15 21:12:30.81 J9V5fg8t.net
まだいたよ
自分がプログラミングの勉強しているときに
散々お前らが間違った知識を2chに垂れ流していたせいで
プログラマクラスタの勝ち組ではなく
世界全体クラスタの勝ち組になりつつある
uyにはプログラミングをファッションとして行う程度の余裕があるのです
134:デフォルトの名無しさん
15/10/15 21:15:13.49 28aQIEIe.net
>遠隔操作で縦列駐車も、三菱電機が自動運転システム
三菱電機が電機メーカーならではの自動運転を実現しました
>自動運転技術に電機メーカーも参入、「未来の車」課題は？
URLﾘﾝｸ(youtu.be)
三菱とかトヨタとかGoogleとか自動運転テクノロジーに使われるプログラミング言語ってやっぱり組み込みだからC言語とかなのかな？
まあこういうのってソフトよりハード技術の方がより重要なんだろうけど
135:デフォルトの名無しさん
15/10/15 21:16:55.47 YhiK7HuV.net
>>129
オブジェクトは自身の振る舞いを知っている
関数も自身の振る舞いを知っている
オブジェクト指向は「関数は低レベル」という考え方をする
高レベル関数とか発明したらキャラが被るから関数はあくまで低レベル
136:デフォルトの名無しさん
15/10/15 21:19:09.27 whFEoHyO.net
それがなにか？
137:デフォルトの名無しさん
15/10/15 21:30:07.99 N9hEQVX6.net
> オブジェクトは自身の振る舞いを知っている
果たしてそうだろうか？
例えば、紙があったとする。
紙は自分の振る舞いを知っているのだろうか？
水に濡らすと→柔らかくなる
火をつけると→燃える
針で挿すと→穴が空く
折り曲げると→紙飛行機になる
違う折り方をすると→兜になる
これらはオブジェクト自身が知っていることなのだろうか？
138:デフォルトの名無しさん
15/10/15 21:40:36.50 7x3qta5X.net
>>137
少なくともオブジェクト自身の性質に由来する現象だろう
意識の有無は無生物主語だらけの英語ワールドでは問題にならない
139:デフォルトの名無しさん
15/10/15 21:57:23.96 YhiK7HuV.net
>>137
振る舞いへのポインタを保持とか、低レベルな言葉を使ったら死ぬ病気なので
140:デフォルトの名無しさん
15/10/15 22:01:06.60 whFEoHyO.net
いやむしろ>>137は有る程度正しい考えなのでは？
コンピュータやプログラミングの基本は数値計算だけど、
足し算を考えた時、例えば1+2で、1や2自身は足し算についてのルールを知っている必要が有るのだろうか
+という演算子が足し算の性質を知っていて、1や2に適用した結果、足し算の法がうまれ、
自身と他の整数の間に関係性が生まれ、整数の性質が浮かび上がるのではないだろうか
ある物の性質というのはいつも相対的で、その物そのものだけで勝手に決定されるものではなく、
他の物との相互作用の結果として、周りから与えられるものではないだろうか
例えばuyが自分自身の性質を決定するために
「世界全体クラスタの勝ち組になりつつある」と明言したとして(>>133)、それに何の意味が有るだろうか
uyの社会的立ち位置は、uyが決める事ではなく、他の人との相互作用の結果として
周りから、社会から、与えられるものではないだろうか
しかし、オブジェクト指向では
>オブジェクトは自身の振る舞いを知っている
と考えるのが前提なので、今回はあえて言及しなかった
マルチメソッドではもうちょっと違った見方も出来ると思うが殆ど採用されてないね
141:デフォルトの名無しさん
15/10/15 22:05:02.72 N9hEQVX6.net
>>138
確かに分子、原子レベルで見たら、
オブジェクト自身の性質だろう。
だが、オブジェクト自身の性質にもとづき
物理法則に従って、変化は起きる。
この物理法則というのは、オブジェクト自身が持っているものだろうか？
例えば、質量はオブジェクトの性質だろうが、
そこには速さを加えた時の運動エネルギー、
つまり「物体の運動エネルギーは、物体の質量と速さの二乗に比例する」
という法則はオブジェクトが持つべきものだろうか？
142:デフォルトの名無しさん
15/10/15 22:14:14.69 whFEoHyO.net
マルチメソッドがあれば、>>141みたいな人も納得させられるオブジェクトの理論体系が出来上がるんだが
これはこれでカプセル化や組み合わせ爆発や実行速度なんかで問題が有るんだよね
だから殆どの言語がシングルディスパッチというのもあるし
日本人は農耕民族で土地とか利権に拘る縦割り行政主義だから、そのほうが分かりやすいってのもある
>物体の運動エネルギーは、物体の質量と速さの二乗に比例する
これはつまり物理法則とかの法のようなものが働いて
相対的にオブジェクトの性質を決定付けているという考え方
法のようなものは手続き型言語では関数なので
マルチメソッドで
method( obj1, obj2 )
として、obj1とobj2の間の関係を決定する事ができれば、
他者との関係に基づいて性質が決定するっていうノリが実現できるので
>>141のような人も納得なわけだ
こういうのを機能主義という 機能=function=関数 だからね
143:デフォルトの名無しさん
15/10/15 22:17:44.71 whFEoHyO.net
しかしそういった言葉遊びはともかく、
当面はRuby3.0にどういった形でどの程度のデキの静的型が導入されるかだな
どう考えてもうまくいきそうに無いが、matzがやるといっている以上はやるのだろう
144:デフォルトの名無しさん
15/10/15 22:28:40.59 gTKnbHZq.net
> matzがやるといっている以上はやるのだろう
え…Matzがやると言ったことで放棄されたor放置されているものはかなりあるぞ…
「オープンソースで前に進むためには燃料が必要」と言ってるぐらいなんだから、
ただの燃料ぐらいに思っておかないと
145:デフォルトの名無しさん
15/10/15 23:06:58.05 J9V5fg8t.net
型を入れるコンセプトが
速度を上げる事なのか
コードセキュリティの為なのかだよ
後者だったらいらね
146:デフォルトの名無しさん
15/10/15 23:33:19.63 mn0BrUjG.net
速度は結局エンジンに書けた労力しだいとmatzは言ってる。
動的型でもV8は速いし、そのV8の資産と経験を十分に活かせるはずのDartは
結局当初の目的の２倍高速を実現できずに敗れた。
そして何よりも、機械が出来ることは全部機械にやらせて人間は楽をすべきという
Rubyのポリシー上、多少早くなるからという理由で型を入れるということは絶対にしない。
147:デフォルトの名無しさん
15/10/15 23:49:48.72 XerH+8kv.net
>>145
速度を上げるためという名目でやるが
実際に一番有効活用できるのは可読性の向上だろう。
コメントで型を書くよりも、コードで型を書いたほうが
同期が取れるし正確になる。
148:デフォルトの名無しさん
15/10/15 23:54:07.96 whFEoHyO.net
機械ができることは全部機械にやらせて人間は楽すべき、なレベルで
型チェックをコンパイラに任せつつ、柔軟性を確保するには、
ジェネリックなどの機能が無いと上手く機能しないわけだが、用意できるのか心配だね
C#も割りと早いバージョンで実装してたし
結局Javaもジェネリックを導入したし
静的型には必要な代物なのだろう
C言語レベルの柔軟性の無い静的型に不満があってRubyを動的型にしたわけだから
今更C言語レベルの柔軟性の無い静的型を導入したら最早意味が分からないことになるしな
149:デフォルトの名無しさん
15/10/16 00:05:31.68 N+EJJaaq.net
静的型の観点から言えば、型はなるべく書くべきってことになるし
Rubyに静的型が導入されたら、やっぱり折角導入して、そういう機能があるわけだから
可読性や安全のためにも型はなるべく書くべきって事になると思うんだけど
そういう要求に答えつつ、今までのRubyの世界観も維持するためには
相当柔軟性の高い凝った静的型システムが必要だと思うんだけど
どういうものを出してくるか楽しみでは有る
少なくともジェネリックは欲しいところではある
150:デフォルトの名無しさん
15/10/16 00:15:13.00 VBzgHbv/.net
いまごろになって静的型を入れるんだから、
C#等から古くさいジェネリクスをパクるより
Haskell等から型クラスをパクってほしい
151:デフォルトの名無しさん
15/10/16 00:28:18.89 +z0qI3+p.net
速度を上げたいだけならprivateメンバのみ静的型という手があるが
152:デフォルトの名無しさん
15/10/16 07:20:28.43 EA3T5rKJ.net
自己満足の議論だね
153:デフォルトの名無しさん
15/10/16 07:24:30.36 yoBqthc9.net
Smalltalkに静的型チェックを導入したStrongtalkは速かったが、あれの速さは
後にJava HotSpotやJSのV8で使われた爆速のVM技術を彼らが持ってたからで
静的型チェックの有無とは無関係だった。
今のRuby開発陣に、機能を削らずにRubyをこれ以上速くするのは無理じゃないかな。
まして、型推論なんて機能を追加した日にゃ、再び爆遅処理系に後戻りするのは必至。
154:デフォルトの名無しさん
15/10/16 07:26:41.14 pM+jfY6O.net
Rubyの問題はクラスの実装方法にあるので、
静的解析の可能な仕様に変更するならそれはもはやRubyと全く互換性のない別言語
従って「Rubyに静的型を導入」という前提は無意味である
はい終了
155:デフォルトの名無しさん
15/10/16 09:21:29.48 Wb9pxNM+.net
静的型付と静的解析は関連はしているが必要・十分の関係ではないでしょ。
156:デフォルトの名無しさん
15/10/16 13:17:02.59 3DK9u+XT.net
おっRuby談義熱くなってきたね
やっぱこうでなくっちゃね、なんせ唯一無二の世界で通用してる国産言語なのだからさ
157:デフォルトの名無しさん
15/10/16 13:30:03.77 l04muiBk.net
果たして通用しているんだろうか？
158:デフォルトの名無しさん
15/10/16 16:04:11.56 4XmsRPEG.net
作業効率化において現状これに勝てる言語はまだない
何の言語で開発するにしても必ずrubyは連れ歩く
まさかこのスレでmakefile使ってる奴なんていないよな？
159:デフォルトの名無しさん
15/10/16 16:16:40.86 l04muiBk.net
makefileも使ってる(正確にはあるだけど)よ？
このスレが対象にしてる言語だけじゃ仕事にならないカテゴリなんでね
160:デフォルトの名無しさん
15/10/16 21:33:20.74 +G3m5iUJ.net
githubのatom有能杉内？
今日terapadを窓から投げ捨ててきたよ
161:デフォルトの名無しさん
15/10/16 21:44:24.38 pM+jfY6O.net
さすがにそれはatomが特に有能というよりまともなプログラミング用エディタを使ったことがないだけでは
162:デフォルトの名無しさん
15/10/16 21:57:07.09 ZoTRSHay.net
まともなプログラミング用エディタというのは
デフォルトでプログラミング用に最適化された
エディタであって欲しい。
163:デフォルトの名無しさん
15/10/16 22:22:34.47 C0FkHDSz.net
普通に考えたらEmacsかViの二択だよなぁ
164:デフォルトの名無しさん
15/10/16 22:35:29.05 ZoTRSHay.net
EmacsもViもキーバインドが特殊すぎて。
165:デフォルトの名無しさん
15/10/16 22:37:30.93 C0FkHDSz.net
>>164
それだけテキスト編集に特化してるんだよ
つまり慣れれば最強ってこと
166:デフォルトの名無しさん
15/10/16 22:44:20.85 f/Epc6uW.net
>>161
atomが良いとか好きとか普通にいえばいいのに、有能とか違う意味の言葉を使ってしまう
そういう現象もあるらしい
167:デフォルトの名無しさん
15/10/17 00:02:19.39 mzjdQH44.net
>>165
それは違う。
viは開発者が当時使っていたキーボードにカーソルキーがなくて
代わりにjkhlに割り当てられていただけ
emacsは単なるアルファベットの頭文字
配置に意味があるわけじゃない。
168:デフォルトの名無しさん
15/10/17 01:00:49.82 OT5GhlDm.net
今の配置を変えればもっと良くなるか悪くなる
悪くなったら元に戻せばいいだけなので必然的にメリットしかない
これは偶然ではない
169:デフォルトの名無しさん
15/10/17 01:19:12.33 kV08E+NU.net
vi好きです。他のエディタを使う事が出来ないカラダになってしまいました
170:デフォルトの名無しさん
15/10/17 01:43:03.31 97BJbcDl.net
sublimetext一択でそ
171:デフォルトの名無しさん
15/10/17 01:44:43.56 FN3G7dO/.net
vimと普通のwinメモ帳系のエディタだな
emacsはメモ帳系が使えなくなって仕事に支障をきたすのでやめた
172:デフォルトの名無しさん
15/10/17 10:08:12.92 OT5GhlDm.net
問題があるとすれば、デフォルトより良い設定を自分だけの秘密にするのは何故か
その設定が良いという証拠が見えないから
証拠を見せるには初期設定から全てやり直して見せるしかない
つまり、証拠はないけど良いってこと
173:デフォルトの名無しさん
15/10/17 10:54:12.76 6bVjpFvg.net
今度はエディタの話か
ひとそれぞれって答えが妥当なものばかり
174:デフォルトの名無しさん
15/10/17 11:25:24.16 KBdUYWvy.net
熟練者にとっては人それぞれでいいんだよ。
自由にカスタマイズすればいい。
初心者の取っ掛かり、一番初めのスタートラインだけは
高い位置（つまりカスタマイズ無しでも使いやすい）で
共通化してくれ。
175:デフォルトの名無しさん
15/10/17 11:27:44.54 u6HpNLYA.net
>>174
EmacsもViもこれだけ普及してしまった以上、もういまさら無理だよ
176:デフォルトの名無しさん
15/10/17 12:23:26.01 KBdUYWvy.net
>>175
嘆かわしいことですね。
誰かEmacsやviに代わる端末内で動作する
エディタ作りたいって人いないかなぁ。
177:デフォルトの名無しさん
15/10/17 15:01:30.96 u6HpNLYA.net
>>176
EmacsやViは普及してるので、何か新しい言語なりが出てきても誰かがソッコーで
対応してくれる
利用者の多さが利便性の向上につながり、さらに利用者を増やすという循環が
できてしまってるからね
いまからこれを覆そうとするには相当機能的に優れているか、相当金をつぎ込むか
どちらかじゃないと無理だね
178:デフォルトの名無しさん
15/10/17 15:13:26.97 KBdUYWvy.net
> 何か新しい言語なりが出てきても誰かがソッコーで対応してくれる
syntax highliterなら、ライブラリがありますよ。
179:デフォルトの名無しさん
15/10/17 15:18:28.66 u6HpNLYA.net
>>178
EmacsやViでプログラミングしたことあるなら、そんな個別の事柄を挙げても何の意味もないことは
すぐに分かりそうなものだが…
180:デフォルトの名無しさん
15/10/17 15:21:30.72 wx6tLFnT.net
というより俺はそもそも>>176が何を言いたいのか分からない
emacsやviに不満を持つ奴ってどんな夢のような高性能エディタ使ってんだろう？
181:デフォルトの名無しさん
15/10/17 15:29:33.14 KBdUYWvy.net
>>180
重要なのは"高性能"エディタじゃないよ。
使いやすいエディタ。
182:デフォルトの名無しさん
15/10/17 15:32:05.22 u6HpNLYA.net
>>181
エディタに何を求めてるの？
プログラミングやるなら高性能は使いやすさに直結するんだけどさ
プログラミング以外のエディタの話だというなら、スレ違いじゃね？
183:デフォルトの名無しさん
15/10/17 15:33:52.66 ceT/tJ4E.net
>>181
ちなみに>>176本人？
本人じゃないなら答えなくていいけど
使いやすいエディタって例えば何？
184:デフォルトの名無しさん
15/10/17 15:34:43.12 KBdUYWvy.net
>>182
学習コストの低さ。
いくらエディタが高性能でも、その機能を使うまでの
学習コストが高ければ、使われなくなる。
高性能であることは当たり前で、それをどれだけ
簡単に使えるかが今の時代で要求されているレベル。
185:デフォルトの名無しさん
15/10/17 15:35:45.79 KBdUYWvy.net
>>183
Sublime textやAtom
186:デフォルトの名無しさん
15/10/17 15:40:52.02 u6HpNLYA.net
>>184
> 高性能であることは当たり前
残念ながら、この当たり前を実現できているエディタがEmacsやVi以外にほとんどないのさ
なぜならば、両者には長い歴史があってノウハウも豊富で、かつ多くの利用者がよってたかって
プラグインを開発してきているから
後発のエディタはその歴史と利用者の２つの壁を超えなければならず、無理ゲーとなっている
187:デフォルトの名無しさん
15/10/17 15:41:08.63 m81ysFVA.net
viってカスタマイズとかいらなくね
emacsは必須だろうが
188:デフォルトの名無しさん
15/10/17 15:48:50.56 tbAeg9G6.net
>>185
> Sublime textやAtom
レスとん！
へー聞いたことすら無いけどemacsより使いやすいのか
機会があったら触れてみるわ
189:デフォルトの名無しさん
15/10/17 16:09:39.79 KBdUYWvy.net
>>186
たいしてプラグインなんか使ってないだろｗ
使えない部分を、まともにするものか、
専門ツールに任せろよ的なことばかりだろ？
190:デフォルトの名無しさん
15/10/17 16:10:25.80 KBdUYWvy.net
そもそもプラグインが大量に必要な時点でおかしいんだよね。
全部標準搭載すればいい。
191:デフォルトの名無しさん
15/10/17 16:13:28.83 u6HpNLYA.net
>>189
AtomやSublimeTextもプラグイン前提のエディタなんですがそれは？
192:デフォルトの名無しさん
15/10/17 16:15:19.04 0GQ640b+.net
>>187
viもキーボード配列に因縁をつけられるのでカスタマイズ機能は役に立つ
因縁をつけられるまでがUXです
193:デフォルトの名無しさん
15/10/17 18:54:21.75 /7+5znpF.net
>>184
その理屈、いまだにCOBOLを使い続けていたり頑なにオブジェクト指向から目を背けていたりする連中と全く同じなんだよな
目先の仕事に追われて効率化のための投資をしない、典型的な無能
194:デフォルトの名無しさん
15/10/17 19:18:33.62 pib/Nfzj.net
>>193
まったくだね。いつまでも古い言語（道具）を使ってないで
もっと効率化したものに乗り換えよう！
195:デフォルトの名無しさん
15/10/17 20:48:11.04 6bVjpFvg.net
道具って人とか熟練度で使いやすさは違うと思うが
196:デフォルトの名無しさん
15/10/17 20:50:08.57 XvNYZLvx.net
やはりプログラミング向けエディタと言えば補完機能が大事では？
197:デフォルトの名無しさん
15/10/17 20:57:04.41 uNJQ9dbe.net
未来永劫その時俺が望む機能が完成した形で目の前にある事が保証されるのならば
馬鹿馬鹿しくて学習の為のコストなんかかけてられない
だけどその望みを実現する事が不可能である事が分かっているから
コストをかけても全てを支配下におけるツールの使い方を学習する
198:デフォルトの名無しさん
15/10/17 20:59:52.51 pib/Nfzj.net
学習コストをかけるかどうかじゃなくて、
学習コストが高いのが問題って話なんだけどな。
目的はどちらでも達成できるなら、
学習コストが低いほうがいいのは当たり前なわけで。
199:デフォルトの名無しさん
15/10/17 21:08:44.70 uNJQ9dbe.net
>>198
で、その学習コストが低いやつは、俺が望む機能をいつでも提供してくれるのか？
200:デフォルトの名無しさん
15/10/17 21:11:01.56 pib/Nfzj.net
>>199
学習コストが高くても、俺が望む機能をいつでも提供してくれないので、
それはなんの反論にもなってない。
201:デフォルトの名無しさん
15/10/17 21:12:07.24 uNJQ9dbe.net
>>200
> コストをかけても全てを支配下におけるツールの使い方を学習する
202:デフォルトの名無しさん
15/10/17 21:18:02.91 pib/Nfzj.net
全てを支配下におけるツールは存在しない。はい論破ｗ
203:デフォルトの名無しさん
15/10/17 21:18:39.87 mlPlTlFa.net
>>200
またまた、本当は望みの機能なんて無いくせにw
204:デフォルトの名無しさん
15/10/17 22:01:35.64 u6HpNLYA.net
>>193
その分野で代替のものがないならば、そうするしかない
科学技術計算でFORTRANが未だに現役なのも、FORTRANに代わるものがないからだ
過去に蓄積された膨大なノウハウやライブラリが他を圧倒している以上、それを使うのが最も
問題を解決するのにふさわしいと思われているから現役なのだ
エディタも同じで、学習コスト云々の前に、自分の開発効率を最も高めてくれるのはどれだ
という観点で物事を見なくてはいけない
その結果選ばれるがEmacsであり、Viなのだ
学習コストの低さがご希望なら、最初はAtomとか使っておけばいい
優秀なプログラマならそのうち自然とEmacsやViに興味が移るよ
205:デフォルトの名無しさん
15/10/17 22:17:21.19 6bVjpFvg.net
自分の開発効率を最も高めてくれるのは、自分にあった道具
人によってはatomかもしれないし、vimかも知れない
学習コストを考えるかどうかもその人の状況での話で、お前らの都合で決める筋合いではない
206:デフォルトの名無しさん
15/10/17 22:21:07.78 HjqN8fv+.net
学習コストってのを大袈裟に数えすぎじゃね？ｗ
気持ちよく使えるくらいまで学習するとして
比較した場合、三日と三年みたいな深刻な差はねーだろ？ｗ
実質、せいぜい倍くらいのもんじゃねえの？
そして最大でも30時間くらいありゃマスターじゃねえの？
学習コストを大袈裟に言うひとは
ここらへんをハッキリさせたくはないんだろうけど
207:デフォルトの名無しさん
15/10/17 23:37:15.94 0GQ640b+.net
学習コストを時間であらわすのは人月の神話と同じ
ここがム板じゃなかったら気付くまでに何年かかっただろうか
208:デフォルトの名無しさん
15/10/17 23:40:29.71 wBRaFA3P.net
じゃあ学習コストは何であらわして比較するの？
学習コストの低さに拘ってる人いるけど
209:デフォルトの名無しさん
15/10/18 00:30:19.03 JFtsAugF.net
プログラミング初心者でもMacVim使いこなせますかね？
210:デフォルトの名無しさん
15/10/18 00:49:24.92 EztmzLmu.net
>>209
Vimぐらい有名ドコロであれば、慣れれば問題なくいけると思うよ
211:デフォルトの名無しさん
15/10/18 06:28:41.31 k26UA5Iq.net
>>206
エディタってのを大袈裟に数えすぎじゃね？ｗ
エディタ比較した場合、三日と三年みたいな深刻な差はねーだろ？ｗ
212:デフォルトの名無しさん
15/10/18 06:41:24.20 2izk1DSP.net
三日と三年どころか、一瞬と永遠だからな。
vimやemacsを使いこなせるかどうかでプログラマーの資質が分かる。
どちらも自分に向いてないと思った人はプログラミングを続けても将来性はないよ。
趣味にとどめておくならやめろとは言わんが。
213:デフォルトの名無しさん
15/10/18 06:45:39.53 k26UA5Iq.net
お前の資質と将来性の程度がよくわかるね
214:デフォルトの名無しさん
15/10/18 09:40:48.33 UcI/5vQY.net
emacsの作者でさえそんな古くしいもん捨てちまえと言ってるのに
215:デフォルトの名無しさん
15/10/18 09:49:24.48 FU6fHshJ.net
emacsはエディタというよりシェルだからな
純粋にエディタとしての使い勝手が評価されてるわけじゃないので、
atomなどの他のシェルにも必要なプラグインさえあれば問題なく移行できる
対してvimは入力道具だから根強く残るだろうけど
216:デフォルトの名無しさん
15/10/18 11:55:26.86 WvPHJe2x.net
キーバインドがEmacs/vimと、それ以外のアプリ・OSで違い過ぎるのって致命的じゃね？
使い続けててもショートカットキーで頻繁にミスりそう
217:デフォルトの名無しさん
15/10/18 12:07:26.70 486ZuQ8x.net
viはのこってもvimはどうかな
218:デフォルトの名無しさん
15/10/18 12:08:25.42 usHUNN/I.net
あんがい簡単に使い分けられるものですよ
219:デフォルトの名無しさん
15/10/18 14:28:20.72 EztmzLmu.net
>>216
ほとんどミスらないよ
普通に切り替えられる
220:デフォルトの名無しさん
15/10/18 14:36:35.50 W+pOLtWX.net
でも、vim使っている人は、新たにemacsを覚えないと
使えないんだよね？ その逆も同じ。
カーソルの移動や保存、終了のレベルで使えない。
Windowsのテキストエディタならそんなこと無いのに。
221:デフォルトの名無しさん
15/10/18 14:42:30.31 diScBqxL.net
sublime textの勢いが半端ないみたいなんだけど？
222:デフォルトの名無しさん
15/10/18 14:43:24.83 EztmzLmu.net
>>220
Emacsを覚えようとする気持ちがあるならそんなレベル５分で突破できるよ
viはUnix系のOS触る人なら最低限の使い方はみんな知ってるはずだし
223:デフォルトの名無しさん
15/10/18 15:22:56.89 W+pOLtWX.net
別にEmacs以外でやれるなら、Emacsを覚える必要はない。
224:デフォルトの名無しさん
15/10/18 15:26:02.66 2izk1DSP.net
やらない言い訳を考えるような奴はやっても結局物にならない
225:デフォルトの名無しさん
15/10/18 15:27:16.57 NglnuKc2.net
EmacsよりもMac使いこなした方が楽だよね。
226:デフォルトの名無しさん
15/10/18 15:27:19.70 TlCj8Nex.net
EmacsよりもMac使いこなした方が楽だよね。
227:デフォルトの名無しさん
15/10/18 15:50:50.92 W+pOLtWX.net
やるやらないの目的がEmacsになってる時点で
手段と目的が逆になってるんだよな。
228:デフォルトの名無しさん
15/10/18 16:10:15.43 8PmYf0zQ.net
エディタバトルロワイヤルってスレでも作ってそっちでやれよ
スレタイと全然違う論争でどんだけスレ消費するつもりだ
229:デフォルトの名無しさん
15/10/18 19:15:38.10 dvIcABTP.net
エディタのプラグインを書く言語が気に入らないんだろう
シェルスクリプトは他のOSで使いにくいから汎用言語に移行できたが
230:デフォルトの名無しさん
15/10/18 19:39:27.42 W+pOLtWX.net
あぁ、プラグインの言語は今ならJavaScriptがいいだろうね。
231:デフォルトの名無しさん
15/10/18 19:47:33.21 k26UA5Iq.net
もともとpythonとかjsとかで書けるエディタがいろいろあるだろ
232:デフォルトの名無しさん
15/10/18 19:52:50.28 UPMG2BEU.net
> シェルスクリプトは他のOSで使いにくいから汎用言語に移行できたが
？
233:デフォルトの名無しさん
15/10/18 20:47:36.88 dvIcABTP.net
この？も「わからない」という意味ではなくわざと違う意味の言葉を使う現象らしい
234:デフォルトの名無しさん
15/10/18 20:51:59.36 x9iaqQ6Z.net
>>233
？
235:デフォルトの名無しさん
15/10/18 22:09:03.27 KCA3bqXn.net
まぁ、プログラミング言語語る前に日本語ができてない馬鹿が多いからな日本人。
英語もできて初めてプログラミング言語とか語ってほしいわ。
あと、なぜその言語が良いのかの説明も無い奴はバカかな。
Emacsで出来ることはMacの既に備わってる機能で同じような事が出来るし、場合によっては適材適所な使い方をした方がいい。
EmacsもVimも標準でMacに搭載されているがエディタという意味ならVimの使い方を一通り専念した方がいいんじゃ無いかな。
適材適所でVim使うわけだから局地的な使い方しかし無いわけだからAtomでもSublime TextでもEmacsでも誰でも同じだと思うね。
あとは見栄えがどうかぐらいじゃね？
つまりEmacsが歴史も拡張性も高いもしれないが、
Emacsを拡張しまくって重くして何でもかんでもこなす時代じゃないということ。
それに後出しのソフトウェアの方が最新のハードウェアにとって適切であったり程よい妥協点を選んでる可能性もあるから、
Atom EditorとかSublime Textでいいんじゃ無いかな。
同じ壁にぶつかったり自分にとって解決してほしい問題を既に解決した人がブログか何かに書いてる可能性も高いし、
Emacsはクソだね。
236:デフォルトの名無しさん
15/10/18 22:12:39.42 EztmzLmu.net
AtomはEmacsと同等か、むしろそれより重いソフトなんだけどなぁ…
それはおいといて、好きなのを使えばいいと思うよ
色々なエディタを渡り歩く人もいるわけだし、そのときどきのやりたいことや気分や好奇心で新しいエディタを
使いはじめるのもアリだしね
237:デフォルトの名無しさん
15/10/18 22:19:07.53 4hS3opoA.net
>>235
>まぁ、プログラミング言語語る前に日本語ができてない馬鹿が多いからな日本人。
スレタイも読めない自称日本人も増えたしね
238:デフォルトの名無しさん
15/10/18 22:56:52.14 yFvCCm+o.net
>>235
長い文章だな。プログラムも簡潔に書けないのが容易に想像つくわ。
周りからタイポ魔のバグ仕込み野郎と呼ばれるぞ
239:デフォルトの名無しさん
15/10/19 00:10:31.45 RUMAerHx.net
>>237-238
わろたｗ
あんまイジめてやんなよｗ
240:デフォルトの名無しさん
15/10/19 00:21:38.76 loY8Y6Iq.net
>>238
簡素な入門レベルのプログラムしか書けないんだな。
普通のプログラミングならこんなものじゃ済まないだろう
自分のレベルを披露してさもめでたいな
241:デフォルトの名無しさん
15/10/19 00:39:09.63 S9qQFqXU.net
こういうのに好まれるのがスクリプト言語です
242:デフォルトの名無しさん
15/10/19 03:46:56.76 3gr1qLW4.net
プログラミングに魂売るような感じだったら
自分で何でもカスタマイズしていくエディタが良いんだろうけど
流行りのIDE・エディタを入れてコード書くだけで十分だろって印象
243:デフォルトの名無しさん
15/10/19 03:49:28.65 xS4Gt1Ok.net
つーか、emacsやvimの基本になるキーバインドなんて、休日の半日も使えば習得できるだろ
学習が必要になる部分なんて設定ファイルや拡張機能を使うぐらい
atomやsublime textなんか使って、どうすればコードが書けるのか分からない
244:デフォルトの名無しさん
15/10/19 03:51:58.11 xS4Gt1Ok.net
>>242
プログラマの方がIDEの補完機能に頼って、ガリガリ書いてる印象なんだけどね
プログラム言語を習得するときにvimやemacsを使うぐらいで
245:uy ◆e6.oHu1j.o
15/10/19 04:32:53.27 3gr1qLW4.net
昨日19時半に起きて、今日は何するかって考えてこのスレ覗いたらVimとかEmacsの話してるから
家から徒歩5分の本屋併設の、スタバで購入前の本読めるし、
ミルクラテ飲みながら幽雅に読破しようと思ったんだけど
隣の隣の隣の席の奴の喋り声がうるさすぎて読んでる内容全然頭に入ってこなくて
3分の1しか読めないまま閉店時間を迎えたからVimには縁がなかった
246:デフォルトの名無しさん
15/10/19 05:55:46.71 xS4Gt1Ok.net
vimの入門なんて端末にvimtutorって打てば十分だから、スタバでミルクを注文するよりも簡単だな
つーか、atomの出来が良いね。こりゃもう、coffee scriptが他のどの言語よりもロングスパンになるわ
247:デフォルトの名無しさん
15/10/19 06:24:21.33 LeQMqyQ0.net
好みの問題
スレ違い
終り
248:デフォルトの名無しさん
15/10/19 11:03:45.36 ag1CgunQ.net
> vimの入門なんて端末にvimtutorって打てば十分だから、
他のエディタでそんなことしたこと無いな。
vimだと必要なのか。
249:デフォルトの名無しさん
15/10/19 11:12:01.48 v19BRXDY.net
そりゃvimは初見だと1文字入力することすら至難だからな
vimtutorを呼び出すのも説明なしじゃまあ無理だろう
250:デフォルトの名無しさん
15/10/19 12:24:51.23 Tm4YuhXB.net
僕は Visual Studio ちゃん！
251:デフォルトの名無しさん
15/10/19 12:36:10.19 ag1CgunQ.net
>>249
ウガンダだかドドンガだかしらないけどそんなの出すぐらいなら
目立つ所に一言vimtutorのことを書けばいいのにね。
252:デフォルトの名無しさん
15/10/19 15:10:56.07 J6KXpJm0.net
纏めるとemacsやらvimはスルーしてsublime textで良さそうね
253:デフォルトの名無しさん
15/10/19 16:31:26.94 UqlRVX0P.net
なんでemacsかvimなん？
nviも仲間にいれちくり
254:デフォルトの名無しさん
15/10/19 17:18:26.03 iI7CfCu6.net
メモ帳のまねをしたらブラウザかIDEの劣化コピーにしか見えない
だからまねをしないのが正解
255:デフォルトの名無しさん
15/10/19 17:35:52.75 ag1CgunQ.net
メモ帳のまねって何のこと？
メモ帳のキーバインドは、メモ帳だけでなく
殆どのアプリに共通するキーバインドなので
「メモ帳」の真似じゃない
256:デフォルトの名無しさん
15/10/19 18:32:56.06 LINALPbf.net
>>245
気持ち悪いね、なんでそんなに気持ち悪いの？
スタバと併設してるからって、ドヤ顔でゴリゴリ読むなや情報泥棒w
努力と根性は正しい方向に使おうなw
257:デフォルトの名無しさん
15/10/19 19:02:57.92 xS4Gt1Ok.net
最近にム板に来たバカを見分ける方法を見つけた
uy、天使とakira develop（ちんこ）をスルーできずにマジレスするヤツらだ
258:デフォルトの名無しさん
15/10/19 19:11:02.57 UqlRVX0P.net
>>257
片山も追加汁
259:デフォルトの名無しさん
15/10/19 20:17:57.34 8GQYIyfO.net
>>257
QZも追加汁
260:デフォルトの名無しさん
15/10/20 03:00:58.70 UWELFMXS.net
>>240
長文で返答しろよ
お前の得手なんだろ
俺に「長い」って言われて短くしたのか？
ポリシーすら無いやつだな。
ニセ日本人って言われるぞ。
いつまで引っ張ってるのか俺は
261:デフォルトの名無しさん
15/10/20 20:24:41.26 5FrvHuNh.net
プログラミングやってると日本人ってほんと劣等種だなってつくづく思う
IT関係でOSS参加するときに日本人だと思われる事がイヤだな
その時点で舐められそう
262:デフォルトの名無しさん
15/10/20 20:43:49.34 n5dZBs0R.net
つまりプログラミングは韓国が一番だな。
263:デフォルトの名無しさん
15/10/20 20:55:02.06 Tig2GNJB.net
英語が出来ないと追いつけないよね
翻訳本待ってる間にどんどん掲示版とかでやり取りが進むし
264:デフォルトの名無しさん
15/10/20 21:02:54.87 0nb01aUJ.net
で、英語も得意な韓国人が一番ってわけよ。
265:デフォルトの名無しさん
15/10/20 22:34:10.34 N857mBVF.net
日本人じゃなくお前個人のその発想が恥ずかしいな
266:デフォルトの名無しさん
15/10/20 22:35:50.40 vVqPHhnQ.net
劣等種に言われてもなｗ
267:デフォルトの名無しさん
15/10/21 00:47:02.67 mEdv74Nv.net
>>266
国が劣等の朝鮮人か。
そのメンタルって劣等の裏返しだもんな
ひたすら毒吐いてりゃいいんじゃない？
好きにすれば～
268:デフォルトの名無しさん
15/10/21 01:31:28.87 bfl5IHz5.net
>>261
イチローが居れば日本人として舐められる事がないよ。
ただお前もその枠に収まったただのサルだって事
日本人と思われるのが嫌と言う前に、お前もそのしょぼい日本人以外の何者でもないわけだから、一緒にされたくないとか贅沢言うなよ、一緒なんだから。
きもいわ
269:uy ◆e6.oHu1j.o
15/10/21 03:04:44.34 bkabQcdE.net
>>268
すげーなお前
名無しで書き込んでも適格に俺のレスを狙ってレスしてる
それ何かしらの才能あるよ
しかしイチローとITは何も関係ないよ
野球選手としての日本人は舐められなくても
プログラマとしてのJAPは舐められてることは確実だよね
自分が逆の立場だったら基本は英語の読めない民族なんて絶対見下すと思うから
今日もぼくは自分のgemsにひとつパッチを当ててきたよ
githubはもう自分の庭みたいなもんだね
で、君は何したの？
270:uy ◆e6.oHu1j.o
15/10/21 03:28:01.09 bkabQcdE.net
js見てるとやっぱ30億のデバイスで走るRubyでもこれは勝てないと思う
パラダイムシフトが起こっているのだよ
いろんなことをデスクトップでアプリ走らせてやるのではなく
多くのことをブラウザを通してやるようになり、それが出来るようになった
だからjsとそれを吐き出すトランスレータでよくなってしまった
atomを筆頭にChromiumベースのアプリは今後増えることが予想される
多くの技術者たちはアプリケーションがChromeと連携を取ることによる利点に気付けていないが、
気付くのは時間の問題
今まで組んでいた多くのことをブラウザ･Chromeに委託する形のアプリが
各段に開発コストを落としてくれる
アプリのUIなんてSassとJekyllでレイアウトすれば良いだけ
C#.NETにも追いつけない開発効率になるだろう
ブラウザの外で行ってたプログラミング技術や規格はまとめて木っ端微塵にバラバラになって
効率の比較ではなく存在すら否定される
神（ｊｓ）と人（ｒｂ）のような比較
勝負になりませんわ
271:デフォルトの名無しさん
15/10/21 03:44:24.24 bkabQcdE.net
uyはブラウザアプリをデスクトップアプリへ変換するトランスレータの蔓延を警告しにきた者です
もうjs以外の言語は終わりですね
272:デフォルトの名無しさん
15/10/21 03:54:47.90 aUR4K/wl.net
何れはc/c++で書かれたソフトウェアたちが、ピラミッドのようなロストテクノロジーになるんだろうな
273:デフォルトの名無しさん
15/10/21 08:05:42.81 FzvQX/dO.net
デスクトップアプリがロストテクノロジーになると思ったら
いつの間にかjsがデスクトップアプリに御執心だった
274:デフォルトの名無しさん
15/10/21 10:30:41.35 zPyN71xI.net
C/C++は確実に残るね
ネイディブコード吐ける系はC/C++がデファクトだから
炊飯器のマイコン用とか、確実の残る
275:デフォルトの名無しさん
15/10/21 10:34:24.55 eLriMzbN.net
Javaでもネイティブは可能。
最近だとLLVMアセンブラというのが流行ってるし
どんな言語もLLVMアセンブラへ翻訳したら、
LLVM/Clangのように出来るだろ。
276:デフォルトの名無しさん
15/10/21 10:42:42.79 t8SS3rgX.net
夢見がちな中二？
277:デフォルトの名無しさん
15/10/21 10:43:36.43 eLriMzbN.net
これは、 C++ ⇒ LLVMアセンブリ ⇒ JavaScript。
ある言語 ⇔ LLVMアセンブリの部分さえつくれば言語間でコンバートできる。
LLVM経由は必須ではない。
Emscripten で C++ の Hello World を JavaScript に変換してみた - 凹みTips
URLﾘﾝｸ(tips.hecomi.com)
278:デフォルトの名無しさん
15/10/21 10:56:27.55 eLriMzbN.net
Microsoft、LLVMベースの.NET CoreCLR向けコンパイラ「LLILC」を発表 2015年4月15日
Microsoftは4月13日、.NETの「CoreCLR」などと組み合わせて利用できるLLVMベースのコンパイラ「LLILC」を発表した。
LLILCは.NETで使われる中間コードをネイティブな実行可能コードに変換するコンパイラ。
現時点ではJITコンパイルに対応し、AOTコンパイルにも今後対応させる方針だという。
まずはx64をターゲットとするが、その後x86や64ビットARMといったLLVMがサポートするアーキテクチャにも対応していくという。
さらに、プラットフォームはCore CLRと同様にWindowsだけでなくMac OS XやLinuxもサポートするという。
CoreCLRにはx86/x64版Windows向けとして開発が進められていたJITコンパイラ（「RyuJIT」）がすでに存在するが、
新たにJITコンパイラを開発する理由として、LLVMがサポートする全てのターゲットおよびプラットフォームで動くコードジェネレーターを提供できるためと説明している。
URLﾘﾝｸ(osdn.jp)
.NET向けLLVMベースコンパイラが登場 | マイナビニュース
LLVMプロジェクトは4月13日、「[LLVMdev] Announcing LLILC: An LLVM based compiler for dotnet CoreCLR.」において、.NET CoreCLR向けの新しいコンパイラを開発するプロジェクト「LLILCプロジェクト」を発表した。
これは、Microsoftにおいて始まった取り組みで、LLVMをベース技術として採用し、.NET CoreCLR向けに開発されたソースコードをコンパイルしてMSILコードを生成するコンパイラを開発することを目指している。
これは、Microsoftにとって.NETの実行可能なプラットフォームを増やすという点で意味がある。
LLVM関連のコードをベースに開発されたコンパイラは、LLVMが移植されているプラットフォームでコンパイルしたソフトウェアが動作するようになることを意味しており、
MicrosoftはLLVMの後ろ盾を得てコードが実行できるプラットフォームの種類を大きく増やすことが可能になる。
LLVMはすでにコンパイラ・インフラストラクチャとしての機能が整っているため、最小限の労力でそれなりに良質なバイナリを生成するコンパイラを開発できるという利点がある。
URLﾘﾝｸ(news.mynavi.jp)
279:デフォルトの名無しさん
15/10/21 11:06:39.92 zPyN71xI.net
>>275
マイコンなんかはC/C++がデファクトで、殆どのマイコンは最低限C/C++用のコンパイラがあるのに
あえてJavaを使ってやろうというのが、もう意味分からないね
技術的に可能というなら、頑張ればなんでも可能だろうが、そんなことは議論する意味が無い
既にC/C++がデファクトなのは動かしようが無い事実なんだからな
280:デフォルトの名無しさん
15/10/21 11:12:47.37 zPyN71xI.net
あーーなんか痛い頭が悪い人に返信してしまったようだ・・・
しかしまぁ、炊飯器に搭載するマイコンに高スペックは必要ないし
コストを極限まで切り詰めたいわけだから、必然的に低性能なマイコンになるのは避けれない
炊飯器の制御に.NetやJavaは必要ないし、現状C/C++がデファクトで、
マイコンメーカーがC/C++のコンパイラを用意してくれているだろうから、それを使えばよいだけ
技術的に可能かどうかはまるで関係ない
281:デフォルトの名無しさん
15/10/21 11:35:23.43 Sess9UkA.net
>>280
お前の方が痛いと思う
282:デフォルトの名無しさん
15/10/21 11:51:52.57 zPyN71xI.net
では貴方は炊飯器の制御をJavaで書いてくださいね
283:デフォルトの名無しさん
15/10/21 11:56:02.13 zPyN71xI.net
274 自分：デフォルトの名無しさん[sage] 投稿日：2015/10/21(水) 10:30:41.35 ID:zPyN71xI [1/4]
C/C++は確実に残るね
ネイディブコード吐ける系はC/C++がデファクトだから
炊飯器のマイコン用とか、確実の残る
275 名前：デフォルトの名無しさん[] 投稿日：2015/10/21(水) 10:34:24.55 ID:eLriMzbN [1/3]
Javaでもネイティブは可能。
最近だとLLVMアセンブラというのが流行ってるし
どんな言語もLLVMアセンブラへ翻訳したら、
LLVM/Clangのように出来るだろ。
↑の最初の時点で会話がかみ合ってないのが良く分かる
俺はネイディブコードはC/C++が「デファクト」と言っていて
彼はネイディブコードはJavaでも「可能」と言っている
284:デフォルトの名無しさん
15/10/21 11:59:29.94 eLriMzbN.net
LLVM対応ならば、言語は見かけだけ。
たとえば、>>278でC#はLLVMに対応して、LLVMはARMやPlayStationに対応してるから
C#でARMやPlayStationは出来るはずでC/C++と速度差はほぼないはず。
Interface３月号の特集は高性能でフリー！新時代コンパイラ入門：旧世代のGCCと新世代のLLVMについて解説
Interface 2015年 03月号の特集は、ARM用のフリーのコンパイラ。
旧世代のGCCと新世代のLLVMのどちらも紹介されているが、GCCは引き立て役である。
新世代のLLVMがどれだけ高性能か、ということが詳しく説明されている。
技術解説記事だけでなく、実際の応用としてBeagleBoneBlack基板でのクロス環境の構築なども紹介されている。
URLﾘﾝｸ(kumikomigijutsu.cocolog-nifty.com)
LLVM Clang、PlayStation 4用コードを統合開始 | マイナビニュース 2015/01/29
URLﾘﾝｸ(news.mynavi.jp)
PlayStation 4、開発にはLLVM Clang | マイナビニュース 2013/12/25
URLﾘﾝｸ(news.mynavi.jp)
LLVM 3.7登場 - OpenMP 3.1をフルサポート | マイナビニュース
LLVMコンパイラ・インフラストラクチャはさまざまなプロジェクトやプロダクトでデフォルトのコンパイラとしての採用が進んでいる。
C/C++以外にも多くのプログラミング言語のバックエンドとして使用されており、活用の場を広げている。
URLﾘﾝｸ(news.mynavi.jp)
285:デフォルトの名無しさん
15/10/21 13:01:15.94 zPyN71xI.net
しかし炊飯器の制御などの低性能マイコンには、結局C/C++が使われるのであった
なぜなら炊飯器をJavaで制御する必要性がまるで無いから
286:デフォルトの名無しさん
15/10/21 13:07:16.22 zPyN71xI.net
>274 自分：デフォルトの名無しさん[sage]
>C/C++は確実に残るね
>ネイディブコード吐ける系はC/C++がデファクトだから
>炊飯器のマイコン用とか、確実の残る
だいたい↑の発言のどこにミスがある？
炊飯器のマイコン用とかにC/C++が残るのも
ネイティブコード吐ける系のデファクトがC/C++なのも
全部当たり前の事じゃねーか
287:デフォルトの名無しさん
15/10/21 13:51:40.78 FzvQX/dO.net
Javaはnew禁止みたいな規約を作ったら暴動が起きる気がする
ある意味C++は治安が良いといえる
288:デフォルトの名無しさん
15/10/21 14:07:24.42 ayvh7TPn.net
そりゃ間違った規約ができたら当たり前だな。
それで暴動が起きないほうが、頭がおかしい
289:デフォルトの名無しさん
15/10/21 17:34:02.29 zPyN71xI.net
しかし、もし組み込みでJavaを使うとしたらnew禁止というか、GC禁止にしないとダメだろう
ファンヒーターの制御がJavaでGCで止まって火事になったら困るからな
そういう意味で組み込みはこれからもC/C++だろう
290:デフォルトの名無しさん
15/10/21 17:52:35.37 ayvh7TPn.net
なんだ組み込みの話か？ しっかりとした理由があるなら別にいいよ。
なんでこう0と1しか考えられないんだろうね。
場合に合わせて柔軟に対応できるようになろうよｗ
291:デフォルトの名無しさん
15/10/21 18:35:45.38 zPyN71xI.net
>なんでこう0と1しか考えられないんだろうね。
>場合に合わせて柔軟に対応できるようになろうよｗ
なんで自分にレスしているの？
組み込みの話をしているという場合に合わせず
柔軟に対応せずに01でしか考えず
「頭おかしい」って発言したのは君自身じゃないか
292:デフォルトの名無しさん
15/10/21 19:12:27.07 ayvh7TPn.net
>>291
君みたいにずっと２ちゃんねるに引きこもってるわけじゃないんだわｗ
過去レスなんか読まねーよｗ
293:デフォルトの名無しさん
15/10/21 21:07:34.78 M3PJopuY.net
歴史から学ばない態度
294:デフォルトの名無しさん
15/10/21 23:15:11.40 b4QGUSAZ.net
こうしている間にもCoffeeScriptの一強時代は続いていく
295:デフォルトの名無しさん
15/10/22 00:09:06.94 T+i/NslY.net
CoffeeScriptはもう死んだって言われてるよ。
296:uy ◆QLvratmkOY
15/10/22 00:24:23.71 KLEdlWO7.net
## -- Sample one --
# CoffeeScript
x = y if true then 1 else 2
# ruby
x = y if true then 1 else 2 end
### CoffeeScriptの勝ち
## -- Sample two --
# CoffeeScript
courses = ['greens', 'caviar', 'truffles', 'roast', 'cake']
menu i + 1, dish for dish, i in courses
# ruby
courses = ['greens', 'caviar', 'truffles', 'roast', 'cake']
courses.each.with_index 1 do | i, dish |
menu 1, dish
end
### CoffeeScriptの勝ち
297:uy ◆QLvratmkOY
15/10/22 00:27:00.46 KLEdlWO7.net
## -- Sample three --
# CoffeeScript
grade = (student) ->
if student.excellentWork
"A+"
else if student.okayStuff
if student.triedHard then "B" else "B-"
else
"C"
# ruby
grade = ->student do
if student.excellentWork
"A+"
elsif student.okayStuff
if student.triedHard then "B" else "B-" end
else
"C"
end
end
### CoffeeScriptの勝ち
298:uy ◆QLvratmkOY
15/10/22 00:28:14.91 KLEdlWO7.net
## -- Sample four --
# CoffeeScript
class Animal
constructor: (@name) ->
move: (meters) ->
alert @name + " moved #{meters}m."
# ruby
class Animal
def initialize name
end
def move meters
alert @name + " moved #{meters}m."
end
end
### CoffeeScriptの勝ち
4 : 0 で CoffeeScriptの勝利です
299:デフォルトの名無しさん
15/10/22 00:37:46.43 T+i/NslY.net
あー、すまん。CoffeeScriptが死んだっていうのは、
CoffeeScriptの開発者が少なすぎて、
これ以上の発展が望めないからだよ。
300:デフォルトの名無しさん
15/10/22 00:51:18.24 wPy/E8qZ.net
typescriptなんか使ってatomの設定や拡張機能を書きたい人なんて居るの？
今もうperlやPHPが手探りで言語の理想型を探した時代じゃなくって、
最初から完成型が見えていたんだから、アレ以上の発展なんてしなくて良いよ
301:デフォルトの名無しさん
15/10/22 00:52:30.53 3kaWJUCe.net
>>299
所詮、JavaScriptの亜種でしかない。
302:デフォルトの名無しさん
15/10/22 00:56:18.63 wPy/E8qZ.net
素のjavascriptでオブジェクト指向っぽいことしようとすると、ボイラープレートが増えすぎる
303:デフォルトの名無しさん
15/10/22 01:01:55.02 wPy/E8qZ.net
gulp,atom,wintersmithと台所まわりはcoffee scriptが制した
304:uy ◆QLvratmkOY
15/10/22 01:03:59.17 KLEdlWO7.net
>>300
とっくにatomの拡張機能書いて公開して2ダウンロードされてる
305:uy ◆QLvratmkOY
15/10/22 01:06:45.97 KLEdlWO7.net
uyのかいたパッケージが
世界中の人がapm list ってやるたびに
一覧に表れるんだよなぁ・・・
306:uy ◆QLvratmkOY
15/10/22 01:08:51.52 KLEdlWO7.net
まだatomは挙動おかしい場所多いから手放しでは奨めない
せめて正式リリースから1年経たないと一通りのバグは潰されない
307:デフォルトの名無しさん
15/10/22 01:12:13.41 wPy/E8qZ.net
vimやemacsにもどるか、sublime textに改宗しようかな
308:デフォルトの名無しさん
15/10/22 03:22:10.53 basoVJGP.net
>>294
Goodbye CoffeeScript, Hello TypeScript
URLﾘﾝｸ(blog.heapanalytics.com)
ES6以降の趨勢は明らかだよ
309:デフォルトの名無しさん
15/10/22 04:12:25.15 IVKIlR3f.net
>>307
Emacs-Evil、Atom、ST３つ使いこなせば良いだろ。
Common LispもJavaScriptもPythonも間違いなく重要な言語なんだから使いこなせないとおかしい。
ま、もっともSwiftもC/C++、Object-Cも使わないといけないけどねw
310:デフォルトの名無しさん
15/10/22 04:43:30.03 wPy/E8qZ.net
>>308
半年後には、angular.jsのウンコさを理解して、
coffee scriptとbackbone.jsにもどってるよ
311:デフォルトの名無しさん
15/10/22 08:38:56.58 T+i/NslY.net
それはない。
そんなの使わなくてもブラウザが搭載するAPIだけで良くなって、
そのAPIを簡単に使えるjQueryに戻ってくる。
312:デフォルトの名無しさん
15/10/22 12:05:51.60 QSun3zFj.net
そんなに無駄に迷走してるjsは数年後には......
313:デフォルトの名無しさん
15/10/22 13:12:56.56 T+i/NslY.net
だからjQueryだっていってんだろｗ
314:デフォルトの名無しさん
15/10/22 13:20:13.97 yz0BR0WH.net
JSじゃなくてDOM APIの、そのまたフレームワークの話だから。
DOM API自体は迷走してはいない。
315:デフォルトの名無しさん
15/10/22 13:24:41.60 Z/S38Wn0.net
最終的にはフレームワークは必要なくなり（ブラウザのAPIに組み込まれる）
DOM APIをそのまま使うか、jQueryラップして楽に使うか。の世界になる。
316:デフォルトの名無しさん
15/10/22 16:06:34.28 wPy/E8qZ.net
ブラウザのAPIをそのまま使って問題がないならjQueryなんて生まれてないだろ
jQueryと併用するミニマム主義のライブラリがbackbone.jsだと思うんだけど
317:デフォルトの名無しさん
15/10/22 16:50:37.59 Z/S38Wn0.net
jQueryは "既存の" DOM APIのショートカットなんで
DOM APIの仕様がガラリと変わらないかぎり、jQueryの利点が生きる。
ただし新しいDOM APIは増える。増えた結果フレームワークは必要なくなる。
318:デフォルトの名無しさん
15/10/22 17:26:12.80 oDtCxyWl.net
結局残るのはjqueryやbackboneのような「センスのいい小物」なんだよな
UNIX哲学
319:デフォルトの名無しさん
15/10/22 18:08:58.70 Ud9o9dbV.net
DOMをそのまま使うことの何が悪いのかをきちんと言葉で批判した方が良い
jQueryの人気度のような数字だけ見せられても、数字はそのうち変わるから納得できない
320:デフォルトの名無しさん
15/10/22 18:52:26.32 Z/S38Wn0.net
> DOMをそのまま使うことの何が悪いのかをきちんと言葉で批判した方が良い
悪くない。冗長ってだけ。
jQueryは、何も変えずに、ただ単に記述を
短くできるようにしただけなので、マイナスは殆ど無い。
（多少速度が遅くなるだけ）
321:デフォルトの名無しさん
15/10/22 19:09:26.16 QSun3zFj.net
このスレでさえ宗派が分かれるわけだからjsの将来は......
322:デフォルトの名無しさん
15/10/22 20:24:42.32 Z/S38Wn0.net
宗派が別れないものなんて無いよｗ
323:デフォルトの名無しさん
15/10/22 20:30:29.86 wPy/E8qZ.net
てーか、jQueryがないとクロスブラウザで動かないでしょ
angular.jsなんて不毛にデカイから保守コストが増えるだけ
SIerに勤めているなら保守コストが増えることは魅力的かもしれないけど、
自分らの用を足すののに、ほんのちょっとタダで使えたら良いだけなんだよ？
324:デフォルトの名無しさん
15/10/22 20:35:55.14 Z/S38Wn0.net
いや、まだ時たまSafariとかの不具合対応とか入ってはいるけど
jQueryはクロスブラウザとしての役目は終わってる。
今は純粋にDOMを関数型風に扱うための便利なライブラリとして考えたほうがいい。
325:デフォルトの名無しさん
15/10/22 23:32:17.62 aOiAbW8x.net
俺みたいな標準厨はライブラリよりもDOM.nextのポリフィルを使いたくなる。
別に標準ではないものを使うと廃れたとき負の遺産になるとかそういうのではなくて
生理的な問題。
326:デフォルトの名無しさん
15/10/23 00:35:59.00 zprVcqwH.net
ポリフィル使うのは全然問題ないけど、
一般的に標準APIっていうのは、必要最小限の機能に抑える傾向にあるんで
それだけでは生産性上がらないんで、厳選してライブラリを使う。
今のところおすすめは、jQuery、lodash、moment、
ここらへんは基本的なライブラリとしておすすめ。
jQueryのプラグインはお薦めしない。jQuery UIもあまりすすめない。
あとは作るアプリに応じて、必要ならば吟味した上で使う。