スレタイ超過のため、一部省略。
Go, Erlang, Kotlin, etcもウェルカム。
Haskellは協議により次世代失格になりました
前スレ
次世代言語議論スレ[Go Rust Haskell Scala]第3世代
http://echo.2ch.net/test/read.cgi/tech/1488608741/
次世代言語議論スレ[Go Rust Kotlin Scala]第4世代 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
スレタイ超過のため、一部省略。
Go, Erlang, Kotlin, etcもウェルカム。
Haskellは協議により次世代失格になりました
前スレ
次世代言語議論スレ[Go Rust Haskell Scala]第3世代
http://echo.2ch.net/test/read.cgi/tech/1488608741/
https://trends.google.co.jp/trends/explore?q=Golang,Typescript,Kotlin
Google社内の標準言語としてTypeScriptが承認される。ng-conf 2017
http://www.publickey1.jp/blog/17/googletypescriptng-conf_2017.html
TypeScriptが標準言語になっても、Dartのことは忘れてませんよとGoogle担当者がフォロー
http://www.publickey1.jp/blog/17/typescriptdartgoogle.html
継承もカプセル化もオブジェクト指向には必要ない
クラスを作る、つまり型を定義する事こそがオブジェクト指向
265 デフォルトの名無しさん[sage] 2017/04/19(水) 23:10:42.57 ID:2dTlCsss
>>208
代数的データ型で型を定義できるHaskellはオブジェクト志向言語だった……？
266 デフォルトの名無しさん[sage] 2017/04/19(水) 23:12:01.85 ID:qOdNs+TP
>>265
代数的データ型とはなんぞや？
269 デフォルトの名無しさん[sage] 2017/04/19(水) 23:19:37.80 ID:qOdNs+TP
type c = a or b
みたいな？
270 デフォルトの名無しさん[sage] 2017/04/19(水) 23:20:37.20 ID:qOdNs+TP
これもオブジェクト指向と言ってもいいでしょう！
こんなん草生える
次世代というものを感じないのだがなんかあるの？
旧世代の資産をなんとか次世代まで持ちこたえさせるつなぎって感じ
とはいえ次世代は次世代でしょ
構文は嫌いじゃないけど。
Haskell学ぶなんて時間の無駄だってことに気づいたの
前スレでHaskellは次世代言語ではなく遅延評価に問題があるとされた。
でもHaskellの考え方を学んで他の言語で活かすならありだと思う。
タイミングを何秒後と指定して評価するのは問題ないとされる
現にそういう問題が出題されたしね
Haskellに詳しい人もHaskellについて議論できる人もいなかったんで対象として取り上げるには不適切になった(このスレでは)
Haskell上げの意見は説得力が無いしHaskell下げの意見はただのレッテル貼りにしかならない
おもしれーw
逃亡というレッテル貼りをおそれて多くの人が努力したんだな
レッテル貼りには人を努力させる効果があった
レッテル貼りは悪という意見にはあまり説得力がない
この場合、逃亡は悪ではかったと考える方が説得力がある
最後の１行がそれより前とつながらないんだが
加えて、正直な感想として現行言語の方が次世代と称される言語よりずっとすっきり書けていた
という現状をふまえると次世代の「売り」って何なのだろう
クラスや付随する言語機能を捨ててシンプルさを求めたこと（継承のデメリットの排除と学習コストの軽減）と
それで生じる表現力・抽象度の低下を型チェックや型推論機構の充実で補ってバランスをとったところ？
実用性皆無なプログラム言語は存在価値無し。
逃亡は悪ではかった→逃亡は悪ではなかった
>>18
レッテル貼りは悪とは限らないし、そもそも悪と戦うことが目的ではない
戦いが目的でないなら逃亡は合理的だ
そこじゃない！ｗｗｗ＞訂正
逃亡というレッテル張りを恐れて他の善意のファンが努力
→レッテル張り自体は悪だが結果はそう悪いものでもなかった
という流れからどうして逃亡自体が悪でないという帰結が導かれるのか？
ひたすら机上の空論を展開し、他を貶め、蔑み、悪態をつくだけついて
じゃあ動くコードやよりよい設計を出せというと逃げるのはどうみても身勝手だろう
そんな出題者の意図があるとは知らなかった
この場合、出題者は関係ないだろう
「他を」は「他言語（あるいはその使い手、ファン、コミュニティ）を」だ
もしかしてHaskell儲がまだいるのか？
なら逃亡行為を好意的に解釈したがるのも頷ける
それにType Classのコード理解できるやつ何人いた？
単なる継承だと勘違いしてるっぽい奴はいたが
旧世代言語なら実質50行程度せいぜい10分で書けるコードにいくら請求するつもりだよｗｗ
それに単価ならカンブリア言語のSmalltalkerの方がよほど高いわ
奴ら呼べばきっと頼まれなくてもホイホイ書くぞ
Rust使いに次いで自分言語大好きだからな
https://developers.srad.jp/story/17/03/31/0448232/
サンプル通りに呼び出すだけのドカタだろ？
次世代言語なんて要らんだろ
仕事できると思ってるバカが多いってだけなんだよ結局。
abc系でみんなで人工知能を作ろう！
http://echo.2ch.net/test/read.cgi/tech/1488681839/
いつか知らないけど、次に主流になる言語が何かを決めたいんだろう
これから100年先までずっとC++だ
それでいいそれで。他を圧倒的に突き放して一番早くて実用的な言語だ。
まず配列アクセス演算子が引数一つしか取れない時点で終わってる
配列アクセス演算子なんて最初から必要なかった。
そのEigenでさえ3次元以上には対応してないっていうのがC++の自由度の低さを物語ってるが
深層学習とか統計処理とかには必須だぞ
量子化学にもあれば便利だな
データ整理一般にも使うしな
あんまいらんだろ。
本当に必要な場合は結局、配列レベルで高速化が望まれる場合だけだし。
誰かが用意した python のライブラリでも使ってなさいってこった。
カスが個人的に作ったものよりもよっぽど速くて正確なものがあるんだから。
速度においてもCython擁するPythonが負ける要素はないし
配列マン「多次元配列需要あるのにC++にはないやん」
C++er「そんなもんあんまいらんだろ。Pythonでも使ってなさいカス」
C++erってやっぱダブルスタンダードのカスだわ
そこを処理系任せにしてメモリ上のデータ構造チューニングできないようなものが次世代言語なのか？
ラッパ用スクリプトのPythonとはそもそも言語としての立ち位置が違うって話。
頭にチンポ型の伝送デバイスハメるだけでプログラミングできたりする？
言語はなくなってるかもしれん
科学がなくなる
数学がなくなる
こういう無数の可能性から一個選んで的中させるのはほぼ不可能だよな
早くネットワーク系のライブラリを標準で入れてくれぃ
ID:bkkcl6Xn「私はID:UJAzDyB2である。C++は実用ライブラリを書くための言語だ」
なにこれ
多次元配列でチューニングすべきところなんかあるか？せいぜい格納方向が2通りあるくらいだろ。チューニング出来るものは一切搭載してないFortranにすらデフォルトで搭載されてる機能だぜ？
それにそれ言っちゃあSTLなんてどうなるんだよ？ まさかSTLは使うけど多次元配列は自分で作るなんて言わないよなあ？
ガチ用途でSTL使わねえだろバカも休み休み言えよ……
STL使うC++なんてちょっと速いPythonやらRubyじゃねえか。
ほーんSTLより速いの書いてあげてみ？
絶対無理だろ
そりゃ自分の書くものに一番合うように書くから、あらゆるベンチを通すように丸く作られたSTLに全分野で勝てるわけないだろ。
この用途ならこれが一番速くて信頼性が高くて拡張性も優れていて、自分で書いてSTLを使わないコストという面でも釣り合いが取れるっていうのがあるってことだよな？
用途から自分で設定していいから書いてみろよ。
1〜5次元くらいまで同じインターフェースで動く奴作ろうとして、思いの外面倒だったから辞めてFortranに乗り換えたことあるんだよな
亀だけど、C#って、C++++という意味を込めてるんだよ。
だよねぇ、多次元配列の操作で Python に勝るのは Fortran くらいしか思いつかないや
純粋手続き型言語の始祖である Fortran と、同じく純粋手続き型スクリプト言語である
Python、誰にも否定できない当然の結果だよね
もう、このスレでは次世代 Fortran は Python で決まり！！ってこと結論が出たね
多次元配列操作で次世代言語を選ぶならJuliaだろう。
Python使いをJuliaに引き込むサンプル集
http://www.mwsoft.jp/programming/julia/python_to_julia.html
RユーザのためのJulia入門（行列編）
http://rishida.hatenablog.com/entry/2013/11/30/194733
ないけどさ
Qiitaで検索するかAdvent Calendarｓを読め。
普及が始まっている次世代言語は
たいていAdvent Calendarｓ 2016がある。
次世代言語に必要だったのは高速で便利な多次元配列だったってオチか
Julia0.3の化石みたいな記事貼るなって意味だよ
そろそろ0.6
多次元配列が必要な人間は一部だけど文法が全員に影響があるから、多数決で文法優先
オタクではなく多数決です
C#やJavaScriptにしても、簡潔に書けるとかじゃなくて何を作れる(サポートするプラットフォームの多さ)で選ばれてるし。
どういう分野の人が使うの？
マクロ書いちゃえばいいんでないの？
アクセス演算子と大仰な言い方するが、要は単に掛け算なんだし。アライメントも揃えられるしさ。
適当な並べ方してるとメモリアクセスで悲しい思いをする気がする。特にどーんとクラスタに投げるときとか。
Fortranでもメモリマップ的には後ろの列からの順番になるから思い付きで並べると重いよ。
テンソルに係数を掛けたり、テンソルとベクトルを掛けたりすると、欲しくなるのは確か。
unionって思ってたより随分便利だなーって思うやつ。
Rubyが流行りそうになった時、RoRの登場で一躍有名になった。
Pythonにはそれに相当するものが無かった。
後に同じようなの出来たけど、Rubyを引き離すほどじゃ無かった。
Ruby1.9の時、互換性切り捨てでRuby自滅が決定打だった。
結果としてディープラーニング向けライブラリの登場で揺るぎない地位を得た。
文法はRuby1.9以降のが好きだし理に適ってる。
でも、世界的には終わった言語。
自然言語で言えば、エッセイストは言語学者じゃないのに形態素に基づくなんとかかんとか、こういうしきたり、こういうルールってのを並べられてもって感じで、
しかも、言語学者側はそれを素晴らしいと絶賛してると言う狂った状態に近い。
英語なんかあんな破綻した闇仕様に溢れた言語
(例えば、Shipの口語の代名詞に失われた性を補完してsheを使う)なのに、
あんなに全世界で使われてるんだから。
言語なんて歯ブラシなんや、ってPHPの方が随分スタンスとして好き。
あんまり原理主義的な事話してると怒られるから。。
Rubyも注目された当初は簡単でなんでも出来る言語としてsmalltalk作ったけど、真のsmalltalkはRubyだったとかアラン・ケイも絶賛してたし、RoRもRubyの文法に惚れて作られた。
その後の保守戦略家で差が付いた。
o保守戦略
どうやって決めたかは教えないけど、成功とか失敗とか成果だけ教えてやるよって感じ
成果だけが重要と思っているからなのか
>Ruby1.9の時、互換性切り捨てでRuby自滅が決定打だった。
互換性切り捨てってのは、これのこと？
http://echo.2ch.net/test/read.cgi/tech/1413113999/128
うーみゅ、確かに Hello world レベルのお題ですら動かなくなるようでは、
互換性切り捨てと批判されるのも仕方ないよね
戦略って言っても、私が結果だけ見てそう判定しただけだがね。
結局、言語の開発管理側が業務で使われているって事実を重要と見たかどうかってだけ。
どっちも互換性切り捨ててるんだけど、Pythonはまだ旧バージョン系列サポート切ってないし、長々とアナウンスしてる。
X：Pythonはまだ旧バージョン系列サポート切ってないし
O：Pythonはまだ旧バージョン系列サポート切れないし
Pythonはまだ新旧バージョンでの後方互換性切り捨てが災いして、
未だに旧バージョン系列から新バージョン系列へ移行できていないだけの話
だから旧バージョン系列サポートを切りたくても切れないってのが現実
http://blog-imgs-82.fc2.com/n/o/r/noriaki3/201508310726369c2.jpg
強行したRubyはどうなったよ。
http://echo.2ch.net/test/read.cgi/tech/1486026729/900
ところで、Rubyの互換性切り捨てとは具体的には何を指しているのかな？
少なくとも Hello world レベルであれば、RoR登場以前の 1.6 から最新の 2.2 に至るまで、
Ruby であれば Syntax Error にならず正常動作するから互換性は維持されているけどね
うーん，LL(1)に徹している pascal が古今東西素晴らしいとおもっているんだが‥ruby ってそんなにすごいの？
？
低機能パーザー使うと何ですごいの？
＞自然言語で言えば、エッセイストは言語学者じゃないのに形態素に基づくなんとかかんとか、こういうしきたり、こういうルールってのを並べられてもって感じで、
だろうね
1/ 2 = 0.5
とか型が弱くなる方向に修正したんだか。。
明示的に書かせるのが python の良さなのにそれと逆行しようとしてるのが好きになれん。
pascalは素晴らしいと思うよ。俺も。
いつの間にか呼ばれてるto_intみたいな馬鹿な仕様もないし。
あれは理想ではなくて現実。
>>101
追いかけてるだろー。
「Objectには不要なものが多すぎる、好ましくない。でも、互換性失いたくない。
そうだ、Objectの親にBasicObjectを作って白紙のオブジェクトとしよう」
なんてまともな神経してたらちょっと思いついたけど敢えて忘れるレベルの実装をマジでやった上に、
一番やめてほしい==の実装をBasicObjectに持ってったんだぞ。
気が狂ってる。
わざわざtrueClassやらnilClass作ってたのが原理主義っぽくて良かったのに。
n = true if false
で、nがnilになるのもおかしい。
n = n+1でnilに+はねえよってメッセージの原因だけど、こればっかりは異常。
言葉に気をつけろよ
キャットドア問題の前にお前らはボロ雑巾のように敗れ去っているのだから
そもそも、クラスを破壊せずに機能追加せよ、って矛盾した設問がおかしい事にまだ気づかんのかなぁ。
俺もpascalはシンプルで好きな方。
だけどブロックは波括弧が好きなんだよなぁ。
うろ覚えだが、文字列から文字を取り出すのが思い切り変わった。
これは阿鼻叫喚になるなって印象はあった。
＞うろ覚え
正しくは。うる覚え。な
学がないやつはこれだから
Objectクラスの親クラスにProtoObjectクラスがあるのも、
==をProtoObjectで実装するのも、
TrueクラスやUndefinedObjectクラスがあるのも、
false ifTrue: [true]がnilになるのも、
みんなSmalltalkでは理想どころじゃない、
ProtoObjectは90年代のOO普及期からずっと当たり前のこと、
それ以外は80年代のOO黎明期からずっと当たり前のことだが、
どこがどう理想なのか、どこがどう次世代なのか、教えてくれよ。
これは嘘でしょ？
本当なら落ち込むわ。。
ネットスラングとしては、「ふいんき」と同様に、誤記を承知で敢えて用いられる例が見られる。
ネットスラングとしては、「ふいんき」と同様に、誤記を承知で敢えて用いられる例が見られる。
Python の配列って、list でしょ？
だから、理想に走りすぎで現実見えてないって言ってるの。その論調だとsmailltalkが自然で目指すべきだと聞こえるが？俺はそうは思わないけど。
泥の中の蓮的な理想感はあるが、実際にはそんな物が必要ならそれこそRubyなんか使ったら劣化コピーで気持ち悪いものをこねくり回して満足してる学者大先生と同じ。
エスペラント語を素晴らしいと言いはって、エスペラント語でエッセイ書くようなもんだ。書いてみりゃわかるが、無謀だよ。
正しくしか書けないし、元の発想が比喩で作られてるようなもんだから、比喩表現は比喩の比喩になってもう意味がわからない姿になる。
永遠に次世代になりたくて、実は永遠に次世代ではない。
ポエムは難しいけど。
思い出したよ。
Stringクラスからeachメソッド無くなって、each_lineとかeach_charsになったんだ。
お陰で配列と同じように扱ってたのが、文字列だけ別扱いになったから、ダックタイピング出来なくなった。
あと文字コードの扱いとか。
詳細はこっち。
https://www.oreilly.co.jp/community/blog/2009/05/changes-on-ruby-1-9.html
Pythonのクラスは演算子を定義する機能のような印象
小論文の意味のエッセイなら割とそうだろうけど、それでも主観の表現方法を無理やり曲げられる時点でダメだろ。
グーグルをラ行五段活用する事を無理に実現するために他の名詞が巻き沿い食う感じ。
表音文字に依存するな、記号に依存しろ
ずっとクラスベースを拒否し続けたJavaScriptも
ある意味プロトタイプベースの理想を追い続けてるような
まぁ、恐ろしいほどに無意識に使ってるスペースなんて記号も英語ベースだしな。
コアダンプが漢詩のように見える事もあるけど。
>>124
あれはあれで、リストをああいう形で実現した時点で割と言語としては完成してた。冗長だけど。
>それが企業に好感持たれてる現実。
Hello world すら Syntax Error になってしまう(>>95)ほどの壊滅的な
後方互換性切り捨てを強行してなお旧バージョンのサポート打ち切りなんて、
常識的な企業倫理からはありえないだろ
そんな対応を指して「好感」という言葉は冷酷な皮肉でしかない
あるいは、過去に Hello world がバージョンアップで動かなくなったメジャー言語が存在するの？
print が文なのか関数なのかという言語とライブラリ設計における根源的な決定、
言い換えると入出力処理は構文で実現すべきなのか(すなわち文)、それとも
ライブラリで提供すべきなのか(すなわち関数または手続き)という言語設計の哲学、
そんな初歩的な判断すらできない人物によって行き当たりばったりに設計されたのが
Python だろ
$ irb1.9
irb(main):001:0> "abc".each { |x| p x }
NoMethodError: undefined method `each' for "abc":String
from (irb):1
from /usr/bin/irb:12:in `<main>'
うん、確かに実行時エラーになった
では、ここで呪文を唱えてみよう
irb(main):002:0> class String; alias :each :each_char; end
=> nil
irb(main):003:0> "abc".each { |x| p x }
"a"
"b"
"c"
=> "abc"
irb(main):004:0>
あれ、おかしいなあ、Ruby 1.9 の String クラスなのに、Ruby 1.8 と同じく
配列と同じように扱えるようになったぞ、しかも元のコードは一切改変されていない
いったいどうなってるんだあ…
その理屈だとSmalltalkはオブジェクト指向じゃなくてなんだったんだ？
全ての関数をクラスという箱に入れた結果全てが事実上のグローバル変数になった
見方によってはそう(グローバル変数)なんだよね。
スコープは狭い方が良い。
正直オープクラスはイマイチと思うのだが、でもjavascript はそのおかげでpolyfillとかできるんだよな。
Smalltalkはレシーバだろ
記法の問題ってこと?
ビヤーネ・ストラウストラップらの抽象データ型のOOP（カプセル化、継承、多態性）と
アラン・ケイの遅延結合徹底のOOP（オブジェクトにメッセージを送る）は別物だって事をいいたいのかな
後追いのRubyも死滅するのは歴史が証明している
そう。パッシングの口でしかない。
死滅したとか記憶から消し去りたいロートルがいる一方でスタートアップで勝負をかける奇特な人もいる
http://pharo.org/success/AllStocker
スタートアップ界の異端児！産業機器 x IT x SmalltalkのSORABITO株式会社
https://thepedia.co/article/1068/
Smalltalkのとらえ方は人それぞれやね
今日もSmalltalkが世界の海上コンテナ輸送の30%を捌いているわけだが。
OOCLのことを言っているんなら、あれってJavaに置き換えられたんじゃないの？
Who uses Smalltalk? : programming - Reddit
https://www.reddit.com/r/programming/comments/3wv7ik/who_uses_smalltalk/cxzzhkp/
もしかしてOOCLのこと言ってんの？
とっくにそんなシェア無くなって、今年に入って買収の噂が出るくらい落ちぶれてるぞ
よく読め。再実装されたのはUIだけだ。あほか？
なんでとても素晴らしいsmalltalkで再実装されなかったの？
そんなことするなら言語ごと変えた方が良い
Smalltalk は開発環境含めてあまりにオールインワン過ぎるから。
そんなどーでもいいことより30%シェア撤回ﾏﾀﾞｰ
死体蹴りは良くない
過去に同じことがあったと口で言っても証拠が残ってなければ同じことが繰り返される
死んでるのはおめーの脳みそだろ？
http://pharo.org/success
いつでも同じクオリティじゃないか
最近文読みやすくなってきてるしちょっとええ感じやで
まぁ具体的に「パラグラフが長い」「言い回しがくどい」と言われたら、
なるほどと思うし、ちょっと気を付けられるからな。
読みにくい、ガイジか！とだけ言われたら、読みにくいだけならしっかり読めとしか言いたくなくなる。
「ロボットは東大に入れるか」成果報告会 in 2016（11/14）レポート
http://blog.livedoor.jp/dg_law/archives/52354118.html
これからはシミュレーションシステムの構築が簡略化されるので、来年のセンター物理は大きく得点が伸びるに違いない。
スーパーコンピュータでの計算に必要となるプログラムはときに数十万行にも及び、作成やチューニングは大変困難です。
一方で、原理的にはシミュレーションしたい自然現象とその離散化法（注2）を指定すれば、プログラムは機械的に生成できます。
しかし、プログラミングはシミュレーションとコンピュータ双方に深い知識が必要となる非常に高度な作業であり、多数の計算機を
協調して動作させるスーパーコンピュータの性能を引き出す高度なプログラムを、自動かつ汎用的に生成することは不可能でした。
そこで共同研究グループは、方程式がプログラムに変換されるまでの一連の段階に対応する数学的定義を作りました。
スーパーコンピュータが持つ階層のすべての段階において、自然が元来備えている「並列性」と「局所性」（注3）を保持する変換
を厳密に定めることで、新たなプログラミング言語「Formura」を開発しました。これによって、これまで不可能だったプログラミング
の機械化に成功しました。さらにFormuraは、同じアプリケーションに対して何万通りものプログラムを試し、最も速かったものを自動的に選択します。
Formuraを開発したことで、規則格子シミュレーション（注4）分野においては、自然科学者が慣れ親しんだ方程式の記法を使ってシミュレーション
したい対象を記述することで、スーパーコンピュータの性能を引き出すための高度なプログラムが自動的に作成できるようになりました。
気象、地震、宇宙、生態ネットワークの研究など、規則格子シミュレーションを用いる分野の研究の加速が期待できます。
http://pr.fujitsu.com/jp/news/2016/12/2.html
「5%の不良率で100個発注したら当たり前のように105個納品されてくるようなどっかのおおざっぱな国の発想だ」
と、日本の会社だと反発されるやつ。
ナップサックとか問題持ち出して、モノによっては泥臭く計算せなあかんのやと言うのと、
次は百万台でやっても一つのタスクの不可分な時間以下にはならんのだよ、
を説明して説得して導入するようなものだから。
トポロジ解析と図面生成か何かで原始的なそれやった事ある。
多くの深層学習フレームワークはNN構造をPythonなどで記述すると
それをテンソルの計算グラフに変換してGPUで高速計算してくれる。
NN構造や規則格子をさらに簡略に記述したければJuliaがある。
Fomuraの20行のシミュレーション記述も既存の言語でできるはずだ。
つまりシミュレーションをより簡略に作成するために新言語は必要ない。
必要なのは用途毎のフレームワークだ。
覚えやすさとチューニングのしやすさ。
以上。
いろんなプログラム言語を開発しておいて、その上で『良いとこ取り』で新言語を開発する。
Goはグーグル発じゃなかったら「今どき継承もない言語作ったのかよ？ｗ」で即死
なおScala
実際死んでね？言語としては。
言語として死んでるのをGoogle謹製の周辺ツールで無理やりカバーしてゾンビ化してる感じ。
ゾンビなので一周回って死ににくい。
死ぬときは死ぬ
Dartとか
Goは文法が簡単で高性能という特徴がある。
おかげで文法は簡単だが低性能な言語から移行しやすい。
だから難しい言語が選ばれない所で活躍している。
Gopherの道を歩む – Node.jsからGo言語への移行
http://postd.cc/the-way-of-the-gopher/
Go言語の低レイテンシGC実現のための取り組み
http://postd.cc/gos-march-to-low-latency-gc/
Mainに集中して必要な機能呼び出すだけでいいんだから設計書なしで良さそう
バージョン11.1では，機械学習，ニューラルネットワーク， 音声処理，ロバストな記述統計等の分野における
MathematicaおよびWolfram言語の最先端機能が拡張されています．
広範な応用分野に加わった，130を超える新関数
ニューラルネットワークの新しい20種類の層の追加，および再帰型ネットワークと可変長シーケンスのシームレスなサポート
NetModelにより，増加し続ける完全なニューラルネットワーク（訓練されたものとされていないものを含む）のリポジトリにアクセス
データ，画像，テキスト等の空間を機械学習ベースで可視化するFeatureSpacePlot
SequencePredict，ActiveClassification，ActivePredictionを含む，新しい機械学習関数
AudioCaptureを使って音声を直接ノートブック内で録音することによって，すぐに処理・解析することが可能に
2Dおよび3D画像に対する，*，-等を使った計算が可能に
計算写真学と計算顕微鏡学に対するサポートの拡張
ImageGraphicsを使って，ビットマップのベクトルグラフィックスによる近似を求める
HilbertCurveやSierpinskiMesh等の空間充填およびフラクタル領域コンストラクタ
WinsorizedMean， SpatialMedianを含む，新しいロバスト統計と空間統計
新しいGeoBubbleChartと，Callout，ScalingFunctions等のサポートの拡張
記号次数を持つ導関数のサポート
解像度が高くなった標高データ
シームレスに統合されたWeb検索，Web画像検索，テキスト翻訳のための外部サービス
セッション間の値をローカル，あるいはクラウド等に保存するための，幅広いPersistentValueシステム
クラウド内で個別に編集できるノートブックをシームレスに配布するためのAutoCopy
ノートブックベースのスクリプトエディタを使ったWolframScriptの.wlsファイルの生成
Wolfram言語スクリプトの自動実行がWindowsでも可能に
ドキュメントセンターおよびオンラインの例題すべてが新しくレスポンシブデザインに
https://www.wolfram.com/mathematica/quick-revision-history.ja.html?footer=lang
http://mathtrain.jp/kaitenhobutsu
「放物線 y = 3/4 - ｘ^2」
を
「y軸の回りに回転させる」
・・・例えば、こういう操作ができる３次元ＣＡＤって開発されてないんですか？
統計的機械翻訳では自然言語処理は無理という話も聞いているけれど、高校数学でやることは内容が限られており、
一般的な機械翻訳よりは難易度は低いと思われます。
その問題を解けるCADは多くないだろうな。
近似的な数値解が求まることと、解を方程式で表して数式処理できることは全くの別物。
＞その問題を解けるCADは多くないだろうな。
そのための新プログラム言語開発ってことだよな。
ごく当たり前の機能として存在する。
面で切り取る事もできる(面に対する押し出しで、相手方を削り取る感じ)
体積も求められるよ。
拘束条件は厳密だし、カーブを式で入れることもできるから。
ただ、それのために1License300万出す？
うちでつかってるのは数値解じゃなくて方程式まで自由じゃないけど変数の式でも出たはず。あれ内製だったかな。
AutoCADのMASSPROPとかくらいだと、悲しいかな数値解しか出ないけど、カーネルに手を出せる会社ならだいたいその辺持ってると思うよ。
それはすまん。
押出する元の図形をプロシージャルではなくて、曲線定義で描く。
曲線への拘束条件で何を取るか次第だけど、問題文通り入れればそれで良いと思うよ。
ゴールデンウイークは試せないのがもどかしいな。
殆どの人は信じてしまうくらい先進的だよね
進歩しすぎてて理解されない不幸な言語
型推論の問題じゃない？多分
型推論を使う言語とか、動的型言語に型ヒントを追加する場合とか。
だったら最初から統一的な記法で良くね？ってなる
型推論が流行ってる(のかはわからないが)から型推論の書き方+αで書けるようにしたってことか
たぶん型後置の方が合理的という点には大方の一致があって、あとは合理性を取るか、Cの語順に近づけることを取るかっていう感じなんじゃないかな？
pascalがそういう記法だけど、コンパイル速いのはpascalがコンパイラの都合に合わせた文法だからって読んだことある。
何かしらコンパイラが解釈し易い記法なんじゃね？
Pascalの構文は再帰的パーサを簡単に書けるLL(1)文法なんじゃなかったかな
LL(1)ならトップダウンで構文解析できるからパーサは書きやすいしパーサの効率も多分だけど高い
Cの場合は、例えば
atype;
という宣言があった場合、"atype"という識別子が
１．typedefで型の名前として既に定義済であれば「変数が指定されてない構文エラー」となるし
２．そうでない場合、"atype"という名前のint型の変数の宣言として扱われ
２―１．"atype"という変数が既に宣言済であれば２重宣言のエラー、
２―２．そうでなければ正しい変数宣言
となるので、構文解析の際にsymbol tableを参照する必要がある（つまり本質的なレベルで文脈依存文法）ケースが存在するので
当然ながらコンパイラの効率が下がるだろうね
今のobject pascalはジェネリクスもあるしどうだろう？
v: Type形式なら変数の型だけでなく、式に型をつける構文としてもそのまま使えるから。
これは評判が悪かった
悪いのはポインタだけだというのがJava
全部悪いから全部変えるのが次世代
いまいち統一感がないんだよな。:のままだと構文的にうまくない部分があるんだろうか。
C方式に慣らされてるからそう感じるだけであって
あれはパースしづらいクソ構文だよ
struct S s;
を捨てたのは何でだろうと問うべきだよ
静的型は悪くない、だがジェネリクスは不要、ただし Array<T> 等はこっそり入れておく
こんな状態で統一感（笑）を期待する方がおかしい
思いっきりGoだな。
まぁ、Goに統一感なんか無いし、期待してはいかんw
あれは誰でもかける便利な言語だよ。
一切の原理原則以外を排除する崇高な思想で作られた芸術品ではなくて、
「その辺にある便利そうなものを誤謬矛盾なく突っ込めるようにそれなりにルール作りました。
とりあえずこのルール破ると突っ込めなくなるからやめてね。コンパイルさせないよ。」
という、実用のためのルールが細かいのがGoだよ。
電動ドリルのチャックとビットの規格みたいなもん。
「対称性がなくなるからこのメソッドを実装する」という発想ではない。
口実やね。
専用品と汎用品なら、圧倒的に前者の方か仕様変更の回数は少ない。
無理に延命したり使いましたりしたいからこそ、よくわからん仕様変更するハメになる。
無駄な仕様変更なら、最初からしなけりゃいいんだよ。
無駄なんでしょ。
使い捨てを使い捨てと認識する事こそがスタート地点。
歯が折れたら取り替えたいし、違う歯を使いたいからチャックがあるんだから。
歯の代わりにバフ付けることも出来るけど、それに対して仕様変更なんか要らないでしょ。バフを新規に作るだけじゃん。
置換原則出してきて証明する必要も無い。
>>203
そうだ、と言う認識だなぁ、俺は。
PHPも同じ理由で、いろんな意味でとても潔い言語だと思うよ。
どう違うかをきっちり教えて欲しいわ。
本当に勉強になったら素直に勉強になったと言うことにしてるし、実際何度もそうレスしてるよ。
言語なんて外から見たときに一意に呼び出し規約や入出力が決まってりゃそれでいいんだよ。
これでも素晴らしい言語とやらを5個10個と多数見てから言ってるんだけどな。
それ以上の、実用性以上の思想の旗を振りたいなら、何故その思想が必要か語ってほしい。
キャストの前置や後置と何か違うのかなぁ。
って考えたら「宣言文 名前 型」の方が遥かに簡単にパースできるなって思わんのかな。
式に型をつけるってのも、コンパイラに教える意味での型か、キャストの型か2つの意味あるけど、どっちの事かな。
疑問。
多分それは使い捨てではなく交換
これを捨てる代わりにあれが欲しい
見返りがあれば捨てるが無条件に捨てられそうになったら使い捨てに反対するだろう
haskell みたいにな。
静的型の原理だけで理解できるから
「交換できる、交換出来ない」と「使い捨てである、改良を加えて連用する」は同時にどの組み合わせも成り立つのでは？
これを捨てる代わりに、これと同じ機能プラスαの新ライブラリを作る、みたいな話で、
完全に前方後方互換の代替品であるかもしれないし、そうではないものかもしれない。
そういう意味では、無条件に捨てる事ができるってのは立派な見返りだよ。
Haskellは美しさが売りなんだから。
むしろ美しさを保ったまま、どこまで実用的なの作れるかが楽しいんだよ。
そう言う意味じゃsmalltalkと同じ、純粋xx言語でxxの真髄理解するなら〜って言語であって、次世代言語じゃあない。
ならPrologの方が賢いし、Scalaの方がまともだし、Lispの方が最低限の原理から出来てるから、Haskellは要らない子だな。
それそれ。エスペラント語とかロジバンみたいなもん。
実用的ではないけど面白いのは認める。
何気にあのレベルに便利な型システム他に見ない
OCamlの方がシンプルかな。
Haxeの方が記法はきれい。
Kotlinはいささか冗長で使い物になるのかな？みたいな羊感出てるけど、when使うときに逆に便利になる。
信者が煩いとこもソックリ
アンチがウザいのもそっくりだよね
どっちの信者？
アンチが無知なのもそっくりだよね
Smalltalkの時代遅れのIDEモドキ？を使ってみると、
終わった言語の進化に取り残されてる感がよく分かるし
こんな出来損ないを使うの強制されるSmalltalkerって哀れだなーって優しい気持ちになれるよ
言語としてはどこらへんがゴミなの？
動的型言語の中ではぶっちぎりで冗長なコードになるところ
文字列クラスクラスがあれば壊れたクラスを使い捨てて新品のクラスに交換できるのに
クラスが壊れるという事自体が糞めんどくさい
ひとつのプロセス内で遅延結合しても意味が無い
アホは適切な抽象化レベルってものが分からないから
やりすぎてナンセンスになっちゃうんだよね
Smalltalkはアホがナンセンスなデザインした結果死ぬべくして死んだ言語
あの辛さはやってみるまで想像もつかなかった
システム構築中に得られた新たな知見を、既に構築済みだったり運用中の部分へ適用できたり
オブジェクトとそのストアを長期にわたって運用し続けるために細胞の新陳代謝を模した試みだから
http://metatoys.org/oxymoron/oxymoron.html
'70年代からほんの数回の再起動で動き続けている同システムは狙いとしては成功しているんだよね
RWHにその辺の解決策載ってるから手元に置いとくと良い。
意味無いとは言わんがなぁ。
プロセス内でもプロトコル決めてやっとくと、あとでスケールするとか、
固まりへのインアウトが自ずと決まるから可換だと言いやすいとは思う。
やりすぎると自分の重さで死ぬだけで。
Haskellと比べてOCamlがシンプルって
SMLと勘違いしてない？
してないよw
シンプルってのは字数が少ないって意味じゃないぞ。
そんなら勘違いしてるね
時代によって変わる程度問題だけどね。
C++だって、昔はクラスってなんだよ。Cより遅くなるじゃねーかって言われてたらしい。
昔よりも抽象度の高さが問題になる場面は少ない。
まずはファイル名とキーワードを受け取って、ファイルの中にキーワードがあったらTrue。無かったらFalseと表示するコマンド。
プログラミング自体から離れてだいぶ経ったので、錆びた頭だったがHaskellでどうにか書いてみた。
search部分を拡張してくから、各自searchは自前で書いてくれ。
import System.Environment
search _ [] = False
search s ns | take (length s) ns == s = True
search s (_:ns) = search s ns
main = do
arga <- getArgs
content <- readFile $ args!!0
print $ search (args!!1) content
http://ws.stfx.eu/JD8JH4XF3I3U
Go版ももう少しマシな感じにしてみた
http://ideone.com/aFqKsd
プログラム組みたいのであってクラス作りたいんじゃ無いんだぞ？
いや別に>>240へのレスというわけではないのだが…
これでいいか？（Squeak Smalltalk、もしくはPharo）
| search |
search := [:fname :keywd |
FileStream oldFileNamed: fname do: [:file |
(file findString: keywd) > 0
]
].
search value: 'test.txt' value: 'something' "=> true "
http://ws.stfx.eu/1UQT4K8GSVHU
それだとコンパイル通らないよ
import System.Environment (getArgs)
import System.IO (readFile)
import Data.List (isInfixOf)
search :: String -> String -> Bool
search = isInfixOf
main :: IO ()
main = do
(word:file:_) <- getArgs
putStrLn . show =<< search word <$> readFile file
通ったけど。。。
おk。
強いて言えば、この後拡張する時、どこまで今のコードから書き換えないで済ませられるかが仕様変更に強い基準になると思う。
そのままじゃ通らなかった
けどごめんね、詳しく見てなかったけど駄目だったのはタイポだけだったみたいだね
LinuxにHaskell入れたばかりなのでPCで実行確認してiPhoneで書き込んでるんで、コピペでコンパイル出来ない時はどこかタイポあると思う。
一応、第三形態までの予定。
明後日から夜勤なんで、第三形態どうすっかな。
そうなのかなぁ。
例えばそれぞれのどんな例からシンプルさがわかる？
後学のため教えて欲しい
Go版、マシどころか疎にしておいたところ密にされてしまったな。
ノブのないドア、ノブはあるけどラッチのないドア
実現する術がなくなったね。
With Withなんて気色悪い無理に継承関係を作ったような型作るくらいならもう継承とか全部捨てたほうがマシ。
もうちょっと真面目にやって。
参照、ポインタ、値を自由に扱えてかつ新しい言語の特徴を捉えてるような言語が出てほしい
前スレの埋め込みを使った再帰型の試みとして、主要なメソッドを再定義しなければならない版より「マシ」と言ったまでで
君のチャンネル版よりマシという意味ではない
それは他言語版と同じ設計で比較しやすくしたって程度だから気にしないで
気を悪くしないで欲しいがHaskell外してKotlinは個人的にはないかな。
敢えて外すなら次世代感満載のAgdaを入れて欲しい。
が、呼び水としての趣旨からしたらHaskellを敢えて外す理由が分からない、個人的な怨嗟？
あと前スレでまともなコードを掲示しなかったので、そもそもHaskellerが居ない事が分かった
Javaより古いHaskellを次世代言語に混ぜた初代スレの>>1がどうかしている。
初代スレはHaskellの美しさを語るエアプログラマーが多かったが
次世代言語の実用性を語るスレに変わってよかったと思うよ。
次世代じゃ無いけど、学ぶべき価値ある言語。
参考まで、ほぼ同じ設計にした場合の
Ruby版 http://ideone.com/7VnOfe
Python版 http://ideone.com/UngSO8
Scala版 http://scastie.org/30851
Swift版 http://swift.sandbox.bluemix.net/#/repl/59032b64ebfba02b8d274320
Mix-inとか言われては書けなかったね。
普通のクラス代りなら何とかなったが。
そもそも目的のプログラム作るアプローチとして関数かクラスかなのに、クラス作れは問題としてオブジェクト指向に有利過ぎ。
実際に動くプログラムで拡張勝負のが公平っしょ。
だから>>240提案した。
なるほど。申し訳ない絡み方したな。
smalltalkでもパッシングに徹すればひたすらコーディング量はあるけど割りと文句無いのできそう。
>>256
Kotlinなしなの？使いやすいのに。実用性あるから？
証明付きでプログラム書けとかなったら、Coqなどの証明支援系の独壇場で、
他言語の入り込む余地がないように思われるが如何？
Kotlinは言語としては悪くないけど次世代感は感じない
golangぐらい簡素な仕様にしてくれればまた違ったとは思うけどJVM言語だしなあ
ライブラリ関係ないなら、ライブラリがない言語でも参加しやすい
> smalltalkでもパッシングに徹すればひたすらコーディング量はあるけど割りと文句無いのできそう
具体的にはどこらへんにその「量」を感じた？
ドアの振る舞いを記述してるコード自体はGoで書くよりずっと簡潔でステップ数も少ないはずだけど
念のため補足すると件のSmalltalk版では、通常はGUIやIDE任せにするクラスやメソッドの定義
（ちなみにGNU Smalltalkなどを除き、IDE前提のSmalltalkにはクラスやメソッド定義の構文が無い）
をあえてクラスへのメッセージングでやっているのでそのぶん冗長にみえるかもしれないけど
Goが得意な技法はダメ、Smalltalkで書きやすい技法だけ使って書くっていう縛りでもあるの？
同意
どうしてそういう発想になるのか全く不明。
人間の言葉でしゃべって。
>>267 を補足すると、
compile:とかがやたら続いているコードブロックがクラスやトレイトの定義に相当する部分で、
それ以外がドアやストッパーを操作するサンプルコードな。
いや別に拘ってないですよ
そもそも誤解があるようなので断わっておくとGoを貶めるつもりは全然なくて
Smalltalkに難癖を付けてるID:BE072L/9が前スレからGoが詳しそうなんで
その方がわかりやすかろうとGoを引き合いに出したまでです
Goの得意な技法を駆使した優れた設計ってどんなのですか？ぜひ教えてください
今のところ埋め込みスタイル以外で出ているのだとこういうのでしょうか？→http://ideone.com/yvttId
このお題自体では設計を工夫しにくいと言うことであれば、新たにGoに有利なお題をご提供いただければと
あと、
> Smalltalkで書きやすい技法だけ使って書くっていう縛り
とのご指摘ですが、少なくとも Ruby、Python、Scala、Swift では Go よりすんなり書けています>>260 から
旧世代言語で書きやすい…ならともかく、Smalltalkで書きやすい技法だけって縛りにはならないですよね？
答える側には間違えるリスクがあるのに問う側を無リスクで無謬とするのは不公平
chan と select 使ったサーバープログラムなんでねーの。
ああいうふうにチャンネルに放り込んだものを適当に一列に並べてくれるのはかなり楽。
単純な力押し検索だから、難しいアルゴリズムでも無いんだが。。。
おいらも頭悪いんよ。
>>244の書き方でargs書き換えと、nsをcontentから取ってcsへ変更。sも折角だからwordから取ってwへ。
import System.Environment
search _ [] = False
search w cs | take (length w) cs == w = True
search w (_:cs) = search w cs
main = do
(file:word:_) <- getArgs
content <- readFile file
print $ search word content
どんな変更があるか事前準備したクラスがあってもおk。
第三形態までの変更箇所の少なさが言語の優劣とする。
主観としての悪評価と客観としての悪評価を混同すんなよ…。
採点してる訳じゃないんだから。そこまで傲慢でも無いよ。
俺Rubyボロクソに言ってるけど、主観としてだよ。
>>280
並列化を意識してるんじゃないよ。
コンポーネントとして存在し得るかを考えただけ。
ノブがノブだけで存在できないなんておかしいじゃん。何にも繋がってない地面に転がったノブさえ定義できないのに、突然ドアについてる突起をノブだと言うくらい不自然じゃないの？
オブジェクト指向ってなんなの？
地面に転がってるのも、ドアについててもノブであって、ノブとしての役割を果たしているか否かでしかないのでは？
確かにそのノブがノブとして成立するのはドアについたときだろうけど、それ以前からそいつ自身の存在が変わったわけじゃないじゃん。
んー。クローザーついてないドアにもスレッド使ってなかったっけ？
スレッドと言うかまあマイクロスレッド使ってるけど。
キューイングしてる所で同期をGoにやってもらった形に近い。
イベントやらメッセージパッシングと変わらんつもりだけど、キュー抜いて中もgoroutineなのは確かに悪手は悪手か。
それは確かにそうだな。
ラッチの開閉すら実装出来ないと前スレで判明してのによく再登場出来るな
実装はできてたでしょ？
良く飽きないな
主に決めるのは外人だ
まるでトクホや世界遺産に採用されるみたいな
官僚主義だな
主観で悪評価しているなら、それこそ難癖以外の要素ゼロじゃないか。
物を作る道具としては失格だな
叩きたいことと叩くべきことが一致してない
無意味なむずかしさだわ。
自分で正しくプログラム組めてませんって言ってるようなもんじゃん。。。
x性的型が
o静的型が
キャットドア問題って言いたいだけだろお前
すでに答えは出てるし、そもそも問題の把握すら出来てないじゃないか？
>>276
ライブラリ使うのとかはありかな？
主旨から外れるかもしれないが、こんなのどうだろう
import System.Environment
import Data.Conduit
import qualified Data.Conduit.Text as CT
import qualified Data.Conduit.Binary as CB
import Control.Monad.Trans.Resource
import qualified Data.Text as T
import Control.Monad.IO.Class (MonadIO)
searchSink :: (Monad m, MonadIO m) => T.Text -> Sink T.Text m Bool
searchSink w = do
n <- await
return $ case n of
Nothing -> False
Just s -> T.isInfixOf w s
main :: IO ()
main = do
(file:word:_) <- getArgs
x <- runResourceT
$ CB.sourceFile file
$= CT.decode CT.utf8
$$ searchSink (T.pack word)
print x
仕様変更への耐性を競うだけなので、まあライブラリ使ってもそれで仕様変更に強いなら構わないけど。。。
Haskellとsmalltalkしか回答寄せて貰えてない。。。
キャットドアのクラス作るだけの問題よりも、客からこんな機能付けてって要望に応える形で仕様変更されたのを如何にコード変えずに対応するかって問題は実践向きで良いと思ったんだが。。。
明後日には書くので、第二形態の問題だけ出しとく。
ファイル中に検索するキーワード見つかったら、見つかった数も表示するように機能追加。
見つからなかった時は表示しなくても良いし、表示を分けるの面倒臭かったら0個って表示で見つかった時と表示機能を共有しても良い。
なるほどね
ならConduit使った方が処理簡単に挟めるから、仕様変更には強いと思う
あとはストリーム処理だから読み込むファイルが巨大になっても一定のメモリしか使わないってのも考えてみた
多分実戦向きの問題でいい感じなんだと思うんだけど、出題レスがとっちらかってて全部探すのめんどくさくてやる気起きなくてすまん
綺麗に纏まったレスどれ？
意図が良く分からないんだけど、Pythonで言えば
from sys import argv
def search(path, word):
____with open(path) as f:
________for l in f:
____________if word in l:
________________return True
________else:
____________return False
if __name__ == '__main__':
____print(search(argv[1], argv[2]))
みたいなのでいいの？ とりあえず書き捨ての簡単なプログラムから初めて拡張していく感じで
多分これ拡張しろって言われたらsearch関数まるっと書き直しちゃうけど
オブジェクト指向も関数型言語も、仕様変更に強いって言われて広まったり注目されてるから、次世代言語も仕様変更に強くないと使える言語と言えないと思って。
だから、書き捨てでも良いし、どんな変更が来るか事前に予測した設計でも良いけど、設計変更に強いと言うのを示せるか？って感じ。
ちなみに私のHaskellは何にも考えてはいない。
自信があるとかじゃなくて、デザパタとか知らない。
関数型言語が設計変更に強いなら、まあ何とかなるだろうってノリ。
全体の趣旨
>>277
第一形態
>>240
第二形態<-今ここ
>>304
Pythonで言えば
def count(path, word):
____with open(path) as f:
________return sum(l.count(word) for l in f)
でも追加しておけばOKだな。うん。searchの内容一切使ってないけど変更は3行やね
つーかsearchももっと短くできたな
仕様変更に強いっていってもこのお題の長さなら仕様変更というより新たに書き上げる短さを競うことになるな
一切再利用考えなくても三行だし
| search |
search := [:fname :keywd |
FileStream oldFileNamed: fname do: [:file |
| count |
count := 0.
[file match: keywd] whileTrue: [
count := count + 1.
file atEnd ifFalse: [file skip: 1 - keywd size]].
count
]
].
search value: 'test.txt' value: 'something'
http://ws.stfx.eu/RU59LGEMKG9G
search test.txt hoge
Ture 4
みたいな感じに表示項目増えるように第一形態のコードを育てる様にして欲しいんだが。。。
関数名以外は中身が丸っと変わっても良いけどさ。
それはおかしいやろ
一回作った関数の振る舞いを変更するのはおかしい。別の関数を作るべき
search test.txt hoge
(True,4)
ってする予定。
そう言う問題も第二弾として考えてる。
searchはもっと短い実装思いついたから短くした。
from sys import argv
def search(path, word): # 1st
____with open(path) as f: # 1st
________return any(word in l for l in f) # 1st
def count(path, word): # 2nd
____with open(path) as f: # 2nd
________return sum(l.count(word) for l in f) # 2nd
if __name__ == '__main__':
# print(search(argv[1], argv[2])) # 1st
print(count(argv[1], argv[2])) # 2nd
変更は2ndって書いてある4行。一切再利用とかしてないけど、このお題に関して分かりやすさ、変更の少なさ、安全さでこれ超えるのは無理でしょ
やりたいことは了解したけど、回答者としては適切な設計でいきたいから、再利用したほうがいいと判断するまで再利用しないからな
まあいい具合に短いし気が向いたら次世代っぽい言語でもやってみるか
ファイルの行ごとの内容はメモリに収まる程度なのか、とか
例えば 'xxxoooxxx' という文字列内に 'oo' は１個なのか２個なのか、とかは
回答側の都合がいいように自由に決めていい？
バグのない完成品に機能追加して多機能化すれば優秀さを示せるって発想か
嫌な予感がする
可換であるべき理由を殺しに来てるよね。
どういう意味？
再利用せずに入れ替えたいから、その部品が使われるときのインターフェイスを定義して、関係ないものをカプセル化するんじゃん？
再利用して無理に機能追加してると、割りと早めにインターフェイスは形骸化するよ。
引き戸である、とか、このドアは回転扉で開けると反対が閉まる、とか、エアロックみたく、どちらかしか開かない制限をかけたいとか、そういう要件で安易に
扉だったものを魔改造するハメになる。
そうすると、インターフェイスってものや、カプセル化ってものが、完全に無意味になる。
魔改造されてて、本来の意味を失ったインターフェイスの「ドアを押す」メソッドとか怖すぎるじゃん。
横レスだけど
ざっくり言うとインターフェイスや型クラスの存在理由を殺しにかかってるって意味だよね
元の言い方だとちょっとわからなかったよ
インターフェイス、型、あとはクラス構造自体の意義、もうちょっと広くとっても良いかなって思って。
Cでもアセンブラでも可換な作り方って出来るから、あまりに具体例にするのも話が矮小化しそうだなぁって思ったんよ。
申し訳ない。
「も、含めて」とかちょっと言い方考えるわ。
言いたいことはわかるよ
ただ可換なって言うだけだと
上の問題例もアリになっちゃうかなと…
もっとUI作りやすい言語くれよ。
あーなるほど。
難しいもんだな。表現ってのは。
ありがとう、勉強になる。ちょっともう少し練ってから話すわ。
行は基本メモリに収まる程度だよ。
小説とか、常識的なテキストで問題無ければおk。
行に一個二個を回答側の都合ってのは普通駄目だろう。。。
でも、あんまりにも回答者いないんでもう良いよ。。。
あー。。。
あんま考えずに提案してたわ。。。
うーん。。。
インターフェースは変えずにって条件付ける？
実際に引数増やさないと駄目な時は補助関数作って、実際の処理はそっちに丸投げみたいな形で。
一応第二弾ではそう言うのも考慮して、既存の関数に手を加えないで機能拡張ってテーマで行く予定だけど。
> 行に一個二個を回答側の都合ってのは普通駄目だろう。。。
であれば、正規表現に丸投げするのでもなければ処理内容にも影響するので
例えば 'xxxoooxxx' 内に 'oo' は１個と数えるか２個と数えるかとかは出題側で事前にきちんと決めてください
勘違いしてた。
そう言うことね。
ラッキー7(777)検索してて7777ってなってたら1個と数えるか2個と数えるかって事か。
私の方法だと2個に数えてるので2個にしましょう。
jsで言うと(content+'').split(delimiter).length-1だから。
「小説とか」ということは、日本語の可能性もあるの？その場合に想定してるエンコードは？
とにかくideone.comとかで参加者が気軽に動作を確認でき、かつ仕様を満たした回答例を先に出しといてください
実戦向きとか言うわりに細かな仕様がまったくわからんし、動くコードでもなければエスパーするにも限界があるよ
どうにもならんね
+'' ってなんかのおまじない？
splitがundefにならんように、文字列とコンカチしてる。
なるほど
ただ、それでエラーは出なくなるだろうけどバグが見つかりにくくなる悪寒しかしない
数数えるんだから、数えられないものが来たらゼロになっていいんよ。
そうなんだ。。。
じゃあ、両方のを書くのでどっちもおkにします。
>>340
長さは？とか聞かれて小説とかって書いたけど、今回は適当なソース読ませる程度しか想定してないし、参入障壁にしたくないからアスキー文字だけしか想定してない。
本当、思い付きで申し訳ない。
そんな訳で下のコードをコピペして検索にかけると
>search search.hs search
(True,16)
ってなるはず。
んで、777を検索して7777を1個と数える版はsearch2として書いてみた。
最早Pythonよりも修正箇所多そうだけど気にしない。
do形式よりモナド形式が好きなのでdo形式コメントアウトしてるのは気にしないで欲しい。
(ちょうど良かったんで7777を確認用にdoの後ろに追加してる)
search w cts = search' (False,0) w cts
where
search' (b,n) _ [] = (b,n)
search' (_,n) w (c:cs) | take (length w) (c:cs) == w = search' (True,n + 1) w cs
search' t w (_,cs) = search' t w cs
search2 w cts = search' (False,0) w cts
where
search' (b,n) _ [] = (b,n)
search' (_,n) w cts | take (length w) cts == w = search' (True,n + 1) w $ drop (length w) cts
search' t w (_:cs) = search' t w cs
-- main = do 7777
-- (file:word:_) <- getArgs
-- content <- readFile file
-- print $ search word content
main = getArgs >>= \(file:word) -> readFile file >>= print.search word
contentがundefinedでdelimiterが'e'とかだったら？
undefinedと空文字列かー、jsdoだと空になったけど、文字列化してしまうなら辛いな。
>>309で一旦まとめて
インターフェース(引数)固定縛り。
(補助関数可)
英数字のみのファイル前提。
行やファイル全体もメモリに収まる程度を想定。
777で検索した際、7777は検索結果1個とカウントしても2個とカウントしてもおk。
んじゃ、検索で見つけた位置も追加で表示するように拡張。
import System.Environment
search w = search' (False,0,[],(1,0)) w
where
search' (b,n,ps,_) _ [] = (b,n,reverse ps)
search' (b,n,ps,(y,_)) w (c:cs) | c == '\n' = search' (b,n,ps,(y + 1,0)) w cs
search' (_,n,ps,(y,x)) w (c:cs) | take (length w) (c:cs) == w = search' (True,n + 1,(y,x + 1):ps,(y,x + 1)) w cs
search' (b,n,ps,(y,x)) w (_:cs) = search' (b,n,ps,(y, x + 1)) w cs
search2 w = search' (False,0,[],(1,0)) w
where
search' (b,n,ps,_) _ [] = (b,n,reverse ps)
search' (b,n,ps,(y,_)) w (c:cs) | c == '\n' = search' (b,n,ps,(y + 1,0)) w cs
search' (_,n,ps,(y, x)) w cts | take (length w) cts == w = search' (True,n + 1,(y, x + 1):ps,(y, x + 1)) w $ drop (length w) cts
search' (b,n,ps,(y,x)) w (_:cs) = search' (b,n,ps,(y, x + 1)) w cs
-- main = do 7777
-- (file:word:_) <- getArgs
-- content <- readFile file
-- print $ search word content
main = getArgs >>= \(file:word:_) -> readFile file >>= print.search2 word
>search test.txt search
(True,16,[(3,1),(3,11),(5,1),(6,1),(6,51),(7,1),(7,17),(9,1),(9,12),(11,1),(12,1),(12,45),(13,1),(13,17),(18,12),(20,60)])
第三形態まで出たんだから、次世代言語勢たのんますよ。
本当。
英数字のみのテキストファイルと検索文字列を受け取るコマンド。
行の長さや、ファイル自体の大きさは常識の範囲内。(メモリに収まる大きさ)
関数のインターフェース(引数)固定縛り。
第一形態からなるべく大きな変更無しで拡張して行くルール。
第一形態
検索文字列が存在するかどうかのみ表示
第二形態
検索文字列の存在と何個あるか表示
第三形態
検索文字列の存在、個数、見つかった位置を表示
Haskell
第一形態
>>276
第二形態
>>348
第三形態
>>355
ガバガバでは？
type LookupResult struct {
//略
}
func (lr LookupResult) foundAsBool Bool{
return lr.found
}
func Lookup(needle,haystack String) LookupResult{
//検索処理
return LookupResult{found:結果}
}
って第一形態書いとけば、LookupResultが超リッチになってくだけでインターフェイスもへったくれもない石器時代の発想で書けちゃうよ。
そして往々にして業務アプリ屋ならちょっと気がおかしいレベルで、こんな形で結果をラップする事を徹底してる。
大きな変更は無いけど、いい事も無い。
あ、ごめん。foundAsBoolの後ろに()無いな。
7777を一個と数える版(search2)でバグあった。
見つけたらdrop (length w)してるんだから、リストに追加する発見位置はそのままだけど、現在位置は検索文字列の長さ分足さなきゃだった。
適当に修正お願いします。(おい)
そう、バッテリー付き言語ならね
次世代言語議論してないよな
>>348のコードをコピペしたテスト用テキストだとこう表示されるはず。
>search test.txt search
(True,16,[(3,1),(3,16),(5,1),(6,1),(6,56),(7,1),(7,22),(9,1),(9,17),(11,1),(12,1),(12,50),(13,1),(13,22),(18,12),(20,60)])
10年前から主要言語TOP10は変わってないという事実をお忘れなきように
>>259
import System.Environment(getArgs)
import Data.List(isInfixOf,isPrefixOf,tails,findIndices)
search1 = isInfixOf
search2 word = length . filter (isPrefixOf word) . tails
search3 word content = (ps /= [], length ps, ps)
where ps = concat . zipWith indices [0..] $ lines content
indices l = zip (repeat l) . findIndices (isPrefixOf word) . tails
main = do
(file:word:_) <- getArgs
print =<< search1 word <$> readFile file
print =<< search2 word <$> readFile file
print =<< search3 word <$> readFile file
第二形態書いた時点で第一形態は、第二形態を中で呼ぶ様に書き換えないと悲劇だし、第三形態も同じ。
レビューで辛辣な第一形態を安易に書いたdisりを受けたあと、直交性が失われるために、それより前の形態をAPIとしてobsoluteにしてライブラリ関数とかマクロに降格するレベルだよね。
Data.Listの関数はisInfixOfとisPrefixOf、tailsを本で読んだだけで使った事ないな。。。
それ以外は見た事すらない。
ちゃんと使うと、ここまで書けるのね。
そう言う意味じゃ、おいらのは入門書前半の知識だけでも書けるって感じやね。
おいらがHaskell好きなのは美しさもだけど、ひたすらミニマムな知識だけでも何とかなっちゃうのが良い。
数学と同じで便利な関数知ってれば、強力な武器だし周りからは難しそうに見えるけど、基本はとても簡単で、少ない武器でもどうにかこうにか自力でも解ける。
これこそ初心者向け言語だって思ってるんだけどねぇ。。。
Haskell追い出せるだけの次世代言語の立派な回答求む。
search1st := [:str :kw | str includesSubstring: kw].
search2nd := [:str :kw | (str splitOn: kw) size - 1 ].
search3rd := [:str :kw |
Array streamContents: [:ss |
(str lines collect: #readStream) doWithIndex: [:strm :idx |
[strm match: kw] whileTrue: [ss nextPut: idx -> (strm position - kw size + 1)].
]
]
].
http://ws.stfx.eu/DQART2BS6GYF
でもCの地盤沈下は確実に進んでるわけで
まー2017にはさすがにCOBOL使ってるシステムも
リプレースされただろ？されてるよね？ってところ
search3rd := [:str :kw |
(str lines collectWithIndex: [:line :idx |
(line allRangesOfSubstring: kw) collect: [:range | idx -> range first]
]) concatenation
].
http://ws.stfx.eu/A3HB6MT66GI5
実際問題キャットドアより簡単だから。
次世代言語以外が回答してるのがおかしいから。
Ｆｏｒｔｕｎは７７じゃないよね
スレタイに挙げられた言語は局所最適の枝葉末節だらけで参考にならない。
ここまで来てなんで一つもKotlinとかGoで書くやつがいないのか。
簡単だし時間かからないだろ？
Smalltalk馬鹿にしてる奴も意味不明。
夜か明日、書いてもいいけど、全く以って問題が悪すぎて、次世代もクソも無いと思うよ。
現実、3.x だから第3形態じゃないのか？
0.9 もあったから第4形態かもしれんが。
それが次世代言語の意義なんだよ。
便利なスレだな。
問題が悪いからと言って次世代言語が降ってこないのは当たり前と言うか、
自動車が発明される前に人々にニーズ調査したら「すごく早くて馬が疲れにくい、壊れにくい馬車がほしい」って答えただろうってフォードのおっさんの名言に尽きるだろ。
英文は無理でも言語名の綴りぐらいはちゃんと書こうね
ForceじゃなくてForth
FortrunじゃなくてFortran
pascalはPascal
（固有名詞だから頭文字は大文字、なお全部を大文字で書く・・・PASCAL・・・か否かは趣味の問題だが
全部を大文字で書くのは小文字がディスプレイやプリンタで表示・印字できなかった古い時代の名前というニュアンスが加わる）
すぐ手前の流れも読まないPython使いってなんかマヌケだね
結局それか
何か叩いてないと安心できないだけ
だがしかしコードをちゃんと読めて（あるいは書けて）改めて糞だと言えてる奴がどのくらいいるかは怪しいな
ドア→実用なし→糞と短絡してるだけとか
実際、>>404や>>405はドアのお題、何分ぐらいで書けるの？
Juliaの書いて、書いた上でドア糞って言い始めたのは俺だぞ
あれ思い出しながら書いたから一時間くらいのかかったわ
なんか言語仕様変更してる所とかあったし
で>>404は？
Images のデータ構造また変えやがった。いい加減にしてくれ。
あれはコンポジットで解決だろ
その前に問題点理解できてるのか？
Kotlin: http://ideone.com/9xPk7i
既存言語の着せ替えでしか無いなら、プログラムの組み易さも大差無かろう。
Haskellスレのおいらの過去の書き込みより。
341 名前:デフォルトの名無しさん [sage] :2017/04/29(土) 15:22:04.96 ID:nyANDfpK
デザパタみたいなの？
パターンって程実践で使われてないだろ。
んー。。。
使ってた感触だと、割と行き当たりばったりからの仕様変更でも何とかなるのが関数型言語の強み？と思わなくも無い。
ちょっとの変更にも関数経由するから、自然と既存の関数使い回せないか考えるし、関数型言語もそう言う風に進化して行ってるように感じる。
某スレで話題になったキャットドアクラスも、変な縛りがなければ究極的には機能の組み合わせでドアが開くかどうかの問題なのだから、タプルにBoolを並べれば良い。
ただ、同じBool値ばかりだと違う機能を付いてる(付いてない)と表現しやすいので、適当な型を作ってコンパイラが順番間違えたらエラー出すようにする。
cd = (False,型Aの値)
値が欲しかったら
getA t = snd t
または引数の時点で直接欲しい値にアクセス。
getA (_,x) = x
仕様の拡張に関してはタプルを入れ子にする事とする。
継承というよりは委譲に近い。
理屈では(以前の機能,拡張機能)の形でいくらでも入れ子に出来る。
cdEx = (cd,型Cの値,型Dの値)
cdFX = (cdEx,型Eの値)
基本機能だけなら基本のタプル取り出して使う。
getA $ fst cdEx
拡張機能だけまたは、拡張機能と基本機能の組み合わせは引数の時点で(以下略)
getC (_,x,_) = x
getAD ((_,x),_,y) = x + y
ただ、関数型言語は元々多くの状態を管理するのに向かない。
例の通り、構造が複雑になると扱い難い。
HTMLなりXMLなりXAMLなりに状態管理は任せた方がいい。
んじゃ、おいら夜勤明けなんで寝るわ。
お休みzzz...
オブジェクト指向をむりやり c でやったように。
結局それが正解。
私はただHaskellに惚れてるだけで、ここが良いって紹介もするけど、それって結局Lisperと同じ道を歩んでると思う。
一人称が真面目モードに。
x私
oおいら
言語なのかどうか知らんけど。
ひとつはScalaやSwiftのように従来のOOPLをベースにして（つまり機能は特に削らずに）
これまで関数型言語の独擅場だった型推論やオプショナル型といった型システムのサポートを手厚くしたもの
もうひとつは、さらに一歩進めていろいろな不都合の元凶であったクラス（もっというと継承）を外して言語機能を大胆にシンプルにしたもの
GoやRustがこれにあたる…ってところか
あと個人的には並行・並列処理のサポートを手厚くした言語、Clojureや前と重複するけどGoとかも
この調子でコアが増え続ければ重宝されると思う
Rubyは両方を狙っているけどたぶん失敗する
風呂敷広げ過ぎた悲壮感減ってきてる。
ただ、それでもすごく安全なCとして使うほうが便利な気がするわ。
そりゃ何も出来なきゃ安全だよな。
RcとRefCellで書けるんじゃないの？
sml/nj
教科書的に書くだけならな。Cのように実用に耐え得るものは書けない
ttps://hackernoon.com/why-im-dropping-rust-fd1c32986c88
この人が行き詰まってるのは、オブジェクト指向そのまま当てたからでは？
structのImplでもなく、traitの関数でもなく、
traitのImplで書けば何とかなりそうだけど。
あと、サイズを取得したいだけなら、lifetimeを明示してCopyちゃんとすれば良いのでは？
そういう種類のごまかしをするやつはよくいる。
この人が行き詰まってるのは、借用とは割と関係ないオブジェクト指向脳ではって話してるんだけどなぁ。
CでもMISRA-C通そうと思うと木構造相当辛いし。
産業向けのC書いてる奴なら耐えられるレベルの話だと思うけどなぁ。
手軽さ的には俺はGoを押し続けるが、否定するもんでもないと思うようになったな。
物が作れない最高の言語より、物がつくれる嫌われ言語の方が結局世の中に貢献するんだよな。この点ではPHPでさえRustより世の中に役に立ってる言語と言える。
成功するなんて妄想してるからChromeにシェア完全に奪われたんじゃねーの？
守ってない部分はGoやらなんやら、もっと手軽な物で書いたほうが楽じゃん。
あれは要は、ヒープやスタックの領域の担保やら、死んだポインタへのアクセスの回避やら、そういう部分に対して言語側から縛りかけて安全にしよう、ってスタンスなのでは？
本人らは推してるが、副次的にGCが無い言語になってるように見える。
>>439
歯ブラシ言語はマジで強い。PHPはdisる奴がわからんレベル。
遅いしまともじゃない動きしたりするけど「とにかく動くwebページ」は一瞬で作れる。
Goやらなんやらの出る幕がなくなってしまう
RustはCを安全に倒しすぎた結果なにも作れなくなった言語って意味では対照的。
Servoは失敗するだろうが、そこで得られた知見でRust2.0（1.xと互換性なし）が出てからが本番と見てる。
弱者を批判する批評家から弱者を守ってみろ
対抗馬のゴキちゃんは1.0リリースしたのに。
php持て囃してるやつらって、php書いたことないやつらだろ
プロトタイピングならまだしも、phpをプロダクトに使うたら頭おかすなるで
めんどくさいけど、あれ通りに書いてたらバイナリパッチ作りやすい。
>>452
世の中、プロトタイプ程度の物で充分な事が多いって事でしょ。
ねーよガイジ
ペチプァは死ね
次世代感は無い気もするけど
似た印象を持った
問題提起者が新しい型と型制約の逆転に気づいてないし、
RustをRubyか何かと勘違いしている感じだ
開発者が足りなくてライバル言語との開発競争に負けている。
それにこの用途ならNimという用途がない。
https://github.com/rust-lang/rust/graphs/contributors
https://github.com/JuliaLang/julia/graphs/contributors
https://github.com/nim-lang/Nim/graphs/contributors
PHPを書いたことがあるプログラマは全て無能のクズペチパーでFA
何それ？楽しそう。
求人多いじゃん？
でも言語としてはダメってこと？
PHPは言語ではない。まずそこからだ。
え？
まあ、EC-CUBEは開発当初流行ってたからPHPで作った
というだけで今一から同じもの作るとしたらPHPという
選択肢は無いんじゃないかなぁ。
PHPが流行ったのは歴史的な経緯が大きいと思うし。
つーかああいう馬鹿な批評家みたいなやつが生産性を落としてるんじゃねーかっていうことを
証明したのが go という印象。
夏休みの工作をフライス盤で作るような事したくないじゃんww
悪いもの使ってるから悪いものしか作れないと言う意味じゃなくてな。
俺の字が汚く見えるから鉛筆は使わない、みたいな情けない字が下手なやつの言い訳に聞こえる。
>>458
この辺思想だから、移植物だと仕方ないっちゃ仕方ないんだよね。
誰がが言ってたが生産性が高いんじゃなくて生産性を前借りしてるっていうのは言い得て妙だと思った。Rubyに対しての話だがPHPにもしっかり当てはまるな。
Goは「前借り」感が少ない。少ないだけでまだあるがRubyやPHPよりはるかにマシ
洗練されてない
くどい
従来の物のほうがなじみやすい
目立った成果をあげていない
これはさすがにアホだろ
新興言語が既存言語の積み上げた資産ぶち抜く成果上げたらびびるわ。
コンテナオーケストレーション領域やNewSQL領域みたいなそもそも新しい分野ではGoが結構強い。
【Lisp】プログラミング言語 Clojure #4【JVM】 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1483498849/
>>37
＞facebook傘下のwitaiが基盤実装をclojureからc++かhaskellに移行する予定だったらしく、haskellにしたとのこと。
＞移行したら読みやすいみたいな話もちょっとだけ。
＞
＞clojureの場合、ライブラリは一度作るまでいろいろいじって、一回出来るとあまりいじらないイメージもあるけど、実装を多人数でよくいじるみたいなのだと、難しいのかな？
＞IDE上手く使えばそういう開発もできるのだけど、最初からなんでも決まってるほうがいいってのはgo見るとわかる気もする。
＞https://wit.ai/blog/2017/05/01/new-duckling
それはその通りだろうな。
まぁ、使い捨てるためのものであって、確かにあれでバッチ処理とか書いてたのは直させたことある。
>>472
新しい概念に新しい言語はマッチするし、やっぱ効率的だと思う。
PCODEとパスカルとか。
資産活用なら、すごい親和性のKotlinかな。JavaのクラスのgetXXXとsetXXXが、勝手にクラスのプロパティになるとかすげえなって思う。
そこらへんのKotlinの機能はただのGroovyのパクリ
というか静的型以外は大体Groovyのパクリ
そういう意味じゃ c++ は先見性のある言語だったんだろうな。
肝心の言語がアレだが。
一方GoはGoogleの暴力で全部自前で資産を構築した。
当時の次世代だったじゃん、Groovy。
まぁ、KotlinもAndroidの一級言語になったし、暴力かどうかはおいといてこれからどうなるかはわからんが。
さようなら次世代言語ことりん
まぁそれ言うとRoR出る前のRubyとか・・・って話に
なっちゃうしなぁ。
別に推したい訳じゃないけど、サラサラッと見た感じ
ツボは押さえてて悪くなさそうなので、今まで俺は全然
聞いたことなかったし何故かなーと思った次第。
http://jp.techcrunch.com/2017/05/18/20170517google-makes-kotlin-a-first-class-language-for-writing-android-apps/
この中ではJuliaがリードしてる。
import System.Environment
makeList cs f = take (length cs `div` 2) [cs!!x | x <- [0..], f x]
zipArgs args = zip (makeList args even) (makeList args odd)
main = getAtgs >>= print.zipArgs
何が言いたいかと言うと、次世代言語で>>359の第4形態作りませんか？
>zipArgs hello world good by
[("hello","world"),("good","by")]
というかGoに自信ないの？
言語組み込みの１メソッドで対処できる程度のつまんないお題しか出せてないってそろそろ気付けよ
Goは文系土方を集めて開発する時の言語じゃない？
Google社員は優秀な人多そうだからGo使うより別の言語使った方が効率良いんだろ
JVMとKotlinランタイム積んだ方が総合的にスマホでは得なんだろ。
1メソッドで対応出来るの見せてもらえれば、流石次世代言語と思うけど。
じゃあ何かお題出してくださいな。
クラス作れとかじゃなくて何か実際に動くものの。
出来れば高卒のおっさんでも解けるレベルなら有難いw
今>>359をより実用的にするアイデア浮かんでて、まず上の通り複数ファイル対応の後、見つけた場所と同じ行の文章を表示させたいって思ってる。
これを一行丸々か、前後を何十文字ずつ切り取るってするか考え中だが。
なんでかしらんけど
インターフェースって書いたり文末に。つけたり
おじいちゃんなんだろうか？
若くはない。
そう歳でもないつもりだったが、おっさん言われる歳になっちまった。
次世代言語にも興味あるのに、言葉ばかりでコードがあんまり出てこないから問題出せば見られるかと思ったんだが、上手くいかないね。
↓
awk
↓
perl
↓
ruby
これで俺もおじいちゃんの仲間入り。
簡単なので良いから次世代言語のコード見て見たいのよ。
インタネット？
いつも本題と別のとこに難癖つけて荒らしてるのお前だろ
なんか明らかに引っ掻き回してる奴いるなと思ってたが、今回ので確信した
昨日から見始めたんだから
そうか次世代ではあったか
しかし動的で静的にも使えるGroovyのが書いてて楽しかった
普通のJavaコードをそのままコンパイルできたし敷居も低かった
KotlInは今使ってはいるが、優等生過ぎて自分には合わない感じがするな
ほんとかよw
半年ROMってから書き込めよクソザコナメクジ
多分こいつが犯人だろｗ
>>504
ここでこれは次世代、そうじゃないとか言っててもチラシの裏だな
ともかく、GoogleはJVM捨てる方向に行くかと思ったけど、このタイミングで捨てなかったらずっと使われるだろうな
こーでもない言って楽しむスレでしょ？
もっとマイナーな奴発掘してみても面白いんじゃないかな
やっぱjvm嫌なんかね
https://blog.jetbrains.com/kotlin/2017/05/kotlinnative-v0-2-is-out/
それは製品を選ぶ消費者が全てだと言っているようなものだな
消費者の気持ちが全てだから作者の気持ちなどは無意味だと
JVMはARTの時点でほぼ捨ててるのでは？LLVMベースのAOTに近い動きしてたと思う。
そのうちJetBrain買収して全権掌握、kotlinもやりたい放題弄りだすんじゃね
androidがjavaもどきである必要性は世界的に皆無だしみんなハッピー
でもパフォーマンスとかに問題があったからなんやかんや
していた感じで。
一時期UIというか上位層にJavaって流行ってたしナァ。
最初から大企業の強さを疑問視していた方が正しい
そのうちｺﾄﾘﾝもﾎﾟﾛﾘﾝとかにフォークされる
ここで関数型の言語指名してればGoogleもまだやるなぁと感心したけれど。
2ch住民がどんなコード書くのか見たかってん。。。
例えば>>485のコードRubyで書いて見たけど、イマイチ命令的で宣言的にはならんのよな。
次世代言語ならもっと宣言的に書けないかなとか。
書いてみ。
クラス宣言は必ずしも要らんし、データの定義だけが出来たり
クラスみたいだけど、ブロック始まって即関数ではなく束縛とか宣言できたり処理できたり関数書いたりできて、それがメソッドやプロパティになったり、
割と無茶できる言語だよ。
Googleともあろう企業がScalaのランタイム改良ではなく言語としては劣化ScalaのKotlin採用って方針にしてるのは違和感あるんだよな。
次世代ヲタからすれば、SwiftとかKotlinとかGoが憎くて憎くて仕方ないんだろうな。
低機能言語が読みやすいとは思わんけど
それなら納得できるわ。
お題
1) 1から1000までの整数からなる要素数1000の配列を作ってそれをランダムに並び替え
2) 当該配列の各要素nについて、sleep等でnミリ秒後にnを返す処理を別スレッドで起動し
3) 各スレッド終了順に配列等に結果を収めそれが昇順になっているかを真偽値で返すコードを書け。
4) 念のため (2)〜(3)にかかった時間を計測しこれも同時に提示せよ（1秒を大きく越えていないことを確認）
5) (3)が偽なら、(2)を「n*mミリ秒（mは2以上の整数）」に変えてmがいくつ以上なら真を返すかも示せ。
要はスリープソートですが…
Haskellで並列化は今一理解出来てないのか逆に遅くなる。。。
本の通りなら速くもなるんだろうが、使いこなせてない。
途中からシングルスレッド処理に切り替えるのが肝っぽい。
上手く行ったら参戦するけど、期待しないでね。
ハートリーフォック方程式を解くコードを書け
基底はガウス基底。6-31G**でのベンゼンの計算結果を示すこと！！
分子積分は並列化して下さい！！
回答例を兼ねてRubyで書いたのを晒します
手元の環境ではスレッド数的に厳しかったので100にしてmは5でした
$ ruby sleepsort.rb
m = 1; time(sec) = 0.129255; sorted? = false
m = 2; time(sec) = 0.3634174; sorted? = false
m = 3; time(sec) = 0.7056763; sorted? = false
m = 4; time(sec) = 1.1430185; sorted? = false
m = 5; time(sec) = 1.6765738; sorted? = true
http://ideone.com/RhQXqq
※ideone.comには制限があるようなのでスレッド数は更に減らして10にしています
高卒のおいらには、そもそもその方程式が分からない。。。
数学を必要とするのはほんの一部
次世代でも手続型言語が主流なのは変わらないだろう
より記述量が少なく
間違いが起こりにくく
学習時間が少ないものが今後も好まれるのではないか
samlltalkやrubyはかなり宣言的に書ける場合がある。
pythonも>>485をリスト内包表記有るからHaskellみたいに宣言的に書けるはずだし。
次世代言語が過去の言語に宣言的プログラミングで劣ったら元も子もないよ。
宣言的プログラミングに近づけば優秀というわけじゃないから
でも、手続き型言語でどこまで宣言的になったか見てみたい。
ifもforもここまで使わないで済むって。
一般にやれることがおおければそれだけ記述量は増える。
まあよく使われる書き方については短くかけるように符号を割り当てるってのは
あるのかもだが。
だからPythonとか大好きだし、もし自分が言語を決める立場になったら、Pythonで出来ることは全部慣れてるPythonでやると思う
Haskell
import System.Environment
makeList cs f = take (length cs `div` 2) [cs!!x | x <- [0..], f x]
zipArgs args = zip evenList oddList
where
evenList = makeList args even
oddList = makeList args odd
main = getArgs >>= print.zipArgs
Ruby
evenarry,oddarry = [],[]
ARGV.each_with_index{|line, i|
evenarry.push line if i.even?
oddarry.push line if i.odd?
}
evenarry.zip(oddarry){|x,y| print [x,y] } if evenarry.size < oddarry.size
oddarry.zip(evenarry){|y,x| print [x,y] } if evenarry.size >= oddarry.size
puts
Python
import sys
evenList = [arg for i, arg in zip(range(len(sys.argv[1:])),sys.argv[1:]) if i % 2 == 0]
oddList = [arg for i, arg in zip(range(len(sys.argv[1:])),sys.argv[1:]) if i % 2 == 1]
for (x,y) in zip(evenList,oddList):
____print((x,y), end = '')
print()
例えばRubyで
ARGV.each_slice(2){ |e| print e }; puts
と書くのと何が違うの？
あんたみたいな精通してる人のがずっと良いコード書けると思う。
ただ、オブジェクト指向も結局、宣言的プログラミングが理想の形なのは確か。
数学好きならJulia使ってみようぜ。今年1.0出る予定だそうだ。
クソが！！
コマンド引数が奇数の時にエラー出るじゃねーか！！！！
ちゃんとテストしやがれ！！！！！！
ここで興味持って見て見たけど、文法がHaskellよりごちゃごちゃしてるんよ。。。
やっぱおいらはHaskellが好きやねん。
別に数学好きってわけでもないけど、もちろんJuliaは使えるよ
最新の文法を全部追ってはいないから最新のをちゃんと使える自信はないが
そりゃHaskellやLispと比べりゃどんな言語もごちゃごちゃしてるわ。
Juliaが狙撃対象にしてるのはRやPython（つーかNumpy）だから、Haskellはそもそも意識してないはず。
おまいさんに八つ当たりしてもしょうがないんだが、個人的にHaskellは二項演算子のググラビリティが死ぬほど低いのが困る。
学習コストが低い
そこが高学歴ｗの人に好かれるとは思わなかったけど
俺がPython好きなのは簡素だからではないけど、たしかに物理や数学の勉強で忙しくって、あんまり難しい言語は流行らないなあ
昔はpascal風のが多かったけど
自分で書いたコードはどうやって検索してるんだ
もしかして全部オープンソースにしてからぐぐるのか
Haskell
http://ideone.com/affD4l
なぜHoogleを使わないんだ？
あと今のGoogleは記号検索も対応しているぞ。
普通に言ってきたら馬鹿だとしか思えなくなるわｗ
Go
http://ideone.com/Uv5UOC
すまん。
ググラビリティって何だ？
って調べたらググり易さ？
そんなに記号多かったっけ。。。
モナドとファンクタ以外は普通の言語にもある記号だろ？
本一冊持ってれば十分だし、Hoogle有るから。
それ言ったら2引数の関数全て二項演算子になるし、二項演算子も全て2引数の関数になる。
かえって(*)とかのセクション(2引数の関数)としてググれば見つかりやすいかもな。
プログラミングが本分じゃ無い人にとっては言語学習はコストだわな。
オブジェクト指向にどのくらい純粋かとか、そんなのどーでも良いんだろう。
おいらは言語オタだから純粋さにこだわって行き着いたのがHaskellだったが。
そのHaskellも実装が関数型言語ならこんな最適化が出来るって本に書いてたことをあんまり実現出来てない、理想から程遠い実装なんだが。
そんなん言ってる奴おる？
検索は万能じゃないというかむしろ無能である
Googleは開発言語に関しては保守的
社内で関数型言語使うの禁止されてるし
次スレからHaskellはスレタイに復帰ですね
永遠の次世代言語として
Haskellは、サーバサイド・ソフトウェアを構築する際の“秘密兵器に最も相応しい”とCarl Baatz氏(Better社の共同設立者)は述べている。
https://www.infoq.com/jp/news/2016/08/haskell-production-retrospective
サーバーサイドで実行するソフトウェアの構築を行う場合は、Haskellは今日探し得る中で最も秘密兵器に近いと言っていいかもしれません。
http://postd.cc/haskell-in-a-startup/
採用したchatw○rksは運気が下がり
Kotlinにすら負けた
Scalaよ、どうしてこうなった？
コードリーディングしてるとき、例えば<$>とか<*>とかが出てきて、さてこの二項演算子の意味はなんだ？って調べたいとする。
Googleの検索窓に突っ込む。記号しかないので検索結果がまともに出てこない。
Hoogleはしらんかったな。
真っ先に紹介されるぞ->Hoogle
しかし撤退しただけというのを秘密にするための兵器が必要だった
<$>とかはGoogleで検索できるよ
現状では、その記事にあるStackの守備範囲はそう大きくない。
誇張しすぎだろう。
記号が多すぎたな。
あと簡単に暗黙型変換ができるのはやりすぎだった。
F#にも機能としてはあるが、幸運にもあまり使われていないように思う。
数学より工学よりだよね。配列扱うには便利。
今年中に1.0になるかな？
毎回のパッケージのコンパイルが不要にならないものか。
そう言えば、おいらは数学が好きと言ってもHaskell切ｂﾁ掛けに好きにｂﾈっただけだし＝A数学で何か解瑞ﾍしたいわけじｂ癘ｳいんよ。
どっちかっつーと、数そのものの研究？みたいな事は趣味でしてる。
チャーチ数に符号付けてチャーチ数版整数作ったり、少数作ろうとしてチャーチ数って無限進数なんだと気付いて、まず10進数から作らなきゃとか。
くらいの数学観だろどうせ。
Haskellを切っ掛けに数学好きになったんだから、大した数学知識は無いよ。
http://i.imgur.com/Dk9bC75.png
口頭で使ってるやつに早く終われとか言ってた…
になぜか入ってるという。たぶんこれが一番安い入手方法かと。
脇道的話題にレスして済まないのだが正直感謝だ。
エイプリルフールか夢かと思ったがマジだった。数万円が無料って… 意味がわからねえ。
ホームエディションはアカデミックと同じくらいじゃなかったか？
Wolfram Alpha なら無料だし。
時代遅れもいいとこ
言語試したいだけでハード買えって。。。
興味はあるよ。
手続きも書けるのがちょっと引っかかるけど。
純粋じゃ無いんかいって思うけど。
本読んだ限りじゃ悪い印象はそんな無かった。
Haskellみたいな汎用性無いのと導入のハードル(値段だったりハード購入だったり)がね。。。
お前は次世代にふさわしくないね
試したいならお試し版使えばいいだろ。
買ってまで触りたいものじゃなし。
ノートじゃ無いから場所固定されるじゃん。
手軽じゃないなぁと。
せやね。
試すだけならそれで良いか。
ちびるような使い方出来る数学知識は無いし。
ショボいコードしか書けないゴミhaskellerモドキはこんなもんだよ
最初はそう言うワードに惹かれた。
でも今はシンプルな仕様と言うか仕組みが好き。
少ない知識で書いて行けるのが。
そう言う意味じゃCも好きだけどね。
そのショボいコードすら出てこない次世代言語は言語オタに支持されてるだけで、言語オタは実際に役立つコード書いてないんじゃ無い？
少なくとも、おいらのは最終的にはテキストで探したい文の大まかな文脈は表示出来る、文献を参照するのに便利なコマンドになる予定だよ。>>492
俺ずっとMaximaで済ませてたからあれだが。
数学が好きなら、数学を処理する言語使ったほうがいいのは俺も同意する。
ちなみにRaspPi のはZeroでも使えるはず
流石にこれぐらいなら出せるだろ
次世代言語のここが良いあれがダメって言うだけでコード出さない言語オタは貶したけど。
まあ、おいらもHaskellに出会う前はRubyで"Hello World!!".length.displayとかやるだけで満足してたりする言語オタだったから、人の事言えないんだけどね。
何でもいいから一個の言語を使いこなせるようにまずならないと。
うん。お前が言うなだけど。
お前の事じゃない
自己主張強い自覚あるなら控えとけ
すまぬ。
しばらくROMるわ。
"Pharo Smalltalk"
| queue array ans msToRun sorted |
queue := SharedQueue new.
array := (1 to: 1e3) asArray shuffled.
ans := OrderedCollection new.
(1 to: 100) detect: [:m |
msToRun := [array do: [:n | [(n * m) milliSeconds asDelay wait. queue nextPut: n] fork].
sorted := (queue next: array size) isSorted] timeToRun asMilliSeconds.
(ans add: {#m->m. #msToRun->msToRun. #sorted->sorted}) last value.
] ifNone: [].
^ans asArray
"=> {
{#m->1. #msToRun->1003. #sorted->false}.
{#m->2. #msToRun->2004. #sorted->false}.
{#m->3. #msToRun->3004. #sorted->false}.
{#m->4. #msToRun->4016. #sorted->true}}
"
http://ws.stfx.eu/8W36PYP2PQ1G
最低でもフィボナッチはやらないとな。
Python3
http://ideone.com/9um4ku
Java 9
間違ってもScalaには手を出すなよ
Go(笑)だな
VB以下の低脳言語よ
ペチプァ土方に次などない
糞ゴミ連想配列のドブに沈むか首吊って死ね
トレイトあるんやぞ
Scalaの優れたヤツじゃなくSmalltalk式の劣った方だが
WEBならKotlinよりScalaじゃない？
scalaのほうってトレイトと呼んでるけど、実態はmixinじゃないの？
そっちの方が優れてるの？
１０万程度でpc組め
よくあんな汚物吐瀉物糞尿下痢で踊り狂えるな
狂気の沙汰だわホンマ
スレが臭くなるから近寄るなよ疫病神
早く死ね
趣味で言語作りました。試しに作っただけなので複雑な事は出来ません
こんな言語をシンプルだから分かりやすいよ！ってGoogleの知名度使ってゴリ押ししてるだけ
forだと無駄な行が多すぎてパッと見て何をしているのか分からない
コメント書かなくても読めるのが良いソースだろ？
複雑なことっつーか抽象度の高いことが出来ないな。汎用ライブラリ書こうとするとinterface地獄になって悪夢見る。
でも不思議なことに手なりで動くもん量産するのにはものすごく向いてる。
マクロがないかわりにgo generateとかいうクソキモい（誉め言葉）機能があることと、
あとはPHPみたいな言語未満の何かで物書いた時のような負債に陥る危険性が、言語としての幅が狭いお陰である程度緩和されてるってのが案外バランス取れてるのよな。
汎用ライブラリ書くのには全然向かないけどね。
周辺ツールの異常な拡充もごり押し戦略の一環だろうしな。
あくまでドカタ言語。
いや、ワンライナーで無理やり書いたソースのが読みにくいよ。
てかそこまで行数使う複雑なコードなら関数で切り出せ。
そういうのは使ってる言語の問題じゃなくて書いてる奴の問題だから。
でもペチプァ〜のあなたは、テンプレートにSQLのfor string連結書いちゃうんでしょう？
死ね？
関数として切り出す時にループの中で行うことだけ書けばいいのがmapないとループそのものを行うサブルーチンもかかなくちゃいけなくなるじゃん
map不要とか言う奴絶対Lispすら触ったことないハイパーエアプマンだろ
汎用ライブラリ書けないっていうのはかなり大問題だと思うんだが
ジェネリクスないのが原因でコレクションとかは特別扱いしないといけない
Setとか普通に使えないのは不便すぎるし、SortedSetとか追加しようと思ったらそれも言語で特別扱いするのかってなる
型ごとにコード書くのか？コピペは最も基本的なアンチパターンだよね？それをGoogleは推奨してるのか？
>>618
周辺ツールをこれだけ作ったのに言語がこれじゃもったいない
もう少し機能入れていれば間違えなくもっと流行ってた
ジェネリクスについてはさすがにいれようぜって議論はあるな。
今はそういうのをコピペなしに書くならinterface地獄で、自分もそこは嫌いなとこだ
ちなみにgoの汎用sorted setくらいならgithubに既にある上にめっちゃコード短いから、見てみるのも面白いかもしれんね。
でも書くし、読むけど。
昔何かのJavaの本でJavaでも宣言的に書くべきだ。みたいな事が書いてあって、メソッドチェーンされたインスタンスが二行でちょっとした処理してた。
最近C#6実践入門とか言うの買ったけど、それに載ってるコードもifは出るけどforがほとんど無い宣言的なコードだった。
C#6の新機能紹介はほとんどオマケで、タイトル詐欺だけど。
いあ。。。詐欺じゃ無いけど、紹介された新機能が全然頭に入って来ない位、(ドロドロの)実務的な内容。。。
なお日本のドカタ現場はJava6をつかっていればましな方なのは内緒な。
ドカタ現場から見ればObj-Cすら次世代言語ってな。
手続きが透けて見える
見えない奴はエアプ
まあ透けて見えるのはその通りなんだが、逆に聞くが手続き型が透けてたらいかんのか？
機能としてPythonの内包になんか欠けてるのか？
内包表記、map, reduce 使えるとだいぶ偉いプログラマーになった気分なのかね。。
別にあれば使うけれど、それで読みやすさが格段にあがるなんてことはないわ。
まさに枝葉としか言いようがない。
てかなんでこんなに php 嫌われてるのか使ったことないからわからんのだが。
perl には相当神経やられたってのは個人的にはあるけれど、
php ってそんな嫌なもんなんかね。
内部動作が実際はどうなってるか気にしなくて良い。
記述上は単純に一行になる。
書きかたによるけど、関数より意味が通じやすいかも。
リストの長さ求める関数length
再帰
length [] = 0
length (_:xs) = 1 + length xs
再帰はスタック消費するので末尾再帰
length cs = length' 0 cs
......................where
..……...................length' n [] = n
..……...................length' n (_:xs) = length (n + 1) xs
末尾再帰を一般化したfoldlで置き換え
length = foldl 0
リスト内包表記
length xs = sum [1 | _ <- xs]
過程を知ってればfoldlも意味分かるけど、リスト内包表記はHaskeller以外にも分かりやすいかも。
端折り過ぎた。
length = foldl (/x _ -> x +1) 0
単純にカテゴライズして蔑視したいだけだと思う。
そういうのを除いてPHPが嫌われるのは言語仕様が綺麗とか
汚いとかそういうのではなく、互換性とか環境問題で
無駄なエネルギー使うからだと思ってる。
同じような理由で俺はrubyとかはもう手を出したくないと
思うし。俺が好んで使ってたのは256倍本とか出てた頃で
パッケージやら何やらで随分と改善されてるのは
知ってるけどトラウマなんだよな。
このレス痛々しくて面白いな
パソコンの大先生なら孤高の言語でオナニーしてくれりゃいいけど。
次世代ってのは、未来の現世代なんだから。
夢ばっか見ても意味ない。
という楽観を華麗にぶち壊すRustとかいうクソ言語
どゆこと？
どんな優秀な人材でもまともに物がつくれない破綻した言語ってこと。
forという単語を見ると手続きが透けて見えるほうがよほど手続き型に脳が汚染されてるだろ。
述語論理の for all は手続きか？
自分がかけたら使う、それじゃそいつがやめたら困るわ。
ある程度は浸透してくれたものでないと困る。
知らんがな。人材に逃げられないようにせいぜい厚遇するんだな
どういう事？
逃げる訳じゃなくて辞めるんだよ。定年とか、寿あるじゃん。それは仕方ないよ。
教育コストとその言語から得られるメリットのバランス次第じゃないのかな。
新しい人入れるときの問題で、その時に誰でも知ってる言語で地頭があって、そこに自社の資産とか話すのは簡単だし、教育に出しやすいじゃん。自社でもやるし。
書けるから雇うことも無ければ、雇ったからそいつの思うように書かせるわけでも無いんじゃないの？
Javaで書いたってろくにメンテできないだろうよ。
C、C++、C#、Java、Ruby、Python、Scala、Haskellくらいかけろって話だけどね
チームに組み込まれた新人はそのチームで先輩が使ってる言語と技術はどっちみち勉強するだろ
それすらできん屑新人しかこない企業に勤めてるんなら学校で教えてる言語しか使えなくなるなｗｗｗ
ということにしたいだけにしか見えないんだけど
とりあえず動くようにメンテするのと、思想含めて正しくメンテするのはちと違うでしょ。
>>649
Cだけわかるとエグいコードになりがちだしね。Cと最近のC#で充分。JavaScript一本でも良いくらい。
>>651
新人じゃなくても研修とかセミナー行くでしょ。
新人しか行かないなら、どんどん化石化するか社員の自費の自己研鑽に頼るしかないじゃん。
会社のために技術を使うなら、その技術は会社が伸ばして当然かと。。
問題は「自分がその言語で書けるか」ではなく
「他人がその言語で書いたコードを保守できるか」なのでは?
自分が新規コードを書く分には自分が知っている範囲で書けば済むが、
他人のコードを保守するには文法とライブラリを網羅的に知っている必要がある。
C、C#、Java、Ruby、Pythonぐらいは保守できるべき、ぐらいならわかる。
でもC++、Scala、Haskellは文法とライブラリの知識を相当要求する。
C++は普及しているからいいけどScalaとHaskellは保守できる人を雇えるか分からない。
好き好んでScalaやHaskellを選ぶ人は初心者には読めないコードを書くだろうしね。
>>537のエラー出ない版をたまたまRuby初心者スレッドで教えてもらえた。
ARGV.each_slice(2).take_while{|e| e.size == 2}.each{|a| print a}
puts
んで、これを元にHaskellでも書いてみた。
import System.Environment
slice2 [] = []
slice2 [_] = []
slice2 (x:y:zs) = (x,y):slice2 zs
main = getArgs >>= print.slice2
>>654
保守するやつが初心者？
得意じゃないとしても、Haskellは入門書とHoogleあれば十分だよ。
技術は会社が伸ばすから勝手な技術は使うなってことか
すごい文化だな。とてもリーディングカンパニーの考え方とは思えない
大方人から指定されたものを作るだけの創造性のない事業分野なんだろうな
未知だから学習コスト0だがなぜか読める
それらを全部書けても何も作れない腐った言語がRustなんやで
社内開発用言語縛って生産性維持しながら会社全体で技術叩き上げてるGoogleさんのdisおっつおっつ
Googleはプロトタイピングの言語は完全に自由やで
趣味コーディングの時間も保証されてるし
プロトタイプのコードはメンテしないだろ。そりゃ好きな言語で書けばいいさ。
メンテするプロダクトコードはあのGoogleですら言語ガチガチに縛ってそのなかで技術上げてるのに（最近だとGrumpyとかな）、
出来る人材ならどんな言語でもすぐ習得して既存コードメンテ出来るようになるっていうのは幻想。
ある程度ならいけるが限度はある。
C++が許されてRustが許されてない辺り、GoogleはRustが使い物にならんとわかっていらっしゃる
「だってこれボクが好きな言語じゃないもん」
とか言って仕事投げ出すのか。
ゆとった会社だな。
個人で伸ばせばそりゃ素晴らしい事だよ。
勝手な技術使うな、は当たり前では？
簡単なことで、単に社内に布教するだけだよ。
それだけで勝手な技術じゃなくなるんだから。
金貰って作ってる以上、指定されたと言うより要件定義から離れる事は良い方向でも悪い方向でも等しく害悪。
それを使うよう、要件定義を見直しゃいいじゃん？
TypeScriptが承認されるまで延々レビューを繰り返して2年かかったという話を読んで、
Googleといえども典型的な大企業病からは逃れられなかったんだなと思った
好きな言語が使いたきゃ、ホント通せば良いだけじゃん。
各段落最後に同意。そこが重要
その通りだよ。通すんだよ当然だろ
そこを門前払いして「浸透してない言語はダメー」とか、ゆとりすぎ。
上層部の中ににMSのはなんだろうが採用させないのがいる（・いた？）だけのような気がする
それだけならkotlin, scala, ruby, php, perlあたりはとっくに承認されてるだろ
「それお前の好みの問題だよね?」と言われないような理由を示す必要があるんだと思うよ
というのはともかくなんだかんだ追加承認のフローが整備されてるのは日本企業では考えられんよな。
仕事を通して広めるってのがわからんな。
別にプレゼン力次第じゃないの？
あとは、小物を同時に作って見せればいいと思う。
研究開発費くらいあるだろ。
>>676
追加承認なんてどこでもやってるだろ…。
別様式の帳票(物理)をスタンプリレーするみたいなオマケもついとる。
perlはともかく、phpはGAEでも動くし、嫌悪感と実利のちょうど真ん中程度の立ち位置じゃないの？
所詮道具なんだから、作るものに合わせて相応しい言語選ぶだろ。
既に職場で広く浸透した言語に限定するのなら、全く「次世代」の話じゃないな。
スレ違い。
次世代言語だから、その職場には浸透させるんだろ。
世間としてその存在やら概念が浸透していないのとはまた違う。
取り違えるなよ。バカバカしいのはお前だよ。
>>681
すまんな。ここまで読解力無いやつ想定してなかったわ。
「わが社で次に採用するべき言語はなんだ？」って会議するのとの違いじゃね？
自分は前者のつもりで駄弁ってたけど、後者のつもりのやつがスレに紛れ込んでるだけな気がするわ
我が社というより、皆が次に使うべき言語は何なんだろう、何故適しているんだろうって言う話かなと。
そうなると、前者も後者もあんまり変わらない話に聞こえる。
ドカタにそんなもんはないんだなこれが。
永遠にJava4より新しい言語使えねえんだぜ。
前者と後者が変わらんのはベンチャーもしくは顔本林檎みたいな超最先端企業くらいだぞ。
今使ってる言語を変えたい経営者なんていない。たとえそれがサポート切れたJavaでもVB6でもCOBOLでも。
全員が分からないからとか何とか
繰り返すけどさ、採用言語は趣味だよ
変なのに噛みつかれないように厳密に書くと、社内で布教して一定の承認を得るのは当然の手続きであり、そこまで努力しなくてもそれが可能な企業orアカデミックは普通に存在する
そしてそもそもそれが出来ないような可能性を考慮しないといけないような奴が来るべきスレではない
つまり
Javaか…。まあ、環境変えるなのお達しがある案件だとどーしようもないのもわかる。
>>688
わかりにくいなら、わかりにくかったと言えよ。
誤解してドヤ顔で反論してからのそれは流石に言訳だろ。
また誤爆した。
つまりこのスレにいるドカタは俺くらいで他はみんなイケイケベンチャー社員か世界の大企業社員様くらいなのね。納得。
存在がスレチだったようですまんね。
今回は暫く意思疎通出来てないことに気づかなかったからな。具体的には>>666でやっと気づいたわ
だから意味分からなかった旨を>>670で伝えただろう？
これもまだ意味を汲めていないなら分からんけど
とりあえずエンジニアガイジは自分の主張を三行にまとめてみたら？
俺もよく分からんし
いや存在がスレチとまでは言わんけど……
でも自分が絶対使えない言語の議論してなんか意味あるかなーとは思うぞ
プロトタイピングの話ししてるんなら使えるから有効だと思うから、プロトタイピングの話ししにきてるんならスレチじゃないと思う
なるほど。確かに。言ってるな。ごめん。
>>698
3行にまとめれば、理解できないやつに文句を言われ、
一つずつ演繹的に書けば、過去レスまで遡る気かと言われ、
長文で話すとこう言われ。
それぞれの方法で理解できてる人間もいる中で「僕に理解できる方法で話して！」って子供みたいなこと言われてもどーしようもなかろう。
本人だけはいつまでも他人が悪いと思ってる
これが、放置され続けて来た子の末路です
COBOL, VB6, Java 1.4の中からどれが次世代言語にふさわしいか議論しましょう
んー。本当に言いたいことだけを抽出できてない気がする
それと自分の立場を明示できていないせいで誤解されてるのかも
最初に自分の立場を明確にした上で、レスごとに大事な部分を強調するようにしてみたら？
それ具体的にどこの会社？
1.4ってジェネリクスないよな？
PHPでさえ何か（まともではない）はとりあえずできるのだから
その理屈はおかしい
まぁ抜ける時に丁度バージョンアップどうするって話はしてたな
7は新しすぎるから6で、みたいだった記憶
Rustをわかってないな。あれはなんたらチェッカーが強すぎてHelloWorld以上のことをしようとするとコンパイルが通らずにそもそもプログラムにならんのさ。
PHPはとりあえずゴミやカスを生産はできる。でもRustからは何も生まれない。ゴミやカスが生まれないって意味ではよい言語かもな。製品も生まれんが。
なるほど。マジでありがとう。
いろんな話に首突っ込んでるし余計にか。
会社では、とか、個人的には、とか枕つけるのと、うざいって言われるかもしらんが少々冗長でもパラグラフ末に結論書くとか、工夫するわ。
まあ、若い人が存在を知ってるかはわからんが、イライラ棒に近いわな。
CのプロジェクトでMISRA-Cの推奨も網羅すること！でリンタ定義が配られて来たときくらいのめんどくささ。
社内用のgccのtemplate系のエラー解析ライブラリをRustで書いてみんなで使ってる
こう言う処理をこう書けるのがクール！！とか有ったんだよね？
イライラ棒にはちゃんとゴールあるじゃん。
Rustにゴール（コンパイルが通ってかつ望むロジックが実現できるコード）はない。
RAMメーカーのCFDに喧嘩売ってる？
ギターの弦のことかと思った
完成品はいろいろ実在してるんだけどｗ
チェッカーの壁を乗り越えられなかっただけじゃん
チェッカー内で作れるもの作ってるだけじゃん。
PHPでもまともなものは作れるっていう戯言と何ら情報量変わらん。
小物作る分にはゴールはあるよ。
イライラ棒の棒と同じで、全く何にも触れていない棒がゴールで手に入るだけ。
ホントに触れないことが必要なのかはおいといて。
チェッカー内で作れる物作ってるだけ、ってなんだそりゃw
作ってはいけないものが作れなくなってるだけで、もともとそう言うコードは書くべきでないし、
そんな事言うと誰もがチェッカー内で作れるもの作ってるだけなんじゃねえの？
元からあったしね。推奨ですらハネてビルドかけてもらえないプロジェクトとか。
単に技術か経験どちらか、または両方足りないだけでは？
浸透してないようなものは次世代言語じゃないとか言い出すような
一貫性の欠片もない人が紛れ込んでいるとスレの流れが速くなるなw
あの主張読んだらやっぱり普通はそう解釈するよな
有名どころだとグラフ構造。あと木構造も結構辛い。
書けなくはないがチェッカー通そうと思ったらbox rc rcref祭とか色々あったり、イテレータの肩だけで一行の長さぶっちぎったり、無名関数引き回すとぶっ壊れたり、
とにかく存在が破綻してんの。
そうそうこれこれ。俺たちは物を作りたいんであってチェッカーと腕相撲したいんじゃないって話。
Rustは生産性と書けるプログラムの幅が既存の言語よりはるかに低いっていう破綻があるわけよ。
開発効率なんて定義不能じゃ
明確に定義できないから比較できないってんなら
アセンブラ使えで話は終わるわ。
極論だして論破した気になってる奴wwww
説明してもまだ誤解してるのか。
浸透する場が違うじゃん。
腕相撲なんかせんと、まともに考えれば良いだけじゃん？
今までいかに、問題を腕力でねじ伏せてたかよくわかる発言だな。
コンパイル時だと全てのチェックを通り抜ける解が存在するのかという疑問がある
純粋関数型なHaskellで2リストキューを使った素朴な方法だとしんどいし、所有権とメモリ管理が厳格なRustだとADTで書き下すグラフや木はめんどい
どっちもライブラリは既にあるんで、破綻してると声高に連呼するなんて馬鹿じゃないとできないよ
>>715だけど再帰下降パーサで作ったから普通にグラフ構造でできてるよ
コンパイルエラーが嫌いなのかな？C++でもテンプレートとか嫌いそうな感じがする
既に解かれた問題だけを選べば破綻しないのも自明
コンパイルがちゃんと通るグラフ構造の実装をplay.rust-lang.orgに上げてもらって
>>747はそれを他言語と同じくらい簡潔に書けるというライブラリで
書き直したのを見せてくれまいか？
大多数がそう思うような文を書いてしまったという事実をしっかり受け入れて反省するんやで
反省はするが、こういう、特に意見がない限り発言しない、自分がノイジーマイノリティなのかどうかわからん場で、大多数は使うべきじゃないよ。
1/1Mの確率で発生する実行時バグの再現とかうんざりなんだけどｗ
rustってそういう方向で発展した感じはする
一般のソフトウェア開発に適用しようというのが間違いあり
とヒトコト言い返されたのか。
grumpy
プログラミング言語でさえ悪貨は良貨を駆逐する状態だからな
例えばPHP
それがkotlinくらいまともな言語で、ググールがバックで突き上げてくるとなると・・・・・・・
単純な興味だけど、どっちの何がほしいんだろ？
あとはネイティブにも同様の思想の言語の決定版ができれば完成なんだが
Rust使うほどの速度は求めてないけど、Goはリスト操作関数とかジェネリクスとかなくて辛いって時に使える丁度良いネイティブ言語欲しいよね
新しい言語を触るたびにまず自分専用のリストをコーディングするところから始まるなら既に資産のあるCかFortranでいいわｗ
ジェネリクスがないから自作出来ない
最近マルチコアやらHTやらでベンチ結果がC#と逆転することもあるとか聞いたけど
dotnet自体とネイティブでの話だっけ？
ネイティブとマネージドでマネージドのほうが早いわけねーやろ
理屈で考えてそんなことあるわけねーだろ…
何もかかってないたこ焼きと、すでにソースとマヨがかかってるたこ焼きに何かを足して
どっちが美味しくなるポテンシャルありますかみたいなことだぞ
なんもかかってないほうがポテンシャルあるに決まってんだろ
ソースとマヨがかかってるたこ焼きが圧倒的差で勝つ
C(++)とかよりマルチスレッドを楽に実装出来るC#とかならC++だと面倒でスレッド使う気無くすような所でも使えるから同じ労力なら速くなる(かもしれない)
うまくヒットすれば凄く速くなるけど下手すると効率悪い、メモリ喰う、処理も増えるの三重苦
その名もP
JIT+実行時最適化でJIT VMのほうが速くなることはある。
でも、ソースとマヨネーズかけたほうが旨いよ。
有るか無いかわからないからベクトル演算命令使わないバイナリと、JITが使うように、使えないように、どちらでもなく展開できるように書いてある中間バイナリなら中間バイナリのほうがいいと思う。
長期間使うから次世代言語で作ろうと思ったけど
このスレ読んでたらどの言語選んだらいいのか判らなくなったから
RabbitMQ建ててとりあえずpythonで実装して連携させてみた
少しずつ次世代言語に置き換えていこうと思ったけと
常用するシステムって一度動いちゃうと
他の言語で再実装する気が無くなってくるね・・・
まずはerlang勉強してみる
あえて遠回りしたいなら止めないけど
ええことないで
好きなの作ればいい
世間の技術者はもっと柔軟だよ
確かにそれは正しい
勉強自体が目的ならElixirをやらずにErlangをやるのもありかも
C++
>Rust使うほどの速度は求めてないけど
つまりGCがあってメモリ安全って事な
高機能なライブラリ群
ん？
OCamlでいいんじゃない
node.js+typescript
エリクサーが古いオワコンはねーわ
エリ草ｗなんてそもそも話題にすらならん
始まる前から終わってたレベル
と一度はいってみたい
なんかすごそうだろ
仮に終わっても魔術によって復活する
誰がうまいこと言えと
えっ どの辺がうまいの？
GoとRustはC10Kにはどういうアプローチで解決してるんでしょうか
haskellで軽量スレッドの便利さ知ったわ、有名なのはErlangだろうけど
"V"="1.3335412","0","1","3Q",
チューリング完全を扱うスレじゃないんだし
かけるけど面倒だけど、他には無いメリットがある、ならアリだと思うが。
Rustはもちろん面倒だが、チェッカが正しいから面倒だし、
Goの if err != nilも、何回書くんだこれってなりがちだけど、シンプルさといろんな意味での長距離のジャンプをさせないがために面倒だし。
ただただひたすら面倒な物とは多少違うかと。
世の中にはチューリング完全でない、と言うことに意味のあるものもあるしね。
DSLだけど帳票出力言語とか書いたことあって、敢えてチューリング完全にならない様に書いた事ある。
事実それ以前の帳票出力言語で闇ばっかり生まれてたのが綺麗に抹殺されて、
見かけの工数は2割くらい増えてるけどトータルの工数で統計取ったら8割減という驚きの結果が出た。
それを言ったらアセンブラで何でも書けるよ。
安全さのために面倒になってしまう進化もありということね？ 確かにCは面倒な上に危険だもんね
後半の話はよくわからん。それ関係なくない？
>>813
賛成ということね？
って問題意識があるような
rustはチェッカーでエラー出してはねとばし（だから警告じゃダメ）
Goは言語仕様小さくしまくって
でも目的は同じみたいな
言語自体の優劣をどうやって決めるのか
次世代って言うのは単に次に流行る言語って意味だ
多くの人が使い次の世代を担っていく言語だ
なになにの機能がないから次世代じゃないとか本末転倒
見かけだけの生産性が高い言語が流行ったとしてそれが社会の求めるものだったら
そういうことだ
それが理解できないようでは次世代もくそもない
Kotlinなんかで、この中にDSLを内包しよう、という動きもあるが、あれには完全に賛成とは言わんと言う意味と、
○○の○○を書くときにめんどくさい、と言う反論への、○○を書くべく好きに言語選んだり作れと言う予め言っときたい反論。
そういう言語ってプロトタイピングに使える訳じゃないから本番用だろうし、本番の言語を決定出来る立場の人なんだろうか？
o 安全を犠牲に横着が許されない
崇めろ
ねえ神様その訂正って本当に正しいのですか？
横着が許されるような言語とはPHP以外にどのような言語があるのでしょう？
J2EE や J2SE だったら良かったのにね〜
> 横着が許されるような言語とはPHP以外にどのような言語があるのでしょう？
C++とか
可変な再帰的データ構造が書けないチェッカーの何が正しいって？
ああ、そういうのを指して横着と言うのか。なるほどありがとう
仕事なら商品として売りものを作る用？それともプロトタイピング用？
俺はプロトタイピング+趣味なんだけど
理論上可能だとしても現実的には大体無理
お前は動的言語なら型を全く気にしないのか？
Rustはともかくただの静的言語でScalaの型ダルイっていうのはおかしいと思う
Haskellは触った事ないから知らん
プロトタイプならって言ってるだろ……
プロダクションならScalaは良い候補。Haskellは性能で選外。Rustは欠陥なので選外
プロトタイプでも動的は駄目だわ
書かないだけで型を意識するのは変わらないし
プロトタイピングとか自分用の道具でもある程度規模が大きくなって来ると型のサポートが欲しくなって来てな
コトィンがランゲージオブネクストザジェネレーションの地位を確立したのは疑いようのないトゥルス
0 == "0"がtrueかfalseかなんて疑問が毎秒1000ビリオンダラーの損失を叩き出すPHPが
なぜか世界最大級の地位を確立したように
おまいらは低きに、そして大流に流されるだけの哀れな落ち葉でしかないんだよ
いつか腐葉土になる日もくるかもしれないが、まぁね
コピペして使わせてもらうわ
俺はいつも君のそばに。
これが次世代言語を操るプログラマか…
おまえのその才能はプログラムでは活かせない
まあ、言ってみたかっただけなんだろうけど。
そんなもん使う人増えれば最適化進むんだし
次回を期待して待っている
マイナーなだけでなく実体もクソオブザクソなのでHaskellより先にスレタイから外すべきだった。
ネットの情報だけを元に叩く事しかしない引きこもりばかり
横着にもかける言語で、横着が許されない類のプロジェクトに関わった事がある人では？俺もそうだし。
次世代という意味で期待してるってのもいろんな面があって、
とにかく楽な言語、とにかく早い言語、とにかくメモリー使わない言語、とにかく安全な言語と求めるものが違うところに、
これこそ至高！と全部中途半端なRubyとHaskell出てくるからめっちゃくちゃウザい。
>>824
再帰的な構造はかけるでしょ。
再帰的なデータ型も書ける。
だめなのは、多相の組み合わせが爆発するか循環してしまうもので、当たり前だがHaskellみたいに実行時に多相性を解決してるんじゃなくて、コンパイル時に解決されるからで、そのコンパイル時の解決を行うときに死ぬから。
コンパイル時解決は、というモットーというかテーゼなので、仕方ない。
し、そもそも、そんなものを作るべきではないというのが公式の見解かと。
コンパイル時に多相を解決する言語ならだいたい同じ。
色んなスレに「僕には理解できなかったし、すごいプロダクトも見つからなかったからこれはゴミ！」って書いてる奴なんだな。
Ruby、Haskellが至高！って言ってるレスどれ？
最近ないと思うけど
>当たり前だがHaskellみたいに実行時に多相性を解決してる
おいおい、Haskellの実装知ってんのか？
Haskellで実行時に型情報が必要な多相性はほんの一部だ。
ほとんどの場合、コンパイル時に解決される。
モジラのステマ部隊が色んなところでRustの押し売りしてるから訂正して回ってるだけ
こんな気持ち悪い行動をする様になるんだな
頭おかしい
まともに書けたっていうRustアプリのソースでもって出してくれりゃ退散するのにね。
Rust擁護勢の方がガイジレベル高いな
上位互換。
出たーステマ部隊の常套句！
そうほざくなら>>734->>735にこたえてからにしなよ工作員
おお、グイグイくるな。
最近言ってなきゃいいわけではないでそ。
>>854
知ってるよ。実行時に多相性を「しない」のならその主張もわかるが、「ほとんどの場合しない」は「してる」だよ。
「施錠確認した？」「ほとんどしました」って、要は全く施錠の確認できてないのと変わらんよね。
>>735
答えたような。それ。
それ例外の一般化っていう立派な詭弁だぞ
そもそも、まともに知りもせず想像でひたすら叩き合ってるだけ
それを建設的かのように振る舞うのがおかしい
実用的かもしれないけど次世代言語とは呼べない
あれ前世代実用言語だろ
大事なのは、ビジネスモデルを構築できるかという事。 言語はただのツール
知ってるから叩いてるんだよなあ。よくしらないとか想像で叩かないでほしい。
ステマに騙されてRustで無駄な時間を過ごす人が出ないようにしてる訳だから俺は建設的な話してる
C++の後継なんて誰も必要としてなくね
それはC++が至高だと仰ってる？
C++が使われてるって事はいるって事だろ
C++の後継はメモリ管理自由に出来てネイティブな事が最低条件だろ
過去の幻影に囚われていつまでも暴れまわる怪獣みたいなガイジ行為はやめろ
>>863二段落目についてはあまりに下手糞な理論展開のせいで真意が伝わっていないだけだと思うけど
例外を一般化してるわけではなくて、その例外を許さない事自体が言語仕様、言語設計なんでしょ。
お前が例外を例外と認識しているのに、敢えて混同してるんじゃん。
べつにrust推しでも何でもなく、割とまともになってんじゃんって感想にここまで吠えられてるのに。
詭弁だと言うなら言い負かせば良いのに。
無理そうになったら狂ったり、論理否定のための人格否定で誤魔化すのやめてよ。つまらん。
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
あと、その理屈ならHaskell擁護も一部のキチガイ除けばそんなに悪くないと書き込んでるだけなのに噛みつかれて困惑してるよ
読みにくいってまた主観的な意見だな。
何かダメなの？
こないだの、改行を適宜入れろって話のほうがはるかに役に立ってる。
後半。
Haskell自体が八方美人のブスみたいな印象で、実際問題その理念通りの使い物にはならんと言ってるだけで、Haskell使いは叩いてないぞ俺。
その話は知らんが俺は>>705だ。前は具体的に指摘した。毎回具体的に指摘してほしいってか？
俺は超注意深く読んだから今回のはなんとか理解できてるけど、実際今二人ほど勘違いしてるよね？俺も最初彼らと同じ勘違いをしたよ
これRust叩きの人も同じやん
Yes！
ここはアンチC++の巣くつ（わざと「すくつ」って書いたら予測変換出てきたｗ）
仮にfirefoxをちゃんとRustで書き直したら実用性はあると認めるの？
それとももっと基準は高い？
むしろそれ出来上がらなかったら本格的にヤバいじゃん
認める。
おれは破綻するんじゃないかと思ってる。
一番ウンコはSmalltalk！これは間違いない
醜い言語はJS
美しい言語はScala
簡単な言語はpython
難解な言語はHaskel
柔軟な言語はC++
魅力がない言語はC#
意思を感じる言語はObjC
かっこいい言語はElixer
雑な言語はGo
愛された言語はJava
幸運な言語はRuby
迷走してる言語はPHP
本当に書き直して成果を公開したら認めるわ。
うまくいかないにカシオミニ賭けてもいい。
空気な言語はRust
Rust使いはステマ部隊かステマ部隊に騙された不幸な人だからな。前者は叩いても後者は叩けんな。
Rust信者というかモジラとかいう世界中のソフトウェア会社の敵が狙ってるのがこれだろうなってことは感じてた。
クソ言語をステマ工作してソフトウェア会社に売り込んで、自分達の給料の確保に使う。クソモジラならやる。
ES6でかなりマシになったから(ｶﾞｸﾌﾞﾙ
なんとか理解できてるなら必要充分だってことでしょ。
まるで>>883以外は低能みたいに言ってはいかん。
そうでもないだろ。
半コテでなんでここまで叩かれにゃならんのだ。
誤解した人間が二人、誤解していた人間が一人、発言なく見えないどちらの状態かわからない人間が複数名。
これで有意差を出すなら、何人が母数なの？
自分の観測域で相手を評価するのは良くないと思うけど。
「自分と同じく誤解したが誤解が解けたか、誤解したままである」と周りを推定するのは、俺が相手は馬鹿ではないはずだと推定するのと同じでは無いのかと期待するのと同じレベルかと。
しかしまぁ、少なくとも議論スレならばもう少しマシな話がしたいし、不要な枕詞は使いたくないけど、まぁ通じないなら言い方をもうちょい気をつけるわ。
何の反論にもなっとらん
俺はHaskellに例外はないなんて言ってないしそもそも知らん
難癖もいいとこだな
SmallTalkが一番ウンコだと思った決め手は何？
では、具体的にGHCが実行時型情報を必要とするケースを挙げてみろよ。
言っておくが、パラメトリック多相は全てコンパイル時に解決されるし、
型クラスによるアドホック多相も、あれは関数オーバーロードの形式化だからな。
関数オーバーロードはコンパイル時に解決されるぞ。
さあ、具体的に挙げてみろよ。
「rustはコンパイル時に多相を解決する能力がないので、その能力のあるHaskell と違ってデータ構造が作りにくいのは仕方がない」
みたいな感じと思われる。難解だけど
あ、例外の一般化をしてる、ってのは「Haskellでは実行時にも多相の解決をする」ってのを「『Haskellでは多相の解決を実行時に必ずする』と一般化(というより誤解)してる」という意味ではないのか。なら的はずれな事言ってすまんな。
>>905
具体的に上げろと言われてもなぁ。
<T>を持ったenumがOptionかcar(T)とcdr(<T,T>)である時くらいかな。
>>906
そうそう。能力を敢えて持っていない、に近いけど。
実行時ゼロコストを目指してるから仕方ない。
>>906を主張を三行に纏めるお手本にしてくれてもいいぞｗ
エンジニアガイジは本気で伝え方の訓練した方がいい。
ID:uGw1TdWNみたいな有能な読み解き手がいつもおるとは限らんわ。
相手の反論を表面的にしか返さないせいだな。その質問がどういう疑問から出たかわかってない
「Haskellは実行時に型を解決する（からRustより型の表現力がある代わりにオーバーヘッドのトレードオフがある）」 って意見に
「Haskellもほとんどコンパイル時に解決できるわ」って反論が来たときに「ほとんどは全てじゃないだろ」なんてなにも伝わらん腐った返しするから伝わらないんだっての
「そのごく一部のおかげでそれが皆無のRustより型の表現力があるんだろ？」って、元の主張の（）の部分を伝えればまだ理解してもらえるだろうに。
つまり疑問に対する反論が下手。
それが出来てないから今はただ論破することしかできてない。
本当に「はい論破」したいだけなのか、かわいそうに論破スタイルしか議論の方法知らんのか俺には区別つかないからなぁ。
自分の意見の伝わらなさの自覚はありそうだから（現状人のせいにしてるが）後者にかけて長文投下した
本人に非があるわけではないが、治ることもない
確かに「相手の反論が何を疑問点として出てきたかを推察できずに表面的な論破をしたがる」っていうのは典型的なアレだが、
それだけで病気認定は俺にはできんな。健常者でも多少の訓練は必要な事柄だからな。
ただ可能なら診察は受けた方がいいかもわからんね。純粋な心配として。
一から百指摘しないと理解できません、って取ったらいいの？
>>912-913
全然論破もしてるつもりないけど。
反論はまともにしてほしいだけで。
論破スタイルってか、ストレートに言わないと議論にならんでしょ。
雑談所なら雑談するよ。
子供作るときに一通りそういう気質があるか調べてもらったが、幸いながらアスペではなかったぞ。
残念ながら多動はあった。
気持ち良い納得感を得られる良スレだな
一から百の全部を要求するやつは蹴り倒していいとは自分も思うが、一から百のうち任意のどこかを要求する人の相手くらいできんと人と議論は進まんぞ。
相手の疑問から一から百のうちどこの説明をするべきか読み取ろうという話
反論がまともに来ないのはこれまでの積み重ねのせいじゃないのか？
別に論破スタイルじゃなくてもストレートに議論はできるだろ。
通院済みか。余計なお世話だったようだ。
><T>を持ったenumがOptionかcar(T)とcdr(<T,T>)である時くらいかな。
コンパイル時に解決できないHaskellの多相の例がそれか？
おまえHaskell書いたことあるか？
シッタカで主張が支離滅裂になっているのを
多動のせいだと思ったおまえらが勝手に辻褄合わせをしてあげて
なんだか最初からそういう主張をしているかのように
本人もおまえらも思い込んでいるだけ。
別に多動のせいじゃないと俺は思うがなあ。多動ってそもそも議論できる出来ないに関係あったっけ？
単に意見の擦り合わせが絶望的に出来ないから知ったかと同じような議論破綻に突っ込む感じで、
ディベートを議論と勘違いしてるよくある感じのやつだと思ってる。
エンジニアガイジが「Haskellの型はほとんどコンパイル時解決だ」って言われたときに
やるべきだった反応は
「俺はこのパターンは実行時解決だと思ってたけど違ったか？」であって
「ほとんどは全部じゃねえよはい論破」じゃない。
こういうところが議論向いてないんだよな。
enum？
もしかしてHaskellとScala間違えてんの？
相手の意見は汲み取れと言われながら、自分の主張は汲み取る必要が無いように余すことなく全て話せと言われると、
それは違う思う。
>>929
いや、完全に記憶だよりだからその辺違うなら違うんだと思う。
optionじゃなくてnilだった気もする。
なんと言うか、凄いな。Haskellを否定するだけでここまでヒートアップするのは。
スレタイからも抜けたし、否定し放題だとは思うが。
否定されるのが嫌ならHaskellスレに引きこもってりゃ良いのに。
誰かがいってた放置されてきた子って的確な表現だな
どんな優しい人でもこれは放置する
このスレに集まってるだけだぞ
Haskell関係ない
＞相手の意見は汲み取れと言われながら、自分の主張は汲み取る必要が無いように余すことなく全て話せ
それをお互いにやるんだよ。
でもどちらも人間なんだから限界あるだろ？そこを擦り合わせるんだよ。
それが論破合戦じゃない議論なんだよ。
「こいつは自分を潰しに来たから潰し返さないと」とか思ったりしてる？
大抵潰し合ってないですかね
Haskellを否定というか、
明らかに間違えてるので、知りもしないで突っ込んでるとしか思えないが
食わず嫌いは勝手だからいいとしても、さも知っていて、かつ理性的かのように振る舞うのはどうなんだ？
素直に理由はないがキモいと言えばいいのに
大規模案件で採用されているゴミ屑PHPさんの悪口はやめろ
>いや、完全に記憶だよりだからその辺違うなら違うんだと思う。
>optionじゃなくてnilだった気もする。
記憶違いのレベルでなく、それはどこからどう見てもHaskellの型とは似ても似つかない。
記法の問題でもない。
概念レベルから根本的にHaskellとは異なるものをHaskellの欠点と言い張っているだけ。
Nothingとnilは間違えないよな
nullって書いても他言語とは全く異なるし
ないからなw
どこから見てもお前の言ってる事がおかしいぞ
論理的におかしい事をさも正しい事のように言ってるから叩かれてるだけ
何を言ってるかわからないほど破綻してるから、おかしいで合ってるし
そして論理そのものは前提で変わり、妥当性とは関係ないので、お前の主張もおかしい
論理的云々と言うやつほど論理を知らない証左
割とありがたいし、せっかくだからちょっとやってみるわ。
>>933
あーなるほど。それはわからんでもないな。
ただ、指導教官に昔言われた「不明点は察するな、現実を話させろ」を実践してて、
言ってしまえばアスペ的思考をしてたから、ちょっと慣れるまでに時間かかるかも。
実際役にもたったしね。その発想。
Haskellｂﾇうのこうのとｂ｢うよりもまず
お前は重度の知ったか自己弁護野郎であり
さすがに付き合いきれないよってこと
たぶん、そういうとこは伝わってないんやろな
Haskellどうのこうのというよりもまず
＞不明点は察するな、現実を話させろ
大学の研究室や学会では正しいが、2chっつーかネット越しの文字でやるには向いてない手法だな
手法は場によって選ぼうな？
あと自分が間違ってるかもしれないって懸念は常に持っとこうな。
下段は今回のHaskellのことに限らず知ったかぶり悪循環に陥ることへのフェイルセーフな。
俺はHaskell詳しくないから知ったかかどうかわからんのだが一応。
Haskellを知ったかぶるのは大したことないが、医学を知ったかぶると命に関わる
Haskellの型クラスは裏でメソッド辞書を渡して実行時ディスパッチをするって読んだんですがこの理解で合ってます？
https://people.csail.mit.edu/dnj/teaching/6898/papers/wadler88.pdf
それともコールする関数の決定も何らかの最適化機構でコンパイル時にすませてしまうのでしょうか
C++のコンパイル時ダックタイピングと同じ
実行時ディスパッチではない
後者で合ってる
GHCの場合は最適化無しでランタイムにdictionary lookupするコードを生成
最適化でコンパイル時解決になる
指定なしなら通常は最適化される
なるほど
If the type of a function contains a class, then this
is translated into a dictionary that is passed at runtime.
The translation simply assures that the appropriate dictionaries
passed at run-time; ...
One drawback of our translation method is that it introduces
new parameters to be passed at runtime, ...
等々しつこく書いてあったのでてっきり今もランタイムかと。
その後コンパイル時に完結できるようになっていたんですね。ありがとうございます。
念のため言うが、飽くまで一般の話だよ
上での言及のように例外なく、必ずcompile timeになるかどうかはわからない
普通に考えれば、呼出側だけでなく、モジュールに何か細工が必要だろうし
調べてみたが、少なくともHaskell 2010ではCompile timeが保証されているようだ
というか88年の文献は、いくらなんでも古すぎないか？
もちろん、人と人だけでなく、人とコンピュータも分かりあえる共通言語だ
それこそが次世代言語だ
ネット越しだからやるべきかとは。。
>>961
ヨコからだけどありがとう。参考になるわ。見てくる。
>>962
エスペラントを一歩すすめる時代か。
やった結果がお前さんの現状なんだよな。
Haskell 2010 でもまだランタイムに依存しているみたいだけど違う？
https://stackoverflow.com/questions/28169119/is-the-dispatch-of-a-haskell-typeclass-dynamic#comment44713002_28170590
ちょっと話が見えないんだが、もしかして回答してほしいのは
>https://people.csail.mit.edu/dnj/teaching/6898/papers/wadler88.pdf
に限定した話ではないのか？
保証については、再帰がない場合の話で、その参照先は>>959とは状況違う
その場合>>958 + >>960という回答になる
制限を超えたらエラーにするか、あるいはspecializeをやめたら無限に再帰できるか？
あ、いえ、すみません
>>958+960 で理解の確認はできています
ありがとうございます
ただ一方で >>905 >>957 >>961 みたいな主張もあるようなので
最新の実装では型クラスを取り巻く状況もかなり違ってきているのかなと
それより互換性が完全になくなった変更を批判する方が建設的
可読性が高いって言われてる理由が知りたい
インスコしようかな
何系の言語かは自分で判断すべし
文法知らなくてもほぼほぼ読めるぐらい平易だから可読性高いって言われてるのでは
Webの文系エンジニアにバカウケ
さすがにCOBOLに失礼ちゃう？
プログラミング熟練度と人気が反比例してると聞いたな
それ以外は割とよくまとまってる。
ノリとしては極限まで肉をそぎ落としたJavaに近いかな。
手続き型言語でオブジェクト指向止めるとなるとグローバル変数が問題になる。
変数宣言時に、その変数へ読み書き出来る関数とかをホワイトリスト的なものを宣言する事で制限したりとか、そう言う仕組みが要るんじゃないかな。
C++がキメラ化してるしある程度人気出るのも納得できる
ローカル変数こそが、そもそもこいつが何者かわからん存在であるって言語もあるしな。
「僕この名前で変数使いたいから、いったん退けて。ブロック抜けたら要らないから捨てて」
「制御命令？IFとスタック積まないラベルジャンプとスタック積むサブルーチン呼び出しがあれば、それ以外要らないでしょ。仕方ないからブロック構文だけは作ってやったぞ」
という現代の言語から考えたら意味のわからん命令があるM言語みたいな。
ライセンス高いし大手以外ノウハウないし、最近オブジェクト指向しようと歪になってるらしいから、それこそ化石だろうけど。
今どこ使ってるんだろ。
}
000-"M","LES","TUV=0.13325&/0\7&%&",
001-"23","1","0","2","7.14",[\b%7/1444*%812%2.3%7&6111\end\\]{%3%12%\br
Goだとその辺はパッケージである程度制御はできるな
あとはクソカジュアルにmutexが使えたりcontextでセッションローカル変数簡単に引き回せたり、
Goroutineでの並列を売りにしてるのは伊達じゃねえやって感じ
まあそんへんの糞なプライドを捨てればいい言語だと思うよ。
熟練者はそれを逆手に取って嫌いなものを体得する
嫌いなものを無に還すことができるなら必死に体得するのは理にかなっている
>>981
同意
長さ制限に引っかかったらこのままでいい
OUT: Scala, Rust
IN: TypeScript, Swift に一票
一からできるなんて楽しすぎるしな。
>>990
Haskellはガイジと呼ばれる俺ですら感じるキチガイを集める事になるから反対。
TypeScriptは微妙。それより、いっそJS側に倒してESnextとかでいいんでないの？
Scalaが要らんのは同意、Rustはちょっとどっちでもいい。
InのTypeScriptは反対。Swiftはもうちょいガチでマルチプラットフォームに来てほしいけど、くる気配あれば同意
まあC#系はKotlinが一つあれば十分かな
ScalaとRustはずしてSwiftいれるとか正気か？
お手軽言語スレでも立ててそっちでやれと
Haskellアンチは一人の発達障害だけであることが判明したので入れましょう
http://mevius.2ch.net/test/read.cgi/tech/1497311647/
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 54日 4時間 11分 5秒
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 【速報】イスラエルが正式にイランへの攻撃を開始… [BFU★]
- 【熊本】公園のゴミ巡り口論の末、女児殴った疑い 75歳逮捕 [Ailuropoda melanoleuca★]
- パックン 年金納付引き上げ案を受け入れる国民の反応に驚き「アメリカだったら大きな反発、フランスなら暴動」 [ネギうどん★]
- 【熊本】公園のゴミ巡り口論の末、女児殴った疑い 75歳逮捕 ★2 [Ailuropoda melanoleuca★]
- (マイナ保険証)利用率に関係なく健康保険証廃止 マイナカード一本化で厚労相 [蚤の市★]
- 水原容疑者が大谷翔平に“なりすませなかった”理由 銀行員との会話を聞いた米捜査員が証言「オオタニは流暢な英語は話さない」 [フォーエバー★]
- イランで大規模な爆発 [256556981]
- 日経平均、またまた大暴落で円安株安の最悪の結末へ…岸田どうすんのこれ… [434776867]
- 【悲報】日経平均-1100 [126042664]
- 【速報】イスラエル、イラン本土に直接攻撃 [237216734]
- 【画像】ASUS（アサス）、めちゃくちゃ強そうなルーターを発売💪😤 [583597859]
- おっぱいを揉むにはどうすれば良いのでしょうか？