次世代言語議論スレ[Go Rust Scala Haskell]第5世代
http://mevius.2ch.net/test/read.cgi/tech/1497311647/
次世代言語議論スレ[Rust Kotlin Haskell]第6世代 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
次世代言語議論スレ[Go Rust Scala Haskell]第5世代
http://mevius.2ch.net/test/read.cgi/tech/1497311647/
Kotlinがあるしまあええやろ
臭いがうつるから寄ってくるなガイジが
見向きもされてなかったな
SwiftもAppleじゃなかったら
古い状態しか知らなかったのは認めるが、Haskellを攻撃してるんじゃないぞ。
Haskell信者に、オナニーすんなよって牽制してるだけ。
>>11
Scalaも消えてる時点でお察し。
905 ：デフォルトの名無しさん：2017/05/31(水) 06:14:00.96 ID:wEozaoTa
>>879
では、具体的にGHCが実行時型情報を必要とするケースを挙げてみろよ。
言っておくが、パラメトリック多相は全てコンパイル時に解決されるし、
型クラスによるアドホック多相も、あれは関数オーバーロードの形式化だからな。
関数オーバーロードはコンパイル時に解決されるぞ。
さあ、具体的に挙げてみろよ。
908 ：あ：2017/05/31(水) 09:15:21.09 ID:dc+IbjjD
>>905
具体的に上げろと言われてもなぁ。
<T>を持ったenumがOptionかcar(T)とcdr(<T,T>)である時くらいかな。
0940 デフォルトの名無しさん 2017/06/01 01:21:00
>>930
>いや、完全に記憶だよりだからその辺違うなら違うんだと思う。
>optionじゃなくてnilだった気もする。
記憶違いのレベルでなく、それはどこからどう見てもHaskellの型とは似ても似つかない。
記法の問題でもない。
概念レベルから根本的にHaskellとは異なるものをHaskellの欠点と言い張っているだけ。
クソゴミガイジスギィ！！！！！！！！！！！
こんなガバガバ知識でHaskell 信者牽制しようとか草草草ァ！！！！！
余程Haskell好きなんだね。
そりゃ永遠の次世代に相応しいのかもしれんな。
わざわざScala落としてるし。
しかし、Haskellなプロジェクト聞かんなぁ。グループ社内にも稼働してるプロジェクトなさげ。
どこでどう使ってるんだろう？
まあ、知識無いのはそうなんだろう。本気で使った事は無いし。
アンチ的な意味ではなくて、実用例知りたい。
信者なら信奉してる凄いコードとかプロダクトあるだろうに。
無いから次世代だって訳でも無いだろうしね
Goは全然次世代言語じゃない
爆サイというサイトで「なりすまし防止」でパスワードを入れたんですが、解析されて同じトリップを相手に使用されました。
気持ち悪くて怖くなり、それ以来やっていません。
62^4＝14776336通りもあるパスワードをどうやって解析したんでしょうか？
もし解析ができるなら、やり方までは聞きません。
解析ができるのかできないのかを知りたいです。お願いします。
総当たり攻撃であっという間に陥落するご時世ですが、何か？
あちこちに貼りまくってる
つまり、ここ2ちゃんのトリップも簡単に該当できるということでしょうか？
>>24
すみません。
ここと合わせて3ヵ所に書きました。
どこのカテゴリーで尋ねればよろしいでしょうか？
DeepLaningでお前の書き込みから逆アセで住所特定したわ
震えて眠れよ
redhatに支援されてるのに泣かず飛ばすの
ceylonに謝れ！
そうなんですか。凄い詳しいんですね。ありがとうございます。
私みたいなクズ人間の住所を知られて、お伺いしてもらってもかまいません。
オフ会でもしますか？
きも
textPlusってアプリ入れてますか？
お電話します？
タダでは申し訳ないので、色々と教えていただけましたら、お礼はいたします。
なにもしてないですよ？
機能かなぁ。
むしろポリシーとか思想とかそっちじゃない？
機能だとしても、温故知新でより整理されたのであれば必ずしも新しなくてもいいと思う。
糞機能をなるべく排除した方がよいというのはとても前向きな発想。
時期じゃなくて機能で語れば
今でもPrologは次世代言語
そうだよ
まさにこれ。 Goは引き算の美学がある。
* publicとかprivateとか本当に識別子として必用？削ろうぜ。
* classとstructって本当に両方必用？ structだけにちゃうぜ
* 構文規約、言語側で決めちゃうんで問答無用で従ってね。
* パッケージ管理っている？ 直接import文にgithubのurl使っちゃおうぜ。（最高!）
それはあるのかもしれない。
まつもとゆきひろの 言語のしくみ を読んでるけどそんな感じはする。
rubyの作者が作ってる言語streemも気になる。
言語としてRxの全てはストリーム。を体現する言語になるんだろうか。
引き算は使いやすくなる範囲でなら良い
Lispみたいに極端に単純化し過ぎて
可読性下げなければ
ギフハフが死んだらどうすんだろ
別にgithubではなくても、リポジトリ作れるし取ってこれるよ。
逆に、フォークするのがめんどいと問題になるぐらい。
いやメモ帳で書いてるんなら確かに読みにくいと思うけど
lisp つっても common lisp と scheme だとだいぶ違うけどね。
common lisp はだいぶ残してる方だよ。
リスト操作をforで書かせる言語のどこが引き算の美学？
forと言う単語に引きずられてるのでは？
チャンネルが尽きるまで、がforで書ける。
シーケンシャルに舐めるのであれば、バッファのあるチャンネルが実質、リストとして使うに充分。
マップでも同じ構文で書けるけど、キーでアクセスしない、Enumerator的なものは充分にチャンネルで捌ける。
かつ、そうしとくと入れる方も出す方も両方goroutineにできるので、思ってるより色々シンプルに片付くよ。
>>51
Lispは可読性の低さが普及しない原因
>>52
CLでも大差ないと思う
Clojureまで行って少し可読性
上がったかなっていう程度
具体的にどのあたりが読みにくい？
確かに視認性はよくないなと思うことはあって
エディタの助けがかなり必要だとは思うけど。
>Lispは可読性の低さが普及しない原因
そこまで断定的に書くってことはなんかエビデンスあんの？
適当なメモリブロックを適当な型に適当にキャストするだけで
配列としてアクセス出来たり、構造体としてアクセス出来たり
世の中には、こんな基本的な事すら出来ない言語もあるようだし
エビデンスは>>56。
あれクソ構文だと思ってた。
使ったことはないが。
rubyは足し算の醜学だろ一緒にすんな！
map/reduce, collect/inject これすらまとめられません笑
関数、ブロック、プロック、え？ラムダが流行りだって？じゃそれも笑
思想がないからあれもできるようにしましたこれもできるようにしましたで何一つまとめられません涙
goと真逆じゃねーか何でもかんでも未整理にぶっ混みやがって思想もへったくれもあるかあんなゴミ。
言い過ぎたがgoの引き算にすり寄っていい言語じゃないことは確かだろ
普及期にC言語が一番使われてたからそれに似た言語が一番読みやすい人が多いってことだろ
それが読みやすさの本質を持ってるからだろ
ペェ〜ルとかルビー（藁）とかさぁ・・・なんだい、あのゴミは
yaccとかに食わせられるんかね、良く知らんが
まさかソースを(白黒)印刷して読んでるわけではあるまい？
漢字のような表意文字は抽象度が高く、短い語数で意味が凝縮されるから可読性は高まる
でも中国語のように英数字以外がすべて漢字になると、区切りや各単語の軽重が分かりにくく可読性が下がる面もある
ということで日本語は優れてると思うけど結局は慣れの問題が一番大きい
基本五文型とか初めて習ったときは意味不明だったよ
日本語には無い考え方だ
着目している部分が全然違ってて流石だなとしか言いようがない
もっと言えば英語のような言語は構造重視、関係性重視の言語だと思うし
日本語のように述語が最後に来る形式は時系列重視の言語だと思う
そんなもの無くても会話は成立するのになんでって感じだし
日本語には全くない感覚だからな
あるカテゴリーの中の一つ、とか、固有名詞、とか、えらく数学的で
普段からそんなこと考えながら会話してんのかよマジ半端ネーナって感じ
文法の中にそんなものを持ち込むこと自体が凄いし
言語が自然発生的に出来上がったのだとすると、脳の構造違いすぎるでしょ
世の中のことをそういうベン図みたいな捉え方するのが彼らの日常ってことだからな
(= (* a (* b c)) (* (* a b) c)) (中)
a.mul(b.mul(c)).eq(a.mul(b).mul(c)) (低)
(中)と(低)の括弧の数は同じ
つまり表示デバイスや読む人の能力によると
お前の表示デバイスだと>>75が違って見えるの？
頭おかしいな
意外に日本語では修飾語使うしかないシーンでも端的に話せるから便利だよ。
ラテン語ぐらい活用があればホントに単語に主語すら含まれてるから文章の密度が濃くできる。
aや数詞とtheは、日本語でも知らず知らずのうちに使ってるよ。
まともなlisp書くやつは、可読性中とやらみたいなの書かんだろ。
(= (* b c a)
(* a b c)
)
みたいになるんでないの？
表示可能な文字数が少なかったりプリンタだったりしたらRISCの方が効率いいだろ
お前が書く全てのプログラムは>>75程度なのか?
それともお前の頭がおかしいのか?
jsの処理系使ってaltJS作るのに最適かもしれない。
こういうの触るとLISPってまんま構文木を言語と対応させたもんって感じ。
括弧が多いこと以外にも
JavaやRubyみたいな
ふつうの言語の文法と違いが
大きいところが読み書きしにくい
たとえば代入は＝じゃなくてsetqとか
たまに初心者がなんでイコールが代入なの言うけど確かになが
という漏れもそうじゃない文法を自分で書きたくはないけどねｗ
setqはset quoteに展開されるマクロで、setも関数。
ただの代入の構文ではない。
すべて式、みたいな流行りの言語のように、すべてリストで、リストの先頭を関数として解釈しとるだけ。
OOPは言語レベルでサポートされていなければならないってC++の作者が力説したから
これは文法とパラダイムは無関係という説を否定したようなもので
同じパラダイムをサポートするなら文法もほぼ同じになると考えられる
a→具体的な意味を持たない。ok?
鋭→具体的な意味を持つ。まだ大丈夫？
具体的の反対は何か分かるかな？
分かんないか、ごめんね。正解は「抽象的」
漢字のような表意「文字」が(アルファベットのような表音「文字」と比べて)抽象度が高いなんてことはあり得るのかな？お母さんに聞いてみようね！
漢字を抽象度が高いというのは何か違うと思った
それらは対等に扱った方が対称性が高い
どっちが高レベルでどっちが低レベルかという問題にこだわるのは対称性が低い
「抽象度」という概念を知らないのね
1. x^100 + 9x^7 - 3x^2
2. x to the hundred plus nine x to the seventh minus three x squared.
「どっちが抽象度が高い？」と言うのと
「どっちがより具体的な意味を持つ(もしくは持たない)？」と言うのとは意味が違うんだよ
その1と2って表意文字と表音文字には対応しないよね？
表意文字と表音文字の抽象度云々論じるなら例えば
2a. x to the hundred plus nine x to the seventh minus three x squared.
vs
2b. xの百乗足す九xの七乗引く三の自乗。
になるけどこの2a vs 2bの文字レベルの抽象度の差とやらは1 vs 2a/2bの表現レベルの違いと比べたらあるとしても誤差レベルじゃないか？
俺には2aと2bは全く等価に思えるんだが、、
>>89 が聞いてるのは抽象的とは何か また２つのモノが与えられた場合の抽象度の比較についてだと思うの。
>>92 はそれに対して 答えてるだけだと思うの。
そしてそれは 普遍的に決まるので正しいと思うの。
“アラビア数字、その他の数学記号は、代表的な表意文字である”
https://ja.wikipedia.org/wiki/表意文字
情報密度が高いと言えば理解してもらえるのかな？
2bを全部平仮名にしたものと比べれば一目瞭然でしょ
んで情報密度の違いは抽象度の違いによる結果だから
たとえば写真は具体的で情報量が多い
漢字もアルファベットより具体的だから
一字あたりの情報量は多いが
覚える必要がある字数は多くなる
抽象化()で単位をあやふやにすれば比較できるのかな
基本的に抽象度が上がれば情報量は下がっていくものだと思う
プログラミングやってれば経験するものだと思うが
Object型は抽象度が高いが型に関する情報量はほぼ無い
よう、オフィスマ。元気かい？（笑）
具体的な実装が隠蔽されているほど抽象化の度合いが高いという意味で、
漢字は2バイト(以上)を1文字に「抽象化」していて、
1文字あたりの「情報量」はアルファベットより多い
ママンにパンツ洗ってもらったか？（笑）
「筆や指、ヘラ、ナイフなどを使い、油性の絵の具を、板や布、紙など平面に、芸術性のある意匠を表現すべく塗布したもの」を「油彩画」と記載できるのは、情報密度が高く(3文字)抽象性が高い(『など』、を特定出来ない)と表現するならわかるけど、
英語でも「oils」、くどい奴でも「oil paintings」だし、抽象度や情報密度としてはあんまかわらんかと。
単に抽象度をあげると情報密度が下がるという訳ではなく、用途に対した適切な情報密度を提供するために抽象化するのかと。
情報量は減るけど情報密度が上がる方向に持ってくのが抽象化で、両方下がるのは標本化みたいなやつじゃない？
数学記号は表意文字。つまり
1. x^100 + 9x^7 - 3x^2
は表意文字の例。
2a. x to the hundred plus nine x to the seventh minus three x squared.
は表音文字の例。
2b. xの百乗足す九xの七乗引く三の自乗。
は表意文字の例(かな混じってるけど)
2c. xのひゃくじょうたすきゅうxのななじょうひくさんのじじょう。
は表音文字(2bを全部平仮名にしたもの)
かな？
1の数学記号が抽象度高いのは分かる。
で、2bと2cくらべて一目瞭然って何が？
どっちも1に比して恐ろしく冗長だな、としか思わんが。2bの表意文字も2cの表音文字も。
要するに文字が表意か表音かは抽象度とは関係ないということではないか？>>96の当初の主張「漢字など表意文字は表音文字にくらべて抽象度が高い」とは裏腹に。
/⌒ ヽ ／ ／
（ ）'ﾞヽ. _／
. ／iｰ-‐'"i ,; ／
i ! （ ヽ. ） ﾉ/ .:／
（＼.ﾞヽ＿（_／,ｲ／
i ! （＼＼＿,＿）' ﾉ
（＼＼＿,＿,）'
i ! l ,i＼ ヽ､ ! あ”っー あ”っー あ”っー あ”っー あ”っー
し'
情報量は少なくなるに決まってるんだよ
必要な情報だけ抽出することで
量より質を求めてるわけであって
/⌒ ヽ ／ ／
（ ）'ﾞヽ. _／
. ／iｰ-‐'"i ,; ／
i ! （ ヽ. ） ﾉ/ .:／
（＼.ﾞヽ＿（_／,ｲ／
i ! （＼＼＿,＿）' ﾉ >>109
（＼＼＿,＿,）'
i ! l ,i＼ ヽ､ ! あ”っー あ”っー あ”っー あ”っー あ”っー
し'
いいんでないの？
数学に強いであろうHaskellerさんなら、標本化と抽象化、情報量と情報密度を語ってくれるだろう。
きっと。
次世代じゃない、とか、文字数の関係、とか言って議題を恣意的に絞った罰に相応しい流れだと思うが。
言語仕様ってできないものなのかね
printf()みたいなのとかですら
言語ごとに"微妙に"違ってて
いちいち覚えなきゃいけないのって
アホらしくない?
数年も経つと想定されてない
技術が出てきて負の遺産になりそう
print 文を本当に統一するとしたら一番、低レイヤーな扱いしてる c に合わせるしかない。
てか統一厨ってなんで分かれてるのかについてほんとに思考しないよな。
どうしても後追いの追加しかできなくて
そうすると時代遅れの規格になる
MSやグーグルやアップルみたいな大企業は
それを無視して需要のある新言語を作るだろうし
だから今の現状がこうなってるんだろう
標準出力がない環境やら、sprintfとかは普通のlibcではでか過ぎるとか話とか、ファイルシステム？そんなのねえけど？みたいなめんどくさいのを経ての仕様策定になる。
どっかで線引かないと仕方ないけど、その線は言語次第で決めざるを得ない。
Rustの「マクロで展開」もありだろうし、GoやらPythonの「だいたい付いてるけど、それが動く環境以外ではそもそも動かない」もありだし、
Scalaとか古いPascalみたいな「VMが動く環境では動きますけど？VMポートしてよね(笑)」みたいなスタンスもアリなんだから。
仕様や規格って「守らなくてもそれで良い。むしろ守らないほうが(うちのシステムでは)確実に早く動く」って奴が絶対出てくるから、どれだけ未来の事考えて準備しても無駄。
今要るものを今要る範囲で作るのがいいんじゃねえの？
過去と今を見ずに未来や次世代の話する奴にろくな奴はおらん。
ES2015が出るまで20年も掛かってるから
各言語共通規格なんて100年掛かっても
できるかどうかってところだろ
どんな言語からも、どんな言語で書かれた関数でも、呼べるってやつ
どんな言語は言いすぎだが、大体のメジャー言語は似たような着地点に落ち着いてるし
このような重大なことは無理やりにでももっと黎明期に決めておくべきだったな
標準入出力用意しておいたので後は好きにしてくださいってのはちょっと
個々で独自な処理なんて
いくらでもしたらいいけど
最低限、(例えば)printfって打てば
文字列出力するのは
保証しとけって話
つまりはライブラリは標準仕様に準拠しているので
ライブラリは揃ってますんで
是非俺の糞言語を使ってくださいっていう
しかし今みたいにライブラリの互換性を盾にして
既得権な言語が常に上位に固定されて全くシェアが変動しないのも不健康
何の言語で書かれていてもかまわない、どうせ好きな言語から呼び出して使えるから
ってなってれば良かったんだが
移植とかマジ馬鹿らしいし
JVMか.netで動く言語でも使えば？
どんな環境で動くかも決まって無い上にさらに言語の定義すら無いとなると、呼び出せる訳ないかと。
あとは別プロセスとして通信するか。
>>121
文字列って何？パスカル文字列？ヌル終端？エンコーディングは？出力って何？
って話じゃん。独自の処理ではないと言いながら、既に充分独自の話。
どうでもいいのよ
対応する事を仕様にいれろって事
そのようなことは正にどうでもよいだろうというのが俺の意見
言語の多様性の観点からも、そんなことを縛っても意味はない
それよりは、どんな言語からでも、どんな言語のモジュール(ライブラリ)でも
呼び出せるって方が重要だと思うよ
もしそれが出来てれば、君は延々と自分の好きな言語だけ使ってれば良かったかもしれないし
そうじゃなかったとしても、どの言語からでもCのprintfが簡単に呼び出せるんなら
君の願いは達成するんだろう？
それも構わないと思う
通信のフォーマットが統一されてれば
後は処理系がそれに対応すればよいんじゃないかなー
RDBとのやり取りも、それですれば良かった話
さらにはネットワーク越しに呼び出したり
そういう標準が一つ欲しかったね、って話
今更遅いが
趣味で作るならユーザーの願望よりも作者の都合が優先される
アホか。対応する事を仕様で決めるためには、何に対応しないといけないか定義出来てないと、対応しようが無いだろう。
何をどうしたいのかわからん。俺ラッパー一枚で済むんじゃねえのそれ。
>>126
今までもCorbaとか色々あったけど、結局は一番無難かつ使われてるHTTPになるんだろうなって感じかな。
前にも同じ発想を書いた気がするけど、なんだかんだでこなれてるし、いつ使うねんと思ってたし、RFCにも「どっかで役に立つ」みたいな記載されてたUPGRADEのおかげでWebSocket使えたりしてるし。
もうちょい早く、なら処理系で対応するよりOSに頼った方が良いんだろうな。UNIXドメインソケットとか。
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.8.2.html
もう20年以上前になるのか。歴史は繰り返すんだな。
糞ﾜﾛﾋﾟｵ
あんたただの気狂いなだけじゃなくて物知りやね
ガイジVSガイジって感じやね
まっとうな意識ではあると思うよ
HTML5とJSに人が集まってるのも
今一番の共通規格っぽいからなんじゃね？
ID:SQFm1IPC「ぼきプェチピィ〜しか書けましぇ〜ん
他の言語もプェチピィみたいになればいいと思いましゅ、アヘアヘ」
こうやろ
ガイジウムとりすぎか？
そりゃブラウザっていう共通実行環境があるっつーのに、
各々のメーカーの都合で規格がずれてるって状況があるからでしょ。
なんもないところにとりあえずグローバルな規格作ろうとか誰かの自己満足にしか
ならんことを言い出すからバカにされるんだよ。
そういう他言語を意識したつくりになってるってわけじゃないから今回の件では不適切な例だよ
どう贔屓目に見てもHTML5とJSは他の言語とは違った異質なもので
ぜんぜん寄せてきてないよ
こういったものを例に挙げて肯定的にとらえる文体なら
よりいっそう各言語で共通の文法〜〜は要らないってことになる
これは意訳すれば全部Javaで書けばよくね？って言ってるようなもので
他言語を巻き込んで文法を共通にするとかとは反対のベクトルの意見に見える
文法に共通な部分を持たせるっつっても、使用感だけの問題であって
PythonでRubyのコードが走るようになるわけじゃないし
大体のメジャー言語はC言語の文法に寄せてきてるから
その意味で特に不満はないな
細かな仕様が違うのはそりゃ当たり前でしょ
言語として最低限サポートしなければならない仕様を作って
それを満たしていればC上でもJava上でもPython上でもRuby上でもPHP上でも
とりあえずは動く、っていうなら、有りかもしれないけど、あり得ないでしょ
全然違った概念とメカニズムで動いているのに
これ、確か本で読んだと思う。確かに10代だったかもしれん。
>>132
伝わってるやつが居るのに、まだお前は馬鹿な事言いづけるのかなぁ。
おまえがID:SQFm1IPCの言いたいことを全く理解してないんだよ
おまえだよおまえ
どー言うこと？
要は、puts("文字列");
程度のコードはどの言語でも寸分違わぬ同じ動きをすることによって、学習コストを下げたい、って話だと受け取ったが。
そして、それは無理、言語の良いところを殺す。極論は>>130。こんなことするならPascalで書けと。
そもそもさー。"文字列"がすごい、ものによっては言語設計の軸になりうるものなのに、「文字列を出す程度の関数」が低レベルで各言語共通にできる訳ないっしょ。
まー、代わりに説明しといて。あとで読むわ。
を土台にして成功したのがJS
C++がCを土台にしたみたいに
なーんでそこまで分かってて
『「文字列を出す程度の関数」が低レベルで各言語共通にできる訳ないっしょ。』
なんてレスが出来るのかわからん。
あとこの文脈でおまえがどういう意味で「低レベル」という単語を使ってるのかわからん
少しのズレ承知でありたいていに言えば、こいつは「内部でどういう動作するかなんてどうでもいいからとにかく、端末のある環境なら、putとかではなくprintfと書けば端末に表示することを保証しろ」と言ってんだよ
>どうでもいいからとにかく、端末のある環境なら、putとかではなくprintfと書けば
>端末に表示することを保証しろ」と言ってんだよ
だからそのことが否定されているのでは？
何言ってんだ？
まぁ無理だろう
それより通貨を行き来できるようにする方が良い
だからただID:SQFm1IPCを否定するレスには俺は文句つけてないだろ？俺もID:SQFm1IPCはガイジだと思うし。
いつまでも「低レベルで」とか「文字列の仕組み」とか言ってる奴はおかしいって言ってるんだ
プログラマにはならないほうがいいと思いますよ。
ムリだよ。
多少のズレがある時点で仕様では無いし、言語仕様レベルから>>130の無茶苦茶感出てくるぞ。
低レベルってのは、ごめん、いつもこれ伝えづらいな。
システムコールとか呼ぶようなオペレーション、かな。
ちなみに、putsではなくて、printfなら、フォーマットはやるんだよね？Cの形で。
文字列の仕組みは知らないと今時の言語でも辛いだろ。
そんな事気にした事もないなら、一生気にしないだろうけど。
文字列未だに理解不能（笑）
utf8だったり、sjisだったり
c#になってからstringが
なんの文字コードで扱ってるかまったく理解してない
sjisのファイルから読み込んだ文字列と
utf8のファイルから読み込んだ文字列とか
c#のstringではどうなってるか知らんｗ
どの段階かで変換されるのか保持されるのかわかってないｗ
日時の文字列のカルチャとかいうのもよくわからない
無指定だとos依存になってバグるし
じゃあc#のstringって何使われてるの?
osに依存するの?とかマジよくわからん
初心者スレで聞いてみたかったｗ
確かにprintfのfはフォーマットのfだったと思うけど、Fortranではprintでフォーマットもするんだし、言語仕様レベルで滅茶苦茶は言い過ぎでしょ
そりゃfはあったほうがいいと思うけど、fがないと言語仕様レベルで滅茶滅茶ってことはない
そして、厳密な名前にしたことで得られるメリットより、全部printにしたことによる学習コストの低下を優先しろとガイジID:SQFm1IPCを主張するんだよなあ
この話題の本質わかってないのなｗ
なんかよくわからんけど、エンジニアガイジと話すと撹乱されて本質が見えなくなる。多分普通の文より解釈がしんどくてそっちにリソース割くんだろうな。
正直>>151も書いていて微妙とは思ったし、昨日思ったこととなんか違う気はする。
もし本質が見えているならちょいと書いてくれると助かる
まあとりあえず c の printf からはじめるけど、これってバイト列からそのまま、出力する形式としては
とても普通な形式なわけだ。低レイヤーから見ても最低限のものになってる。
ただ、一方で型に対していい加減で %d とかと , 以下のところに放り込む変数が
ずれてたら簡単にアボーンするってなことが言われて cout << とか
まあ他の高級言語の print なんかがでてきたわけ。
じゃあ c もそうすりゃいいじゃんと思うだろうけれど、実際そんな高級なことすると
システムプログラミングみたいな生な現場だとその高級なとこにバグが潜む可能性が
高いし、そもそも無駄なメモリ食うし
ってな理由で拒むわけ。
とりあえず単純な見方をするなら上記のような理由で統一はされない。
言い過ぎでも無いのでは？
printfでも、言語によっては概念が無いので使えない(はず)の%pとか、じゃあ%sは何を取る？%cは？と、収拾がつかんかと。
まずメモリの値を何かに出すって事が実はすごく面倒だって分かってほしいけどな。安易な事言うやつには。
仕様で決めたいならミニマムなのが要るかと。
>>157
何がわかってないか説明してくれる？
わかってないって言うのは簡単なんだし、説明できないって事は自分もわかってないって事と取るけど。
ってのは、語順が変わる言語は守れない。
なら引数の順番は見逃すわと言ったら、次は型の問題。
型の定義と表現の定義は○○準拠な、となると、それを持ってない言語は用意すべきかとなる。
その辺見逃すわ、人間が見て理解できる形で！となると、見る人間がどんな人間か(言語は何か)でかなり変わる。少数とかだとフランスでの地獄の,とスペースに殺される形。
それも見逃すわ、うまいことやって！となると、
もう定義なんか残ってなくない？
ない概念は非対応にして%sはその言語で主に扱う文字列にすりゃ満足するだろうよID:SQFm1IPCは
なんならフォーマット機能すらなくしてfortranのprint*の挙動にしてすら満足するだろうよ
もう別物じゃん。
別物でいいんだよ。ID:SQFm1IPCみたいな手合いはそういうこと気にしない。printfと打てば出力すれば満足なんだから
そんなガイジといっしょにすんな
これは正論だ
テスト駆動でライブラリをテストする感覚
だが慣れたらテストではなく有名なソフトのソースを読めるからテストいらない
なんかわかってきた。本質ではない形でだけど。
標準出力と標準ライブラリとかそういうキチッとした話ではなくて、「printfデバッグで使うための関数」程度の存在として同じような名前で同じような仕様の関数が欲しい、って事か。
>>166
最初にやるようなつまんねー演習課題は、地味に奥が深いんよ。
はいはい画面に出ましたね。予想してたけど。って思うのも当然だけど。
帳票エンジン作った時にDSLのチュートリアルも書いたんだけど、書く側として見ると新しかったと言うか、新鮮だった。
https://www.infoq.com/jp/news/2017/08/Java-Still-One-Tiobe
>TIOBEは、特にCrystal、Kotlin、Clojure、Hack、Juliaを挙げて、
>新しい言語への関心が高まっていると見ている。
>これらの全体シェアは小さいが（すべて1%未満)、その浸透速度は注目に値する。
>特に、RubyのいとこにあたるCrystalは、1ヶ月で60位から32位へと飛躍した。
Crystalが早くRuby を追い落としてほしい。
細部は微妙だけど、まあ大方そんなもんだよ。大分近かろう
https://codeiq.jp/magazine/2015/07/26120/
擦り合わせしたいと言うと荒らし扱いされるから気をつけてね。
プログラムにコミュ力が必須という共通認識は出来ない
頭の良い人が多大な無駄な苦労をするのは
社会的損失だ
自分の知ってる分野・レイヤーの視点で語りたがる
兜合わせとかいやらしい
プログラミングも漢字でやるといいらしい。
そういう結論になる事が抽象化思考力の欠如してる何よりの証
入力速度がアルファベット＞非アルファベットになるのはどうしようもない
タブキーと補完使わないの？
俺、和文のあとに、同じ内容の英文つけたメール書くことあるけど、あきらかにタイプ数は和文の方が少ないよ。
抽象思考したいならLabViewとかSPSSあたりでブロック図とかフィルタのグラフで思考するのが一番早かろう。
そんなことよりユーモアが足りないと思う
ネットのおかげか世の中がマトモという言い方はおかしいけど
正解を引くひとが多くなってきたから
明らかにおかしい状況を
ユーモアで笑い飛ばす必要性があまりなくなってきたんだと思う
苦痛な環境に置かれても、ある種納得してるっつーか
でもプログラミングの世界はまだまだ黎明期に当たるのか
偉い人でも、おかしなことしている人がいっぱいいて
https://img0.etsystatic.com/178/0/13833747/il_340x270.1165546874_11w2.jpg
↑まだまだこういうユーモアが有ったりする
今後ある程度成熟していくと、もうこういうユーモアも見れなくなると思うと残念だね
と同時に、正しいことを知っているだけでは勝負にならなくなる
実力が問われるね
糞バカジャップランド土人が
山ほど遺してくれたコボルやペェチプゥの保守案件があるからね
DrinkをCoffeeのメソッドにしてることに最高に納得いかない。
設計者出てこい！
これ何がアカンの？
bool値はIsEmpty()がいいなー
おれはそれくらい明示的でいいかなと思うのだが。
次世代だとCoffeeが空かどうかのStateは、インターフェースじゃなくて、型クラスで制限して、パターンマッチで処理を切り分けるって感じかね
Cup cup;
...
if (cup.isEmpty)
{
cup = new Coffee();
}
else
{
john.Drink(cup.Drop());
}
Drinkの中でdropを呼べよ
いい言語だと思うけど
強いて言うなら学習コストだ高いとか。
インタラクティブに勉強する教材とか欲しい。
nodeSchoolみたいなやつ
おまえはcupをdrinkするガイジなのか？
ほんと使えるなこれ
ちょっと込み入ったもの書こうとすると即座にコンパイラがあらゆるコード受け付けなくなる言語のどこがいいんだ？
なおC++コードはきちんと動くことは実証済でな
Human you;
Cup cup = Mix(new Coffee(), new Poison());
you.Drink(cup.Drop());
ぶっちゃけ書き捨てプロトタイプには向かない言語
インタプリタ最強みたいな感じなのかな？
ランタイムでこけるより、コンパイラでエラー出たほうがいいじゃん
>>190
今どきのメジャー言語は
たいてい関数名＋括弧だけじゃないか？
いちいちcallとか書いてたらコードがcallだらけになるし
関数定義のfunctionすら面倒だっていう声があるから
いちいち関数を明示的に呼び出す言語は流行らないよ
Fortranくらいしか書いたことない
言語はいいんだけどまだ普及してないからライブラリが辛い
call書かないとカッコ書けないVBAとかが、callだらけになるかな。
でいいだろ
これは同意
lispのS式は自然なんだなぁ。
f (ｘ ＋ 1) みたいないことしたり
f () みたいなことするなら括弧的なもの必要になるし
単に省略してるだけでしかないのでは？
だよね。Lispだと(f x)
どの言語でも定義と実行の区別は必要なんじゃないかな
Nim ならどっちも不要だな
関数と変数とかで名前空間分けるのが普通なのかな
一緒のがシンプルな気がするけどダメなの?
this.objみたいにスコープで名前空間分けたらダメかな
個人的には分けないほうが好きだな
配列の[]も要らないね
正直、そんな文法の言語
使いづらそう……
最後のセミコロンが要らないのと同じ
ｐｙてょｎのことか
ブロックあった方が正直みやすいわ
初心者にも、視覚的にここからここまでがまとまりだと説明しやすい
インデント強制はいいけど、いきなりインデントがどうとか説明しても、イミフやろ
↓
a[ b + c + d + f(x + c + 100
なるほど素晴らしいアイデアだな
実を言うとセミコロンの省略でも同じ失敗をしてるんだよな
y=f; (x)();
↓
y=f(x)()
(a !! b + c) + d + (f $ x + e) + 100
ガイジ
>>225
改行しろガイジ
(x)←意味分からんぞガイジい
優先順位を明示する、または関数呼び出し
どっちの意味か分からんから関数呼び出しの意味で括弧を使うのはもうやめたほうがいい
!! の方が優先順位高かった ゆるして
無意味な主張だな
>最後のセミコロンが要らないのと同じ
それなら、最後のコロンも要らないだろ
インデントを強制する言語の中で、
Haskell や Occam は文末は改行のみだけど、
ｐｙてょｎ(>>222)だけが要らないコロンを強制する
高階関数とかドットチェーンしづらくして、平易な書き方を強制したい
と見せかけてあの可読性ゴミ屑なリスト内包表記糞とかいう糞を強制してくる真性ガイジ
間違いなく俺が設計した方がいい言語できるね
変数スコープがぶっ壊れてる
for/ifの中から飛び散る糞とかほんと糞
馬鹿が書けばどこまでもくそにすることなんてできんだよ。
＞間違いなく俺が設計した方がいい言語できるね
無理無理
無名言語がひとつ増えるだけ
アンダーバーとか、色とか、枠線をつけられるようにしてブロックを表せたりとか
そういうGUI的に拡張させるアイディアって無いのかな？
他の言語でも採用されればいいのに。
実際は括弧付いてるようなもんなんじゃないの？
特定の開発環境に依存するのはリスクを感じる
言語の機能でなくてjavaのdocletやpythonのdoctestみたいに自由な部分で拡張すればいいんじゃないの
拡張可能にさえしといてあげれば、数多の楽したがるエンジニアが稀にいいもの作ってくれるよ
だから言語はシンプルがいい
これはちょっとすでに古い考え方だよ
今の人気言語は最初から機能てんこ盛りだし
ほとんどの言語はいろんな形でで最初から拡張可能
lispやschemeですら充分に複雑だよ
初心者はIDEに統合されててなんでも言語がやってくれる方がいいな
フレームワークとか作ってると競合しないように気を遣うが
Scalaなんかは最初からいろんな機能盛り込んでるな
そのおかげで言語仕様が複雑になって覚えにくいけど
IDEの機能はIDEに任せた方がいいんじゃないの
たとえばシンタックスハイライトとかIDE側の機能を
言語側に仕様を入れる必要ないと思う
そこをあえてやりたいなら
アノテーションで拡張可能にするかな
あんな感じでHTML形式でプログラムを書く
そうするとソースコードの途中にコードを説明する画像を挟み込むことが出来るし
音楽を入れて音声で説明してもよい
さらにはJSを駆使して動的なことをしてもよい
で、それで何のプログラムを書くかというとHTMLを書く
ブラウザで表示させる
ソースコードのソースコードがあるということだ
素晴らしいね
それをあえて入れるところに意味があって
人はあくまでプログラム自身に集中するべきじゃないかな
言語を選ぶだけで他の全てが自動的に決まるのが理想のように思える
現実には言語を変更するだけで他の選択肢も強制的に変更させられることがよくある
文芸的プログラミングの事かな？
XMLで可能だけど誰もやってないような
javadocで十分だな
https://www.youtube.com/watch?v=_Nps8xb5czQ
最新トップYoutuberの年収は10億円、1億円の時代はもう古い
http://www.himatubushisp.com/entry/2017/05/10/224945
Youtuberヒカルが月収を明らかに!!おはよう朝日です出演
https://www.youtube.com/watch?v=RLZGrqQnnZc
第１回案件王ランキング！YouTuberで１番稼いでるのは誰だ！
https://www.youtube.com/watch?v=asF2wQ2xhjY&;t=61s
ユーチューバーの儲けのカラクリを徹底検証！
https://www.youtube.com/watch?v=FUSb4erJSXE&;t=504s
【給料公開】チャンネル登録者4万人突破記念！YouTuberの月収公開！
https://www.youtube.com/watch?v=Y7DAQ0RKilM&;t=326s
誰も言わないなら俺がYouTuberのギャラ相場を教えます
https://www.youtube.com/watch?v=E4q-vaQh2EQ&;t=118s
最高月収5000万円だとさ。年収じゃなくて「月収」な
おまえらもyoutubeに動画投稿したほうがいい
手っ取り早く視聴数稼ぐには有名ユーチューバーへの物申す系動画がオススメ
しばたーやよりひとやkunやぽんちやモンスタージョンなどを真似すればいい
愛生病院みたいなsrc読みたくねえだろ
コードのメタデータとして言語機能が積極的に管理していく方向に発展して欲しいね
2013年まであったのかよ、恐ろしすぎ
病院の先生ってやっぱ頭良いんだなって思うのは
未だかつて愛生病院のサイトより見てて不安になるサイトには出会ったことが無い
やろうとしてできるものではない
そんなことが片手間で出来るんだから、医者って本当に凄い
http://web.archive.org/web/20130515083615/http://www.aiseikai.or.jp/
↑魚拓
若い人で知らない人は一度勉強したほうが良い
昔のインターネットがいかに刺激的だったかが良くわかるだろう
目の前にある具体例と真逆の結論を出すのがすごい
これが抽象化か
言語側で提供しましょうってアイデアだけどね。
TypeScriptで採用してる(採用しようとしてる？)。
言語のシンタックスに一番詳しいのは言語自身なんだからIDEの機能を提供してくれるのは理にかなってると思うけどね。
俺としては、言語を新しく使うたびに初期段階で補完機能に悩むのはしんどいので
新興言語はかならずLSPを用意しておいて欲しい
参考：
http://qiita.com/atsushieno/items/ce31df9bd88e98eec5c4
投稿先間違いました。m(_ _)m
どう見ても皮肉だろ
これどゆ意味？
C診断室ってCやってる奴なら今でもわりと有名だと思うんだけど
ALGOLだったと思ったけれど
ふり返るとこういう言語拡張はLispならアリだし
むしろ今の時代のDSLを先取りしているな
C言語中心の昔じゃ受け入れられなかっただけで
じゃあ、Ｍ式で書けよ
馬鹿がマウントしてくるので、コードを荒らされないようにするため
ってなことが増えてる。
悲しい話だよ。
マウントとの関連性がわからんのだが。ってかマウントがわからん。
自分のソースが荒らされる(≒自分では社内政治も含めて『直せない』)ほどの影響力ってマウントじゃ無くて、ついていけてない実力差であって、あんまりマウントマウント言うべき事で無い気がする。
現に、新しい言語を覚えるモチベーションになってるならなおさらでは？
負債作るだけだから実務では余程求められない限りやるべきでは無いけど。
サーバルちゃんすこ
意味不明すぎる…
yacc的なのを言ってるなら既存ので十分すぎる
yacc要るほどの自作言語なら言語自作らんほうが幸せ。
セルフホストするときに苦労が増える。
何言ってんのこいつ
yaccは糞としても、今時構文解析に専用ツール使わねえ方がめんどいだろ
構文解析に専用ツール作るならわかるけど、少なくとも+++++の解釈が不能とかいや出来るとかくだらん事は考えたくないし、フルにそいつの機能使うわけでもないのに、ビルドするために依存したくはなくない？
そいつでコンパイルできるソースが出るパーサジェネレータが欲しい。それが面倒なぐらいなら、その言語で手書きできるパーサの範囲の言語にしろって事。
BNF書くこと自体も勉強になる
パーサ手書きの練習なんぞ電卓レベルで一回やれば十分
あんなもんただの単純作業だ
他の人の書く文章と明らかに違う
そもそもの何かが違うとしか言えない
何が違うかは分からんが、とにかく違う
話を長引かせる能力だけは本当にすごい
そりゃお前だって2レスも(しかも無駄に)してるんだから長くなるんじゃねえの？
「何が間違ってるかわからないけど間違っているに違いない、なぜなら俺がそう思うから」みたいな感想文の代わりに建設的な否定でもすりゃ、早く話終わるんじゃねえの？
自分で論点ずらして話を長引かせる瞬間の>>287を書いて気付いてない無能にはそれは無理なの？
「あ」に忠告しておくが、君は特に>>289のように概念的な話をしようとすると本当に全く人に伝わらないから注意した方がいい
>>285のように具体的な物事に照らして話をしてくれれば、まだ少しは理解できる
これまで何度も指摘してやってんだから素直に認めて頑張って直せや
そいつつついても何の得もねえぞ
そいつはお前らに相手してもらうことだけを目的としてる
いくらかマシなレスしてるから許せるよ
汲んでないのはそもそも汲もうとしてない。
書かれていることを書かれているように理解して、書かれていない事を推測しないのは基本じゃないの？
そんなとこ汲むから全員が思い込みで話して、散らかるんじゃないの？
具体的に照らせても無いのに否定してるやつにそれ言っといて。
>>291
理解できない馬鹿に合わせて説明屋になるつもり無いから。
土俵にも立ててない事をまず恥じてから書いてほしいと言う嫌味だとまで言わないといかんの？
あのさ、みんなが努力して君の言いたいことを汲んでくれてるから話が成り立ってるんだぞ?
このスレに限らず、おそらくリアルでもそうだと思う。
皆がその努力を放棄したら本当に君は誰にも理解されなくなってしまう。
最低でもその努力に対する感謝だけは忘れちゃいけない。君のことを思って言ってるんだ。
ほんとそれ
本格運用するでもない、自作言語の字句解析や構文解析を自前で実装とか、ムダもいいとこ
そういうのは流行ってからやるもんだし
2つも駄レスしてる奴がそれ言う？
理解しようともせずヘイト感想文撒くぐらいなら、しっかり否定できる意見書けばいいじゃん
ま、>>287-288みたいな自己矛盾したレスしちゃう無能には無理かな？
少なくとも知識もない上、中身の伴わない批判しかしない単発の糞よりはマシだと思うわ
それはわかっとるよ。
語弊があったな。「自分が理解できない事を『理解できていない』と認識できない」と言うわ。
なぜ理解出来ないのかヒントでも出してくれんと、なんともしようがない。
自作言語で、新しい構文考えた時に、今まであった言語とは違う形でパースしたいとか、そういう事考えたら、パーサーは作ったほうがいいと思う。
行き着く先はどうせBNFと既存の色んなパーサジェネレータなんだろうけど、それが何故かを理解しないまま適当にパーサージェネレータ使うのは危ないと思うな。
まぁ、原動機の仕組みを知らんでも車には乗れると言えば言えるけど。
まるでヒントを貰ってないような書き込みはやめろや
ではー
二度と帰ってくるなよ
みんなもうさすがに分かったと思うけど
この「あ」って人の書き方、頭に入ってこない感じに既視感があると思ったら、一昔前の専門書の和訳だ。
自分の言葉で表現し直すか、元の英文を想像するかしないと理解できないところがそっくり
多分日本人なんだろうけど、どういうプロセスでそういう文章になるのかね？
しかもそれらが同一レベルで扱われてて
全体の流れが分からない、って感じか？
継ぎはぎだらけになって読みにくいとか
そういうことだと思う
それプラス、オブジェクト指向のやりすぎで
文章の流れがおろそかになってるとか
例えば
>負債作るだけだから実務では余程求められない限りやるべきでは無いけど。
だと、普通なら
>負債作るだけだから余程求められない限り実務ではやらない方がいいけど。
だろう
「実務では」の位置がおかしいのと、「べき」の後ろに「無い」の否定は読みにくい
そういうのの積み重ねで読みにくくなってる
馬鹿なのか？チョンか？ガイジか？
現役ニートはさすがだな
運動と瞑想すると軽減されるぞ
>>316
一歩間違うと読点過剰症候群に陥るんだよな
どうすれば改善するかダラダラ考えるより、改善は不可能って最初に書けばよい
もっと独自性出そうって思わないのかな？
みたいな発想だよな。
いい機会だからスレタイに入ってるやつ含めて、どれを次世代言語として想定してるか列挙したって。
まさか30年後には普及する、とか言わないよね
次世代IDEのモデルになってもおかしくない
影響を受けてるから全滅したわけじゃない
どの言語でどのアプリケーションをネタに教えるんだろうね。
Java→土方
PHP→ガイジ
JavaScript→土方
Pythonやろなぁ
高度なのは教師がついていけないし
独自の世界でだけ通用する
ガラパゴスなの嫌い
javaとかなったら泣くわ。
Goも特殊すぎてないし。
やっぱりPythonじゃないかな。海外じゃ教育用としても使われてるんでしょ？
丸投げの丸投げ
お前らいつも丸投げしてるな
我々は曲がりなりにもプロなわけだし、家庭教師や個人授業で誰でも稼げるようになる
しかも小学生やで
普通にScratchやって簡単なアルゴリズム作るまでで終わり
ヘビ嫌いの子がプログラミング嫌いになりかねない。
実際彼らが活躍するのはそれくらいだろうし。
義務教育として小学生がプログラミングを勉強する必要性って全くないよな
小学生の貴重な時間の無駄遣い
何がだいぶ違うの？
PC触れない機会なんて絶対無いんだからやるのはいいことだろ
メインは理論的な思考を養うことだろうけどな
必要性が無いに同意するわ
ソリティアとかフリーセルでいいじゃん
パズルゲームこそ論理そのものだと思う
プログラミングの勉強をするのとじゃ意味が違うよね？
理論的な思考は小学生なら算数を中心に他の教科で勉強した方がいいでしょ
図画工作で物理的なものを作ってたりしたほうがよっぽど脳が発達すると思うわ
あと、経済のことも全くやらないよね
で、結局、テレビで池上さんとかでしょ
どーなん
そういうのは教えてもいいかもね。
それくらいやってくれって思うこと多いし。
http://jp.techcrunch.com/2016/05/17/20160510please-dont-learn-to-code/
そのベースとなってる部分にあまり学術性が無いというか
例えば電気回路で言うところのオームの法則など
そういう学校で扱いやすい話題があまりない
疎結合やモジューラビリティー、テスト性とか
すぐにえらく専門的で現実的で「実技」な話に発展する
学校で扱いやすいのは、せいぜい論理演算などの離散数学ぐらいか
もともとやらせたいことを順番に並べて書いておけば
コンピュータが逐次実行してくれるってだけだし
そのような仕組み的概念など、一瞬で理解できてしまう
足し算よりも簡単な概念だ
ただし、コンピュータに、何を、どうやらせるか、の話になると難しいが
これは電子回路で言えば、理想素子など存在しない現実世界で
実際に回路を組む場合のノウハウの話であって、えらく専門的だ
それでも学校でプログラムをするなら
きっと目的に向けて手続きプランを立てる力を養うためなんだろう
例えば、もし音楽の授業が無ければ、俺は自分に才能が無いことに気づかず
ミュージシャンになりたいと思っていたかもしれないしな
そのような面はあるかもしれない、向き不向きがあるからな
特別に一回だけ教える
お前のレスは、このスレに不要
現状のって話だと動きが速くて教育内容がすぐ陳腐化してしまうんじゃないか
そうか？
アルゴリズムなんて数学に近いと思うが
明らかに素人の戯言すぎる…
アルゴリズム云々置いておいても、
形式言語とか式の簡約とか、もろにプログラミングそのものを扱ってる分野なんていくらでもあるのに…
マインクラフトそんなに面白いんか
＞コンピュータが逐次実行してくれるってだけだし
とりあえずこいつがコンピューター科学全く知らないで戯れ言ほざいてる下流コーダーなのはわかった
読書やゲームをするだけのために教師を雇う
この需要の乱高下が見苦しい
小学生や中学生が理解できるか？って部分が抜け落ちてる
論理演算などの離散数学ぐらいならまぁなんとか
それ以上は難しいだろう
お前にとって小中学生に理解できないことは「学術性がない」んだな
> 例えば電気回路で言うところのオームの法則など
> そういう学校で扱いやすい話題があまりない
の「学校」は小中学校を意味しているのは明らかだろ？
政府は国民を騙せなくなるから義務教育では教えないだろうな
義務教育で扱える程度の内容に乏しいって意味で「学術性がない」なんて強い語を使うなよ紛らわしいわ
歴史では昔の政府が国民を騙していたと教えてるんだろ
エビデンスを集めるのに数十年かかるようなので
エビデンス重視の教育では不確定な最新情報を教えるわけにはいかない
問題に直面したときに次の3つの意志が自然に芽生えるよう教育してもらいたい。
1. 問題を直列に分けて考えようとする意志
Aを解決するにはBが必要、BにはCが必要・・・と考えること。
2. 問題を分割統治して考えようとする意志
平行して解ける小問題に分けることと、それらを合成すること。
3. 問題を状態遷移の観点で考えようとする意志
こういう意志が自然に芽生える子は、
プログラミング以外でも問題解決能力が高いと思う。
機能や概念みたいなのって何よ
物理
心理
データ
メンテナンスしやすいコードが少ない労力で書けること？
でも、今の言語でも充分
メンテしやすいし、これ以上コードを書く労力を減らすなんて無理じゃない?
ほとんど（全く）コードを書かないで半自動でプログラミングするとかって次世代？
違うよ
最も大事な近代史を教えないのは
衆愚政治をしやすくするためだよ
CPUのシングルコア性能が頭打ちになって後はマルチコア化するしか無いから。
次はGPUを勝手に使ってくれる言語とかかね。
入力はクラウドからビッグデータ的なものとかランダムに垂れ流しに叩き込んで
そこから深層学習でパターン化できたものを
勝手にプログラム化するとか
次世代は不完全とか不完備とかいうのをやれば需要は確実にある
これを教えないからマスコミを使って簡単に騙すことができる。
えーと。失礼ながら深層学習のご経験は？
ちょっと深層学習組んだことのある人の発言には見えなかったもので……
直受けの50万 客：いつまでもうちにいていいよ
3次受けの50万（客は90万払ってる) 客：短期延長していい？
5次受けの50万（客は150万払ってる) 客：作り終わったらとっと出てけ できなかったら即退場だ
長時間労働 高稼働 高スキル要求が多い
フリーランスサイトを運営している零細ITの自称エージェントは労働市場から流れてくる案件を転売してるだけだった。
労働市場に加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×3 = 言い値50万以下
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×1 悪質な言い値で50万以下
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - JIETに加入して公表価格で応募できる
eJobgo JIET JISA で検索
優良エージェント・優良サイト
首都圏IT(PE-BANK) クラウドテック プログラマーズ
それなら都合の良い解釈で教えた方がいいだろ
江戸時代のミナトモノチンポコリンが紫式部とセックスしてひり出した国産みが、日本の始まりです。
君たちは十分勉強した。頑張った。
だから大学にいったらたくさん遊んで、頭クルッパーになるまで酒浴びて、友達とセックスして、
楽しい思い出たくさん作りましょう。
就職したら、よくわかんないけど税金と年金を払えば一生安泰。美しい日本をトラストミー。
これが中世ジャップランド土人村の教育方針。
そもそも、現代史の存在すら知らなくてよいのです。
異常な言動をするのは、想定外なことをやらないと陰謀を阻止できないという理由だね
その前に、次世代とは一体いつの事か、だろう
次世代はいつ到来するのか
到来しないなら意味が無い
来もしない架空の次世代を議論しているだけになる
かつて次世代言語と言われたD言語は普及する前に陳腐化して消えた
実際スレタイにもD言語は入ってないし、話題にも上がらない
例えば30年後じゃ遠すぎて議論する意味が無い
今現役の人は既に現場を退いているだろうし
今大学生で言語に興味がある人でも30年後じゃ50歳
30年後にメジャーになるなら25年後から学び始めても間に合う
今から30年前は1987年、30年は遠い
その前に30年後じゃスレタイに挙がってる言語も陳腐化しているかもしれない
なんで、次世代は5〜10年後が妥当だろう、と俺は思う
今ある言語で5〜10年後に普及してなかったら、その先もずっと普及しないんだろう
次世代とはいつの事なのか？
機能だけじゃなくて、ちゃんと時間軸があって
その中で流行り廃りがあってやってることだから
時間無視して機能だけ着目してもプランが見えないだろ
むしろ機能がどうであれ、5年後に普及している言語は
次世代言語と言えるだろう？正に一時代
当然今普及しているC#やC++だって貪欲に新しい機能を取り入れていくわけで
その中で5~10年後を目途に食い込んでいけるかどうかなんだよ
流行り廃りとかも関係無い
そう狭い視点で考えずにもっと広い視野をもった方がいいよ
次スレからスレタイにPython入れとけ
構うな、放置しろ
今度はコイツがここに居付こうとしてる
行列計算とかするときに勝手にクラウド経由で計算リソースを取ってこれるようになる。plan9ってそういうosだって聞いた。
明日から本気出す
ってやつ？
ドメイン毎に覚えなきゃならんのか
めんどくさい時代になりそうだな
「専業エンジニアでなくてもビジネスドメインの専門家自身で使いこなせる言語」のことな
言語そのものは汎用言語でも構わない
口語で伝えればそれでプログラム組んでくれるように成る
「この前教えた利子計算の方法あるでしょ？ それでこれ計算しといて」
「都会の中にワーゲンビートルの車表示して、太陽光は七夕の東京あたりの午前10時の薄曇りって感じで、街は勝手に作っといて、あ、車は運転下手なおばさん設定で」
とかね
「自然言語でプログラミング」このたかだか12文字で表現できる主張に、何行かけているのやら。
お前がやると簡単な集計のために一日中PCとおしゃべりしてそうだなw
今だって結局、現場ごとに複数言語覚えるんだから一緒だろ。
https://www.infoq.com/jp/news/2017/09/ceylon-joins-eclipse-foundation
単にプログラムを使ってるだけに思えるが
うーんそんなにコロコロ現場変わらんしな
なら次世代だろうと同じ言語でいいんでないの。
同じような仕事なら言語変える必要ないだろうし。
PHPみたいな冗長この上ない糞コードを永遠書く糞
>>408
適切な抽象化ができる糞
糞杉内
運動会の「プログラム」とコンピュータの「プログラム」は同じことだよ。
式次第。次こうしてその次はああして…とつらつら書いてある。
それにしたがって動くのが人かコンピューターかというだけの違い。
人とコンピュータには違った特徴があるけどね。
人は融通が利くがコンピュータは違う(厳密)とか、人は単純計算が遅いとか…
要するにお前も毎日会社で上司のいい加減なプログラムを柔軟に解釈して実行してる計算の遅い手足のついてるポンコツコンピュータみたいなもんだ。
現状はc#で充分だわ
ここに専用スレないし日本語の情報も少なくてまだマイナーだよね。Ceylon.
IntelliJ IDEAのKotlin に対抗するためにEclipse が動いたんじゃね？
式とお前さんが本来言いたい文じゃ、順序性の観点で全然違うんですが
最近この手の完全な門外漢がこのスレ出入りしまくってるのなんで？
どっかで流行ってるのこのスレ？
言語ではないかもだけど
次元が違うかな
GUIで
要は文字を使わなければいいと思ってるだろ
あとGPUみたいな回路にも文字がない
これこれのドット判定は信用が薄いからほにゃららの色に統一すべきとか
糞みたいな運用しだすだけだよｗ
コードで説明された方が分かりやすい場合も多いし
その時点で・・・
品質の面からみてもそうだし
再現性が無ければバグ取りも苦労するだろう
正確無慈悲なところがコンピュータの良さでもあるわけで
ビジュアルプログラミングのことだったか
それは言語というよりツールの話だね
大昔の話だけどね。
室町時代頃？
ちょｗｗｗ「式」次第だから式だと思ったってこと？
小学生かよw国語の勉強頑張れよー
プログラムでは式と文は厳密に区別するものだよ
勉強になったな生ゴミ
で？ｗｗｗ
>>415のどこに式と文について書いてあるの？ｗｗｗ
あれ？ｗもしかして「式」次第だから式だと思ったってこと？
小学生かよw国語の勉強頑張れよー
それを例えになってない例えにしてる時点で頭が悪いんだが、
まあそこは許してやろうか
演目を集めたものが式という解釈では、
プログラムとはプログラム次第であるとかいう頭の悪い主張になるけどいいのかな？
あ、もしかしてそれすら理解できない？
そもそも？ｗｗｗ
式と文はどうなったんでちゅかー？ｗｗｗ
>演目を集めたものが式という解釈では、
ん？ｗ誰がどこを解釈してそうなったのかな？ｗｗｗ
とりあえずどこを解釈したのか引用して示してみ？
小学生のくせに藁人形論法使ってごまかしにかかるとかｗｗｗ
純Lispの原理はシンプルで良いけど
CLの実装がいろいろ汚いんだよな
特にこのスレだしClojureでいいと思う
>>439
で結局語彙の乏しい雑な煽りには必死だが、何の説明と反論もできないと
お前病院でIQ測定して手帳もらってきた方がいいぞ、将来のためにも
>>407
それ、あんま良くわかってない(特に営業上がりの)PMがやってる事じゃない？
その下がPMの発言を汲み、そして纏まらなかったらメシ打ちで機嫌を取り、深堀してヒアリングさせて、なんとかごまかすという人間だけが出来る事をやって、
それでも死屍累々になる今よりもっと酷くなるかと。
最も重要なのは客の言葉よりもアーキテクトやエンジニア自身の経験や常識だ
人間も結局、事例を学習して継ぎ接ぎしてるだけだよ
そう考えると、それが機械に置き換わるのは案外夢物語ではないよ
継ぎ接ぎで解決する部分と、研開で本気でやらなきゃいかん部分がどーしても出てくるかと。
うちも知財部はチェックはしてくれるけど、明細書は自分で書かにゃならんし、継ぎ接ぎではやっぱ拒絶査定食らうし、弁理士の得意分野なら「新規性に疑問を持たれるのでもうちょい頑張って」って言われて知財部からかえってくるよ。
何の説明も反論も出来ていないとは、まさにお前のことだな。自己紹介乙。
>>415
>運動会の「プログラム」とコンピュータの「プログラム」は同じことだよ。
>式次第。次こうしてその次はああして…とつらつら書いてある。
に対しお前は
>>420と>>433で式だ文だとトンチンカンなことを言っているが、
一体>>415のどこに式と文に関する記述が出てくるのか、まず発端のそこを説明しろよ。
いくら聞いても
>>435、>>436と下手なごまかし藁人形捏造して逃げてばかり。
「式」次第だから式だと思ったってこと？小学生かよw国語の勉強頑張れよー
Win版はうざいけど
内部でモナドに変換してくれて解決してくれるようなんでいいから
人がそういうのをいちいち気にして
プログラミングしなきゃいけないってちょっと次世代的にダサくない？
もう少し語源に近づいて「(ある目的のために)予め書かれたもの(pro(羅pre 前以て)-gamme(羅gram 書く))」とすると、運動会のプログラムも電算機のプログラムも同じものなんだが。
書かれた順に行うからプログラムでも無いよ。
紅組優勝の場合は○○、とか、もっと言っちゃえば午前中に雨が降った場合、午後のこの演目は土が乾くまで他の演目を先に行う、なんてのも運動会のプログラム。
それを読んで行う>>415の半分は「スケジュール」。ジョブスケジューラがやるべき事。
それってHaskellの意味あるか？逆ならわかるけど
コンピュテーション式あるだろ
ずっとIOかStateの中に居ればいいと思うよ
do記法が副作用すなわち手続きを自動的にモナドに変換してくれるよ
型システムをいちいち気にしないやつはPythonを使えよ
どうでもいいがラテン語かね？
普通ラテン語で、書く、となるとscribo、（略）、、scriptumじゃね？
ごめん、思い切り間違えた。希だな。
そういうのを取っ払って使えるようにして欲しいのよ
型クラスとかdo記法も隠蔽してシステムの方で勝手に管理してくれればいいじゃん
railsみたく10倍開発スピード上がるって文句のフレームワークでないのかな。
個人的にはgolangのgoaがそれに匹敵する気がする。
webpaiに特化したフレームワークでswagger.jsonも吐いてくれる。
クライアントライブラリまで自動生成できる。
区別が付かないやつ多数発見
ある意味先祖返り的な感じだけど
分けることが意味が無い方向に進んでいくと思う
やりたいことを思いついたら、それでプログラム完了したと同じみたいな
それはもうプログラミングとは呼ばなくなるんだよ
すでに通ってきた道
作る事と使う事の境界線が時代とともに移動することはあっても
分ける事に意味が無くなることはない
概念に名前を付けるというのは分けることそのものだから
js界隈のFluxとか使い古しの技術の詰め合わせだし、disりの為の池沼、ガイジ、アスペらへんの言葉も同じ。
精神医学やら臨床心理学、障害者心理学やっても無いのになぁ、って思うわ。やった人間からすると。
使う人≒作る人だから
使う人≒作る人だって、言えばいいじゃない
ごまかしって、今お前がやってる下手くそな例えのポエムで自爆してる事？
文や式云々は確かに俺個人の解釈の一つだ
で、それで？
いつまでもまもな解釈を提示できない時点で、意味のないレスと自分で反復的に証明してる用なもんだぞ
ちゃんと理解できてるか？知恵遅れ
Javaのライブラリが使えるのが大きい
ClojureがLispの中で今一番流行してるのもそこ
関数型言語で開発効率は
言うほど上がらないよ
上がるならもっと採用されてる
知ってる。知ってるけど、知った上で鬱陶しく感じてるんや色々と
その言語を使いこなせるエンジニアだから開発効率が上がるのだ
流行に流されず手に馴染んだものを使いたまえ
言語の性質そのものが生産性を大きく向上させることはないのは同意するが、
その言語に習熟しているかどうかもそれほど重要ではない
最も重要なのは、学習コストを受け入れて生産性の向上を図ることのできるエンジニアは優秀なエンジニアである、ということだ
関数型は記号処理が中心なら簡潔に書けるが
ゲームみたいな
状態遷移が中心の開発対象に向かない
あとCRUDとか定型的なアプリなら
ライブラリやフレームワークの方が
生産性の要素として大きい
結果メジャーなOO言語の方が使いやすい
言語は変えてもせいぜい2倍程度だろう
だから言語の差は意味がないと考えられる
普及するのは入りやすくて変化の少ない言語だろ
なのでどっちみち生産性とか実用性は無視していいんじゃないか
これなー
別にC/C++で実行速度も解決できるしほぼなんでもできるからな
言語で何をするかが重要なのであって案の定スレ開いてみたら言語の欠点じゃなくわけのわからんこと抜かしてるし
多分こいつら下の階層のプログラマーじゃないだろ
めんごめんご
>>478
100倍は大げさ
機械語と高級言語だったら100倍ありそうだけど
アセンブリとCで10倍くらいかな
アセンブリとC++で20倍くらい？
java/kotlinなんか仮想化すんなら別に言語javaである必要はないしな
次世代取りたきゃandroidみたいにほぼ強制的にやらせればいい
このスレは終わりである
完
議論スレの終わりを初めてみた!!!!
次世代は
javaの進化系
スレ完
やめろ
＞今までにない要素ぶち込む
じゃVR/AR/MR or（amazon Echoみたいな）スピーカーデバイスだけで
プログラミングできる言語作れと？
確かに次世代っぽくはあるかもねｗ
例えば参照カウントが2以上なら例外を投げるだけの機能
Oculus買ったけど、Unityでアプリのウィンドウをキャプチャしたものを浮かべてたくさんの仮想ディスプレイのようにして遊んだけど楽しかった。NASA感ある。
でもキーボードとトラックボール以上の入力装置は無いな。空間をつかむって思ってるより難しかったわ。
でも何より熱いのと、その仮想ディスプレイを浮かべる部分作る作業は酔う。
タッチパネルの課題としても研究してる人いるけど
C++のラムダはしてないけど
C++だと結構ダイナミックに引数変更してくるし
関数型言語の計算モデルであるラムダ計算モデルを単純に実装すると、
常に(「関数」ではなく)クロージャがヒープ上へ動的に生成され、
最終的にガーベジコレクションによって回収される
これはSICP本にあるような初歩的な関数型言語インタプリタ実装や
初期のLISP処理系実装で見ることができる
で、現在の最適化技術が反映された関数型言語処理系では
「クロージャ変換」と呼ばれる技術が使われていて、
単に束縛変数(いわゆる関数の仮引数)だけを参照する関数は
手続き型言語と同様にスタック上へ引数が割り当てられ、
本当に必要な時しかヒープを消費しないよう設計されている
その概略はTiger本に解説がある
なお、Haskellのような純粋関数型言語では「ラムダリフティング」と
呼ばれる技術によってクロージャ変換と同様な最適化が実現されているらしいけど、
自分は知らない
知りたいことを過不足なく書いてくれた有能。感謝感激雨霰
ラムダを普通の関数として実装するくらいのこと、静的言語だったら必ずやってるよね
静的言語の場合は単にそう実装するのが自然だからそうしてるだけで、最適化でも何でもないな
その程度のことにわざわざかっこいい名前をつけなきゃいけないほど動的な関数型言語の最適化技術は貧弱なのかなと思ってしまった
静的解析時に自由変数の参照を発見したら例外として変数をヒープへリフティングする
名前を動的に解決する言語では、あえて静的解析を入れない限り基本的には常に自由変数の参照があると仮定する
という意識の違いがあるってことかな
動的型付けの言語は全部ゴミってもう証明済みだろ
俺の認識では動的な関数型言語って言ったらErlang,Lisp,Schemeを指すんだがそれのことを言ってんのか？
俺は話を動的型付け言語に限定してないぞ
名前解決を評価時に行う言語と考えてくれ
苦手や
ラムダをどう使いたいかの方が最適化では問題になるのでは？
インライン展開してしまうか、関数にするか、関数内関数にするかってことになるなら、関数ポインタとして呼びたいか条件分岐の方が良いのかとかそっちの観点が問題になるような。
それは石にもよって、armなんかだと再帰しないならインライン展開と条件実行の方が具合が良かったりすると思う。
レイヤの違う問題。誰もそんな話はしていない。
インライン展開するにしても、前のプロセスで自由変数に依存しないラムダについては独立した関数への変換を予め済ませておけば、
インライン展開は容易になるだろう。
ちょっと抽象的すぎんよぉ。Pythonとかか？それ
今わざわざunsignedにして1bit節約したい人はまずいない
20年後はchar?そんなのint(64bitだけど意識してない)でいいだろ？になるんじゃない？
「自由変数に依存していない」から、ラムダが変換出来る訳じゃないよ、って言ってんの。
レイヤの違う話ではなくて、地続きの話では？
その上、最適化と言う言葉は危険すぎると思うが。
jsもそうだな。関数型じゃないけど。
大雑把に書くと
所謂var bindingされる宣言を評価->所謂let bindingされる宣言を評価->実行
だからvar bindingされた名前は一番最初に見えてる。
やろうと思えばIRの変換で出来ることは実行前に(JIT使わずに)できる。
型情報がないから役に立つのか分からんが。
レイヤー次第だろうけどそれは無いと思う。
ネットワーク関連のバイナリプロトコルは思いっきりビット・バイト意識しまくりだし。
最適化しない動的言語のデバッグは容易な気がする
コンパイルしない言語のこと？
じゃあラムダが自由変数に依存してないのに独立した関数へ変換できないケース、
または、その変換を行うことにより最適化が適用しづらくなるケースの例を挙げてくれ
あDHDの主張はこのどちらかを反例として挙げることで裏付けられるというのが俺の理解だが、合ってるかな?
あと、自然言語で回答されても誰も理解できないと思うから必ず具体的なコードで頼む
こいつが言ってるのって、たぶん他の最適化如何でラムダ部分のコードそのものが変わるとか、そういう話じゃねえかな…
変換が何を指してるかは分からないから、完全否定はしないけど、反例の種類は対偶もあるだろよ
おまえら良くやるわ
でもたしかに自然言語で描かれるよりコードか数学記号で主張してるほうが読みやすそうｗｗ
例えば、ARMだとインライン展開してしまえばADDEQとかADDNEみたいな条件付き命令でループ中でもストールさせずに飛ばしたり出来ちゃう時とか。
関数にしてjmpすると効率悪いコードになる時。
最適化では。
>>526
コードは変わらんよ。
だからインライン展開は変換後でもできると何回言われたら理解するのか
Haskellの時に具体的に書いた結果無知を晒して大恥をかいたことがよほどトラウマになっているものと見える
モリカケ問題ばかりをやるきはないっていったそばから
モリカケ問題トーク始まったからなｗ
誤爆シマスタｗ
それは独立した関数が最適ではない、と言う話ではないか。
何が最適化なんだよ。
>>530
別に恥とは思っとらんよ。勉強にはなった。
しかし余程、自分は恥だと思うんだろうなぁ、他人に対してそういう風に「恥ずかしいに違いない」と断定的に言うところ見ると。
余程恥ずかしいな、その思考回路が。
ウダウダ言い訳してないで言われた通りコードで書けよ
いやあれは流石に恥ずかしすぎ。あれを恥ずかしいと思わない思考回路がまず恥ずかしい。
勉強になったとかじゃなくて、最低限の勉強すらせずしったかしてたのがバレただけだろ美化すんな
javaのGraal使って人間がハンドアセンブルしたマシン語をJITに使える新時代くるで。
いちいちjava bytecode生成しなくて済むよ。TruffleRubyが速い。
直行する問題だと言ってるんだよ
等価なものは同じものとして扱ったほうが最適化の実装は容易になるだろ
そーかー。
そら楽しかっただろうな、嗤うだけのお前はw
最適化の話は、話の発端>>502で、最初から言うとるぞ。
Haskellの件は擁護不可能だろ
こいつScalaとかOCamlとか関数型全般で知ったかしてたわけだし
間違ってたら正せば良いし、積極的に正されてるつもりだぞ。
「間違ってるウゥ！」って指差して笑い転げるのは中学生くらいで終わらせとけよ。。
ADDEQがどんな命令か知ってれば必要最低限のコードでは？
自分が何言ってるか考えてからレスしろ
オペコードはコードでない、と。
面白いな。
>>546
理解してないんじゃない。
着地点が定義されてない最適化なんぞ、どのレイヤであっても無意味。
末尾再帰を解釈できるコンパイラと関数呼び出しとしてしか解釈できないコンパイラの話をしないうちに、
ループの最適化の話しても無駄でしょ。
今の論点は、
・クロージャ変換によりガベージの増加を低減できる
・インライン展開により関数呼び出しのコスト低減を図ることも実行速度の向上には効果的である
・クロージャ変換を行うことによりインライン展開などのより低レベルな最適化が行えなくなることはない
・したがって、両者は直行する問題であり、それらを相反するものとするあDHDの懸念は誤りである
これでいいだろ？
嗤うだけっていうのはただのディスやね。決めつけはニート認定みたいで、頭悪そうなのでやめといたほうがいいと思うよ
少なくとも、めっちゃ読みづらい知ったかぶり長々書かれて全然楽しくなかったぞ
あの時からずっとおまえのレスは普通に邪魔
何事も負荷逆な操作をできるだけ後回しにするのは基本だよね
最適化知ったかぶりしてる奴って誰だよ
間違い自体は全然問題にされてなくて、Haskellの実装を知ってるとまで言っておきながら、その基本文法すらわかってなかった酷い知ったかぶりを責められてるのわかってる？
あんだけ散々ディスってたくせに知らんのんか〜いって思った
あれ以来、こいつは知ったかぶりする傾向があるから動くコード書くまで信頼出来んと思ってる
だがマクロよりインライン関数の方がすごいんだという謎のマウンティングが始まった
人にコードを見せる習慣がなくなったのはそういう歴史の影響があるんだろう
いやコンパイラに任せるより手動で最適化したほうが良いような実力者なら知らんけど
現金で買うのとカードで買うのはどちらが賢いかというのに似ている
いやすごいな。-O0でコンパイルして-O3並みの速度出せたりすんの？
俺みたいな速度最優先の少数派のことなんか考えてくれてないから自分でやるだけ。
詭弁もいいとこだな
どこがコードなんだよ
オペランドすら記述していない上に、
結局大部分を文章で説明している
それでも、すべて支離滅裂な文よりはいくらかマシだが
恣意的にレスしてるのがまるわかり
それともモナドとか分からなくてもそこそこ普通に使えて、しばらく使ってたらモナドとかも雰囲気でなんとなく分かってくるものなの？
YouTuberで圏論の勉強会ビデオ四回目まで見たけどなんとなく理解はできたの
結局のところ集合と関数をより抽象化して記号化していろいろやってるんだよね？
コンパイラもモナド則をチェックするわけでもないし。
モナドはわかったぞ。
ちょっとがんばっておぼえてみよーっと
ありがとー
それでちょびっとぐぐったらどうも関数型プログラミング言語はどれもマルチスレッドが得意らしいの
だからやっぱり関数型プログラミング言語が流行よね
そんな気がするの
ここにいるのって、どうせいつも同じ人間じゃね？
クロージャやモナドはパターンマッチができない構造なのに
えらい簡単に並列化出来るんだなって思った記憶ある
なんだっけなあのライブラリ
マルチスレッド派はガベコレ廃止してborrowチェックしないと
http://anopara.net/2017/09/16/kotlin%E3%81%AE%E6%B0%97%E3%81%AB%E5%85%A5%E3%82%89%E3%81%AA%E3%81%84%E3%81%A8%E3%81%93%E3%82%8D/
HaskellだとControl.Parallel.Strategiesを使うと
map関数が容易に並列化できてお手軽だった
ちゃんと使おうとするとWHNF(Week Head Normal Form)だとかの理解を要求されるので
そういう敷居の高さはあるけど
この人はScala大好きのようだが
同様に誰かにのScalaここが嫌だと言われそうなレベルの話で
ふーんでおしまいだなあ。
このラムダ式の凄さが分かって無いな。
ルビーでいうとブロックが何個でも持てるるのと同じことなのにな
どういうことだってばよ？
に言っている
javascriptのcallbackのfunction()という邪魔な奴が消えて見やすくなるということ
nullのくだりは全く同意できないな
そもそもScalaにnull safetyなんか無くね
c#のパターンマッチはまだ中途半端なのに、それに抜かれたとはヤバイな
inlineの方がいいのは型チェックあるからだろ
しかも、完全にじゃなくて殆どならなおさら。
型の意味わかってないだろ。
間違いやすくてかつ間違うと致命的なバグを生むからな
doubleとintの順番ミスったら大変だもんな
python3 の int と float をごっちゃにあえてしたのなんてありゃ失敗だろ。型を弱くしてどうすんだっていう。
たとえば？
座標とかはdoubleとdoubleだったりintとintだったりするだろ
それを間違える可能性まで網羅しないと致命的じゃないか
型システムに都合の良い範囲を想定してしまったらかえって想定外の盲点が増えてしまう
型システムがきちんとしてる言語であなたが考えてるような設計はしない
あとIntへの型変換はHaskellが一番ドイヒー
ソースの見通しが悪くなってバグの検出が難しくなる
phpStormとか使うとphpでも補完効きまくるようになるん？
10年以上Haskellメインで使ってますが、
あなたの言うIntへの型変換の「酷さ」が分かりません。
他言語と比べて何か問題あるのでしょうか。
Haskellメインの現場ってどういう環境です？研究職？
メインはホビーだろ
え？計算毎にいちいちNum経由にするのが酷くないって？
お前もしかしてHaskell使ったこと無いんじゃないの？
コンパイラとかの文字列処理や、モデルの妥当性検証とかに使うならまだしも、
数値計算でHaskellw
Repa位しか優位性ないだろ
Numは型ではなく型クラスです。
具体的には、どの型からInt型への変換が酷いのでしょうか。
Stream Fusion は働かないのでしょうか。
失礼、Stream Fusion と言うより、書き換え規則ですね。
書き換え規則が働けば、大抵の型変換は必要最小限のオーバーヘッドで行われる筈です。
Numが型だとも型クラスでないとも言ってないし、
Stream Fusionだろうと変換はいるけど？
お前さっきから何知ったかぶってるの？
「はずです」って、それ結局自分で書くだけだろ？
変換してそれをDoubleを使う関数にいれるパターンだよな。
オーバーロードはいいがオーバーライドは酷い
だがオーバーロードとオーバーライドを勘違いする非常識なやつもまだいっぱいいる
型が柔軟になればなるほど邪魔になる
ある型の値をInt型の値へ変換する際にあなたにとって酷いことが起きる、
あるいはあなたにとって酷いプログラムコードになる、という話ですよね。
>>609
Int型への変換の話の中で「Numを経由する」という言い方を聞いて、
あなたが Num を型だと勘違いしていると思いました。
大変失礼しました。
ある型の値をInt型の値へ変換する際は一度Num型クラスのインスタンス型の値へ変換し、
それを改めてInt型の値へ変換しないといけない、
あるいはそういう型が多い。
あなたはそう思っているのでしょうか。
もしそのような場合でも、私書き換え規則があれば経由しないようにできると私は言いました。
標準ライブラリの中で定義されている型で、
頻繁にInt型への変換が必要と思われる型に対しては、
書き換え規則がライブラリ内に書かれています。
自分で書く場合も一度書けば済むだけみます。
これが酷いのでしょうか。
改めて聞きますが、具体的にはどの型の値をInt型の値へ変換する際に、
Num型クラスのどの型の値を経由しなければならないのでしょうか。
>改めて聞きますが、具体的にはどの型の値をInt型の値へ変換する際に、
>Num型クラスのどの型の値を経由しなければならないのでしょうか。
だから全部自分で書いた話だろそれ
VanillaじゃIntとIntegerすら必要だろ
そんな事言ったら何らかの形で暗黙の型変換許してる言語全部そうだわ
お前マジで頭の病院行ったほうがいいんじゃねえの？
両方病院言ったほうがいいかも。
今ここで必要なのは法学部か文学部のような能力だという現実を受け入れろよ
Integer型の値をInt型へ変換する際に、
Num型クラスのどのインスタンス型にまず変換する必要があるのか、
その型を教えて頂けないでしょうか。
はあ？Int側にするならNum Integer経由だろ？
お前さっきから関係ない話ばっかりじゃねーか
書くまでもない気がするが一応な
https://ideone.com/MjF75Z
https://ideone.com/es7fao
上も下も非常に妥当な挙動に見えるんだけど、いったいどうなって欲しいんだ？
こいつIntegralをNumって言った事とっかかりに揚げ足取りしたいんだな
IntegralはReal通してNumのサブクラスですよクソ野郎
このクソ冗長なコードが妥当？w
これを解決するための機能まで作っておいて？w
fromIntegral 関数は、Integer型の値をInt型の値へ変換する際に、
どのような他の型へも変換しません。
経由しません。
Inreger型の値をInt型の値へ変換するのにNum Integer を経由、
という言い方がおかしいと思うのですが。
言葉遊びばかりだな
fromIntegralはfromIntegerを使う時点でNum経由
あといちいち俺が言っていないことさも言ったかのように決めつけて反論するの、やめてくれないかな？
チューンしたところでLL並の速度なのに何を躍起になってんだか…
このクソ野郎には適材適所という言葉を送りたい
fromIntegral = fromInteger . toInteger
Integer型の値からInt型の値への変換はどこも経由しません。
例えばWord型の値からInt型の値への変換は、
書き換え規則を働かせないようにわざわざすれば、
Integer型の値へ変換されてからInt型の値へ変換されます。
ですが、このような変換の書き換え規則を働かせないようにするメリットがありません。
初めから標準ライブラリに書かれていて、
プログラマは意識する事無くそれを使っているのだから。
ちなみに、私は>>627のコードが冗長だとは特に思わないです。
文字fromIntegralが長いと感じるのであれば、
fiにでも変えればいい話ですし。
そのほうが怖いわ
え、何？ まさかそこで暗黙の型変換して欲しいの？
だからそれfromInteger使ってんだろ
そしてIntとWordが例外なのに、さも他に定義されてるように言いやがるし
詭弁が多すぎ
あらゆる型で変換が必要だからおかしいんだよ
比較的面倒くさいOCamlでさえ1キャストで済む
他にも色々な型の書き換え規則が定義されています。
ここで全て挙げるのはさすがに勘弁してほしいので、
興味がおありなら標準ライブラリを調べてみてください。
いやお前が言い出したんだから、お前が挙げるんだよw
よくもまあこんな適当な事をw
http://hackage.haskell.org/package/base-4.10.0.0/docs/src/GHC.Real.html#line-442
浅学非才な俺には設計が悪いとしか思えないんだけど。どういう時に必要なんだ……
逆だぞ
そんな型揃えてまで速度欲しい具体的な演算を想定したら
Haskell自体を使わない
いや、速度関係なく、取り敢えず型は揃えとかない？
関数作る時にわざわざ一つの引数はIntegerで一つはIntとかせんだろ？
俺は大体全部Intで作ってるから、Integerは即Intにしてるわ。みたいな
そのファイルだけではなく、他にもあります。
grepかけてみてください。
おっと、型クラスへの罵倒はそこまでだ！
型とか、型クラスとか、
パブリック/プライベートとか
ポインタだとか
そういう言語側の都合を意識しちゃ
次世代言語として
ダメだと思うんだけどどう?
言語側が裏で判断して処理してくれればいいじゃん
A.I.でもディープラーニングでもなんでも使ってさ
ハスケルでもエリクサーでも
古いコンピュータ言語の慣習にとらわれてて
全然、次世代って感じしないじゃん
型がない言語って具体的に何？
危険な操作をできなくする方向で言語は進化してきているから
別に古い習慣とかじゃなく、そういう方向へ進化していくものだから
やりたいことが出来なくなっては意味が無いので
その辺の制約の付け方が次世代で評価されるポイント
変な現象を報告するだけの方向があるぞ
そして両者の存在を認める方向と、相手の存在を禁止する方向がある
マニュアル車より速くなったとき次世代だと思うな。
規則で禁止しまくった SIer の現状を見ろ。
そうじゃなくてより安全な方向を提示するほうが正しい。
2017年9月22日17:10 末岡洋子
https://mag.osdn.jp/17/09/22/171000
Swift 5の目標が確定、新たな発展プロセスを定義
https://www.infoq.com/jp/news/2017/09/swift-5-development-plan
多分PHPのことを言ってるんじゃないかな。
結局動的言語ってテンプレート文字列使ってプログラミングするのと変わんないんじゃないかと思う。
まだ言ってるよw
安全性としては進化しつつ、機能・機構としては複雑になったり踏切からの緊急脱出の手段を一つ捨てるといった退化してる。
結局、言語も何が正解かは使う人間と用途次第だろ。
「ポインタを捨てたりNullableとそうでない型すらもわけるのが正しい言語」「型なんて飾りです、キャストすりゃいいんです、電文？unionで解釈しましょう」みたいな言語が相容れうる訳がない。
傾向があって、その専用の構文では「それ」しか出来ない制限があることで
危険なことが出来なくなったり、読みやすくなったりしているのだから
次世代言語とはそういうものだろう
具体的に行こうぜ具体的に
それ自称シンプル言語()のGolangだろ
array、slice、map,chan。全てが専用構文
次世代言語は演算子もメソッド呼び出しだったりするから専用構文は少ないよ
http://www.nurs.or.jp/~ogochan/essay/archives/5033
HaskellとはバックエンドにLLVMあるんだけど、どうやって実装してるんだろ？
インタプリタで実装できるんだから、極端な話、インタプリタをそのまま埋め込んでしまえばいい。
それをいかに効率化するかは最適化次第だけど、基本的にはエミュレーションだよ。
CPU命令セットとの親和性の高い一部の低レベルな言語を除けば、
コンパイラというのは君が想像してるより非常に複雑でソースからかけ離れたコードを生成するもんなんだよ。
いやまあ、せやね。Haskell が吐くアセンブラ複雑すぎてビビったことあるわ
しっかしやっぱりインタプリタ埋め込みかあ。Haskellもそうしてるんだろうか？
あんまりイメージできないな。
JSをいくら最適化しても複雑なデータ構造はそのままだから
まだ仕変とかABIとか言ってるのかよこの言語。
いい加減枯れろよ
やっぱnullは便利
最近はクラスは使わないとか言われた時はビックリしたわ。割と好きだけどさ
テンプレートとオーバーロードの充実っぷりはC++の比じゃないし、プロパティあるし、UFCSある所とか好きだけど、演算子の定義を構造体中に書かないといけない所だけは解せない
llvmのレベルでクロージャー定義されたらつぶし効かなくなるだろ
llvmにそれを期待するのが間違ってる
期待はしてないぞ。ヒープに関数を展開する機能がないのに、どうやってヒープに関数を展開してるんだろう？って疑問を覚えているだけだぞ
llvmを持ち出す意味がわからん
cで実装されてる関数型言語はどうやってクロージャー実現してんだろ？とか
jitってどうやったら実現できんだろ？
という疑問の持ち方ならわかる
「Cで実装されてる関数型言語はどうやってクロージャを実装してるんだろう」でもほとんど同じ意味だけど、別にLLVMでもいいじゃん。俺がLLVMの方を意識してるからLLVMって書いてるだけだが
Jitの方はよくわからん。関数型言語一般でJit使ってるの？
class {
unsigned int eax;
...
void add();
...
}
みたいなアセンブラ実行クラス作ればできんじゃないの？
クロージャは環境を引数に取る関数として実装するのが普通だ
関数を100個作るやり方とは違うやり方がわかる
単なる疑問ということはわかった
物理cpuとそのabiを扱うことを前提にしてるllvmと
λ計算を理論的基礎にしてる関数型言語とでは
メモリモデルが全く違うんだからいきなりマッピングを考えるのは
無理があるとだけ
データは制御フローに影響を与えるし
制御フローはデータに影響を与える
このように双方が影響しあってプログラムが展開していく
(まるで電磁波のようだ)
この複雑性はソフトウェアが有用であり続けるためには仕方が無い
なので
・制御フローがデータに何か書き込むタイミング
・制御フローがデータを読み取って分岐するタイミング
の二つをトラップして言語やシステムで何かサポートしてやろう
というのが基本的な考え方なんだよ
エンコーディングに依存しないデータが欲しいです
ということだな。
俺の予測したとおり次世代言語は機械学習に最適化された言語ってことだな
相手にしてるお前なんなん？
恥ずかしいからやめて。
量子コンピュータの用途が何％機械学習を経由するであろうか、お前は全て見通しているとでもいうのか？
お前のその自己矛盾に気づかない頭の悪さよりよっぽどマシな発言だと思うが。
それくらいしか使いみちがないと思うんだが。
他の用途で使えるの？
単独の最適化問題って機械学習関係あるの?
処理速度が向上してうれしいだろ。
西洋人は機械学習を量子コンピューターでやっているようにしか見えないらしい
わからないなら真似しなければいいのに
量子力学上の理由で機械学習をやってるという設定で人の真似をするモンスターがいる
端末から2進数コンピューターのエミュレーションさせてそうｗ
そう簡単に移行できないね
そんなんじゃrustで発狂するぞ。
>>649
>パブリック/プライベートとか
カプセル化が幻想だっていい加減気付いてほしい。
有用なのも抽象データ型だけだし。
行きたいところがあれば大抵一人で行けるからみんなで移行はしないのであって
みんなで行けないから一人で行くのではない
> 有用なのも抽象データ型だけだし。
個人的にはデータと操作を一緒にして 型 としなくてもいいかもって思うことある。
でも複数のデータをまとめる機能とオーバーロード・ジェネリクス可能な関数、それと名前空間は欲しい。
それ以外の名前にするとデータと操作が一緒じゃない
これは幻想
抽象データタイプの値コンストラクタの引数は評価されなくてもサンクの為の
メモリーを消費するかな。
結論なんてないさ
結論がないということはどれでも一緒なんだろうという推理は微妙に間違っている
それは君の理解が浅いからだな。ばーか
線型時間スペースで不可能になりコードを生成に向かないジレンマなんだよな。
1レス内に意味の通じない言葉や理屈が複数あると突っ込むことも面倒臭いから、よっぽど親切な人に出会わないと自覚できない
人を怖がらせるのも自由意志ではなく信賞必罰か何かのルールに従っているだけ
逆にルールを破るのも他人が言ったことを鵜呑みにする形で破る
000-DOK<NAZE-0.8112162>
001-3800%\73NMB/1,81,2,NB"IKKI"%
002-91.81%ML7"8.122231746668193,43@ML.4@"%^23.1444
003-1.33321444718%"YLD""SO"%{71.%{62.1339816{331.422231765%<<<NL6
004-LOOP%Go To"000"%
VCL
C++みたいに複雑になり過ぎる
そういう所謂愚かな天才たちのお陰で今がある訳だが。
巡回やめ
ニュートン力学で十分なところを相対性理論だの量子力学だので解こうとするのは
高度なアプリケーションをマシン語で書くようなものでは
原理的には単一の言語で書けるというのと
実際にそれで書くというのは違う
あらゆる問題に対処できる言語になるんじゃないかな
要するに一次元のストリングスをパースする実行性の限界なんだよな。
文学だろうと心理学だろうと社会学だろうと記述しようとしているようなもんだよ。
どんな言語で書かれたライブラリもどんな言語からでも呼び出せる
ライブラリの標準フォーマットと仕組みを作ってほしい
そしたら言語のシェアなどもう気にする必要ない
たしかに統一ライブラリは必要だよね
Java のライブラリをC#で共用するのはうけるだろうか？
マクロとか許可すると意味不明なことになるから
でもそうなると言語自体の進化がしづらくなるかも？
映画メッセージの話みたいだな。
人間の認識能力を進化させて言語を+次元化するしかないな。
ところでUE4のブループリントって正直使いづらいんだけど
あれってメリットあんのかね。ビジュアルスクリプティングっていまいち
シンドいんだよなぁ。
普通にWebAPI経由でいいやん
MicroServiceも知らないのかい？
コンパイル済みのライブラリに言語の痕跡が残っているからライブラリも統一できない
言語違っても呼び出せる
プログラム言語の機械翻訳？
アラン・ケイがそんな研究してた
助成金が尽きてやめちゃったけど
言語自体にPEGベースの解析器生成器を組み込んで
既存の言語も含め、ドメインに適した言語を適宜構築・実行できるようにして
２万行でWindowsみたいなGUI OSを書けるようにするってやつ
STEPS プロジェクトご紹介
http://d.hatena.ne.jp/propella/touch/20091219/p1
STEPS プロジェクトご紹介その２
http://d.hatena.ne.jp/propella/touch/20111022/p1
PEGいいよね。PEG.js使ってるけど簡単に言語が作れそうな予感
独自HTMLモドキパーサー書いてつかってるわ。
ここまで予想できてたやつは頭良いな
http://clang.llvm.org/docs/BlockLanguageSpec.html
C言語にすらクロージャが導入されてるし。
あれはただの歯ブラシだけど、最高の歯ブラシだよ。歯を磨くことに関しては。
そういう比喩は結局なにに向いてるって言ってるのかわからんよね。
フレームワークを駆使するような規模のコードには合わないって言ってるのかな？
君はPHPのコンセプトは知ってるようだが、現実を知らんのだね
PHPは便器に突っ込まれた糞ブラシだよ
汚物まみれで害を撒き散らす
PHPのプロジェクトは例外なく糞まみれだった
糞みたいなプロジェクトに糞みたいな運用に糞みたいな技術者
今さらPHPを選ぶ奴は糞、センスないと言ってもいい
速度上がってから案件増えてるよ
PHPってjavaやC使うほどでもなく
ライトな技術で実装できるからPHPにしてるんでしょ？
やっぱペチパーって能なし脳なしセンスなし技術なしのガイジですわ
まぁ俺の関係のない最底辺の土方イット産業で
せいぜい糞ブラシで糞こねくりまわしとけや
>>766
いかにもロクに仕事もできない奴が言いそうな事だな
道具は時と場合で選ぶもんだぞ口だけの無能共
ペチパーに技術選定なんてできるわけないだろ
ペチパーはPHPしか知らないからPHPを選ぶんだよ
そして単価50万レベルの障害者を寄せ集めて
ヘビーな糞の山をこさえる
開発が糞まみれなら保守も運用も糞まみれ
そして障害者ペチパーは糞みたいな経歴書を元に
糞みたいな案件に流されていくこと糞のごとし
糞の輪廻転生
でたよ、ペチパー最後の砦だな
「道具は時と場合で選ぶ」
これ言ってりゃPHPでも正当化できると信じてる
糞ブラシを選ぶ時も場合もねえって言ってるんだよ、ガイジｗ
どう思いますか？（微笑）
じゃお前のおすすめの構成教えてよ
もちろんPHP並の安値で利益率も高い奴で
PHPしか書けない人に何いってもなぁ
ねえ、前世でどんな悪いことしたんだ？
糞ブラシで便器掃除の仕事しないと生きていけないって
かわいそう
はい逃げた
phpは確かに糞だが次世代言語に関係ねえだろ
はよ出せや
コテハンの数十倍うぜえ
PHP禁止
はよ出せ
ガガイのガイｗ
都合悪くなったら途端にレスを止めて単発IDで斜め上の話題そらし
次は匿名を理由にレッテル貼りかな？
小学生かよ
俺が出してんのは次世代言語の話題だぞ？
はよ出せやクズ
>>775
PHPでなく代替えの話なんだけど？
まさに次世代言語に相応しい話題だろ
http://mevius.2ch.net/test/read.cgi/tech/1506823587/
糞ﾜﾛﾋﾟｵ
まともに日本語も読めなかったのかな？
スレ移動しましょうよ、スレタイ嫁
いや次世代言語の代替えだせって真面目に言ってんだけど？
続きはこちら
自称次世代言語議論スレ[PHP PHP PHP] [無断転載禁止]©2ch.net
http://mevius.2ch.net/test/read.cgi/tech/1506823587/
盛り上げていきましょう！ｗ PHP！ｗ
>>786
スレ立てGJやで
ペチパーでもSlack作るような奴ののほうが
数百万倍価値がある
そのSlackのようなものを作った某ワークスは
PHPが糞だったからとんでもない損切りをせざるをえなかったのですがそれは
しかもSlackはPHPじゃないからね嘘までついちゃって必死だな糞ペチパーは
いやお前が逃げただけだろ？
てきとうなものつくるだけじゃ価値はないな。
保守し続けながら、アップデートしていくのが現代のソフトウェアの課題だから。
http://mevius.2ch.net/test/read.cgi/tech/1506823587/
PHPのホットな話題はこちらへ
はは、それ某ワークスの技術力が低いからだろw
その違いもわからんとかクサっ
自称次世代言語議論スレ[PHP PHP PHP] [無断転載禁止]©2ch.net
http://mevius.2ch.net/test/read.cgi/tech/1506823587/
PHPのホットな話題はこちらへ クサっ
代替
G unk0
頭おかしいんちゃうか
フレームワークが、Railsのパクリみたいな無理矢理他の思想を持ってきたようなものなら、合わないと思う。
>>761
汚物を汚物と認識して、一定の範囲で閉じ込めて使う分には全く問題ないよ。
歯ブラシで台所を磨こうとするからおかしくなる。
便利だし形が似てるから使うもんでもない。
プロジェクトが糞まみれだったなら、そりゃプロジェクトが悪いわ。おそらく、どこもかしこもphpで書いてあるようなプロジェクトだろうけど。
DBへのバッチをphpで書いてるプロジェクトはゴミだと思うが、DB周りはそれなりの言語で、画面だけphpとjQuery、なんて諦めがあって良いと思うよ。
DB周りがそれなりに強いと自分で言ってるのに何故DBバッチをPHPで書いてはいけないのか？
PHPの問題はペチパーのコーダーとしての品質の低さ。言語自体の問題ではない。
閉じ込めて使うべきというのは同意するが、それはペチパーの得意分野がフロントだから。
それ以外までペチパーに手を出させるとシステムの品質は著しく低下する。バッチをPHPで書いてはいけないのはそういうこと。
それなりの言語→PHPではなく他の言語
と置き換えれば矛盾はないな
でも単純に言語を置き換えても決して品質が向上することはない。
全てPHPで書かれてるプロジェクトの品質が低いのはコーダーの品質が低いから。あくまで人の能力の問題。
複数言語使って学習コスト上げるだけだよね、っていう
正直ダックタイピングの動的言語にインターフェースがある理由がよくわからん。
いや。まぁいいんだけど。
なんというかできないことが明確って結構重要だよね。
なんでもできる分、人によって全然やり方が変わる。
c++みたいな嫌な感じがする。
とGoをよく触るようになって思いました。
typescript「…」
ソースに型書かないなら結局ドキュメントに書くんだから
バッチとするには遅すぎるし、例外の扱いは適当だし、向いてない。
何より、仕様として180秒以上動いてれば殺すとかそういう設定項目がある時点で、あれはSSI用の言語。
向いてる向いてないを、コーダのせいにしてはいかん。
歯科衛生士を台所を歯ブラシで磨く名人にする必要は無い。
>>811
学習させなくてももう使える奴がいくらでも居るからな、phpは。
perl全盛の頃に、C組とperl組に別れてたようなもん。
>>812
よくわかる。
オブジェクト指向の半分くらい良さが無くなってるわ
ペチパーはドキュメントも書かないがなｗ
#pragma once
みたいに実装がどうなってんのか怪しいものより
インクルードガードのが俺は好きだけどね
いまいろいろみてたら
関数型リアクティブプログラミング言語Elm
こういうのあったの
2012年に生まれた言語みたい
これも次世代言語なの？
リアクティブプログラミングってすごいの？
Haskellの仲間なの？
ここは議論するスレなので、自分で調べて「自分の意見」が言えるようになってから、出直した方がいいと思います。
https://twitter.com/htmk73/status/914989085269168128
■専ブラ（２ちゃんねるブラウザ）からお〜ぷん２ちゃんねるを見るには？
【おーぷん２ちゃんねる】は全ての２ちゃんねるブラウザに標準対応してます。 ◆お〜ぷん２ちゃんねるボード一覧URL のボードを検索してください
●お勧めの広告なし2chブラウザ ついんてーる twintail の環境設定でお〜ぷん２ちゃんねるボードを入れるだけで使えます。
http://www.geocities.co.jp/SiliconValley/5459/
言語を名乗ること自体が冒涜の極みの存在Rust
react系というかreduxはそいつの影響
受けてるらしいよね。ということで潜在的な需要は高そう。
http://wolfbash.hateblo.jp/entry/2017/10/02/163017
ブロックコメントが入ったのも最近だろう。
スマポは1種類ではなくて左辺値みたいなスマポと右辺値みたいなスマポがある
否定はできないけどエコシステムを含めて評価して欲しいところ。
nim < Go が世間の評価なんだから自分の感覚がずれているということをわかってもらいたいな。
多分goが色々仕様が足りないようにみえるのは言語の再考だからだと思う
例えばclassって本当にいるのか？って考えてるのはすごいこと。
普通は皆つけちゃうよね。そこでclassを採用しなかった。
ジェネリクスも多分いちばんいい形で実装されると思う。
しかも新人かと思えばいい歳したオッサンとか、もう色々と終わっとる
多分いちばんいい形で評価されると思う。
動作もそこそこ速い
でも流行らないNim
とか書ける言語出ないかな
C#やKotlinやRubyでStringにメソッド生やせば普通にできる
a 500 :: varset
succ(x) x+1 :: def
みたいにひたすらこの形式のみにしたらどうかな、とか思った
だけど Smalltalk-80 以降は最新の Pharo、Squeak を含め Transcript show: 'Hello,world!' に
ただひとつ変わり種の GNU Smalltalk だけが今も変わらず 'Hello,world!' print
https://ideone.com/p1HVKw
でも今見直したらFactorも "Hello,world!" print だった
より純粋なオブジェクト指向とかスタック指向を目指すなら後置関数にこだわるのも良い気がする
"Hello, world!" |> println
とか行ける |> は左の引数を右の関数に適用する演算子
多分高階関数を気軽に扱える言語なら大体似たようなことができると思う
同意
いるってかくけれど、
にほんごだとAさんの後ろに自分がいてその後ろにCさんがいるのように自分中心
に書かないだろ。
これが日本人にオブジェクト指向があわない証拠だとおもうな。
単純に実行効率とメンテナンス性のバランスとるのが下手なだけ。
その点ではオブジェクト指向的な気がする
Lispみたいに前置にこだわった感じの関数型は英語的だと思う
10年かかると最初から思ってたら挫折もしない
やりたい事をやりたいように出来ればそれで良い気がする。
自動車整備の達人はレンチの達人かもしれんが、ただのレンチの達人は自動車整備出来んだろ。
新型のレンチ試して習得する前に、どう使うかを考えた方が余程良いかと思う。
javaのパラメトリック多相が複雑だからって後発言語ではin/outになったじゃん。
あれ思いついた奴は天才だろ
あれだけ意味不明だったJavaのワイルドカードが一瞬で誰でも一目で理解できるものになってしまった
https://qiita.com/koher/items/e4835bd429b88809ab33
nullがなくなろうと意味的なnullは必要なんだよ
だから絶対にそこにバグは入り込む
バグり方が変わるだけ
下手に動き続けるよりヌルポの瞬間に潔くクラッシュしてくれた方が
調査しやすいという考え方もある
意味的なnullを想定しない箇所については型でnull を弾くよう静的検査するべきということなんだが?
おれもあれば使う
が思うほど効果ない
結果的にここにnullの可能性がある変数が到達しないってことを言語として保証してくれるってすごすぎる。
書いてみると分かるけど返り値がnullの可能性があるかどうかは
内部で使うapiに依存してたりして、外側から見ると予測できない。
だから人間がやろうとしたら、結局使う側で全ての引数にnullチェック入れるしか無い。
まぁ面倒だからnullPointerExceptionを出しちゃうわけですけど。
コンパイラが把握してくれれは必要最低限のチェックで済むから精神衛生上も大変よろしい。
こういう進化はどんどんしていって欲しい。
必要性を感じるようなコードに出会ったことがないんだね、幸せなやつ
nullで落ちるならnullチェックすればいいというわけじゃない
レイヤーを下りれば結局人間が判断することになることが多い。
これ詳しく。typeScriptでジェネリクス使うようになった新参だからなんのことかわからん。
俺にはどーも単に他のバグ（？）と違いが分からない
意図通り書かれてないからバグ（？）るんであって
いつだって、書かれたとおりに動いてるだけのことであって
ググれ
その例外を処理する途中でバグるから他のバグよりも深刻
例外を投げない言語なら問題ない
interface Hoge<TIn, TOut> { convert(val: TIn): TOut; }
class B extends A { ... }
このとき、Hoge<A, B> のオブジェクトを Hoge<B, A> として扱っても理屈上問題ないはずだろ？
それを可能にするのがジェネリックの変性という概念。
ちょっと考えたら分かるはずだが、変性が適用できるのは型パラメータが入力または出力のどちらか一方にしか使われていない場合だけ。
さらに、型引数が入力と出力どちらであるかによって、変化の許される継承の方向が逆になることも分かるだろう。
C#では、interface Hoge<in A, out B> のように型パラメータの方向を限定してやることで変性を与えることができる。
これ Java だとHogeを使う側で Hoge<? extends A, ? super B> と書くんだけど、意味不明だろ？
C#では、interface Hoge<in TIn, out TOut>のように
ガビン・キングか誰かが同時期に+-考えて後にceylonに導入されてる。
>>864
あれは入力変数と出力変数と入出力変数
>>878
ムダに長いな。
いちばん重要なのはどの型変数が入力/出力用か定義した側は分かってるから
宣言部だけに書けばいいのにjavaの仕様だと利用する側も利用する型を
書かなきゃいけない無駄が無くなること。
javaも型推論の範囲広げてくれればダイヤモンド演算子で済むんだけど。
話は変わるけど「意味的なnull」の場合はnullable typeとoptionalどっちがいんだろうな。
optionalがモナドかどうかは抜きにして。
すまんいまいちわからん。
in outの指定がなくても推論できそうな気がするんだけど。
それがどう便利になるのか、、、、
推論のための情報を増せるってことかね。
コンパイラ側で実行時エラーが減らせるならそれに越したことはないと思うんだが。
特にコード書いてる最中に指摘してくれるから頭がいい人が隣に座ってくれてる感ある
この例え、ちょっとﾜﾛﾀ
全く違う。推論じゃなくて、Hoge<A, B>をHoge<B, A>にアップキャストできるってこと。
例えば型パラメータに応じたオブジェクトを作成して返すFactory<T>インターフェースがあったとして
Factory<DBConnection>型をパラメータとして要求するメソッドに対して
Factory<OracleDBConnection>オブジェクトを直接渡せるってことだ
型推論じゃなくて型パラメータの互換性までを考慮したアップキャスト
抽象度さがってるんだから、アップキャストじゃなくてダウンキャストじゃねーの？
よく考えろ
広げる方向へのキャストだよ
（単なるType **を）ダブルポインタ
（単なるポインタ型の値渡しを）ポインタ渡し
（謎の用語）アップキャスト
（謎の用語）ダウンキャストの飛び出して来ない世界に旅立ちたい
いかんのか？
やっぱ具体的なコードがないとよくわからんな
<T extends Hoge>XXX のHogeの部分を自由に指定できるようになるってこと？
class SuperY a where { fromY :: Y -> a }
Haskellなら単なる関数にするだろ
キャストという謎の用語を使う必要がない
い（ちごや、み）かんでしょ
あとJavaしか知らない人が背伸びしようとして？
（参照型変数の値渡しのことを）参照渡し
これもいつまでたっても無くならない
var f1: Factory<OracleDBConnection> = getOracleDBConnectionFactory();
var f2: Factory<DBConnection> = f1;
var conn: DBConnection = f1.create();
こういうこと
いちいち無駄な型パラメータを使う必要がない
訂正
3行目はf2
できねーよ。
>Factory<DBConnection>型をパラメータとして要求するメソッドに対して
>Factory<OracleDBConnection>オブジェクトを直接渡せるってことだ
>List<object>にList<string>を代入できる
これが出来るのはFactory<T>/Factory<U>やList<T>/List<U>が共変のときのみ。
それを緩めるのがjavaの上限境界ワイルドカード型。
>>898
それじゃモナドだろ。変性の話な。
変換の話ししてんのはID:Wf+VpSRVだけだから型変換は忘れろ。
おまえらPECS理解してなさすぎ。ポケモンで説明してやるよ。
List<? extends ゼニガメ>があった時このリストに入るのはゼニガメ、カメール、カメックス。これが上限境界ワイルドカード型。
set<T super ピクシー>(T value)というメソッドのときピクシー、ピッピ、ピィが入力できるんだよ。これが下限境界ワイルドカード型。
ValueT<?> value = foo.get<ポッポ>()とあった場合は?はポッポに変身したメタモン。これが非境界ワイルドカード型。
ただし、非境界ワイルドカード型はjavaの場合は型消去されてすべての型のsuper typeを表すObject型になる。つまりに何にも変身してないメタモンのまま。
これはjavaがnone-reifiableだからでreifiableな言語ならポッポに変身したメタモンならポッポのまま。
O non-
それをC#だとキャストできるという話なんだが、頭おかしいのか？
ちなみにKotlinだと型定義時の指定と型使用時の指定の両方をサポートしてたりする
TypeScriptの場合はキャストが完全なstructual-subtypingベースで、型名やジェネリックは型定義のエイリアスに過ぎない
だから特に変成を明示的に指定する必要はない
Go「templateやめた」
Haskell「仮想関数やめた」
Java「直交やめた」
>だから特に変成を明示的に指定する必要はない
TypeScriptの場合は必要ないと言うより、個々に指定できないから固定ルールでごまかしてるってのが近いと思うが。
擬人化だけならいいが擬人化してから罪悪感を植えつけるのは科学ではない
政治に近い
この文脈で脈絡のないモナドとか出してる時点で
いつもの知ったかぶり野郎ってわかんだね
structural subtypingあるのにできないって、随分中途半端な言語なんだな
言語は決めたがコードは書けない無駄な状態ができるだけだから
決められない状態の次の瞬間に書き終えるのが正しい
ポエムかよw
T extends Foo
U super Bar
だと人間がその型変数が入力用か出力用かわかりづらいからin/outの方がわかりやすいって言ってるだけ。
>>903
キャストじゃないって言ってるだろ。
mapとlistの区別もできないガイジ
年上に敬語使いたくなくなったの初めてだわ
あったのは数値インデックスをキーとするマップだった。
でもPHP7からまともになったと噂で聞いたがどうなんだい？
ウンコにカレーかけたらカレーになるか？
そういうことだ
知ってりゃ知ってる程度の話で
ただやった事あるかないかの差だろう
やればすぐに覚える
その程度で上になった気になってマウント取れる頭が羨ましいわ
だからC#ではキャストなんだよ
知らないなら黙ってろよ
まぁ、逆にそういう基礎的なことを知らない時点で他も推して知るべしってなってイライラする気持ちもわかる。
多分、色々あったんだよ
若者にバカにされたくなかったら勉強を怠るなということさ
他人であれば敬語以外の選択肢が出てくる時点で異常。
上司であれ部下であれ、客であれ飼い主であれ、友達じゃねえんだから。
ほんとにドヤ顔したいなら、理解させたら良いのに。
理解させる事が出来ないなら、そいつ以下な気がするわ。
少なくともそいつより賢くないとできない事が、そいつに教えるって事なんだし。
ブラックジャックのように報酬はいくらでも出すと言わせるのが難しい
教えるって直接何かを伝える以外にも色々あるじゃん。覚えなきゃ切るって言ったり何でも。
それなら賢くなくても出来るか。
C#でも同じだバカ。
パラメタ型がキャストできたら型引数が部分多相になるだろうが。
おまえが代入互換性とキャストの区別もついてないだけなんだよ。
今巷にあるテストのないコード見てるとそれが良くわかる。
メンテしやすいかどうかは言語機能とは無関係なことが多い。
いいから具体的なC#コードで説明してくれ
んで、全部Cにロジック書いてそう
やっぱMVVMが主流？
適用対象が違う
構ってちゃんにまともに取り合おうとするな
正義なら古くてもそのまま
これだけの話なのに
おそらく正義か悪かを判断したくないから、新しいか古いかだけで決めようとするんだろ
悪は悪だが必要悪だとか、悪は悪だがそれを避けるコストが、我慢して使うコストを圧倒的に上回ってるとか。
ちょっと前の話なら、ClassicASPを嗤ってた割に、SSRとか言ってはしゃいでた奴とかいたが、心底アホなんだなぁって思ったよ。
とか言ってる連中ってマジで頭おかしいんちゃうか
あまりのレベルの低さに草も生えない
割と色んなものに当てはまると思うよ。
できればもう書きたくないけどプロジェクトは大規模だし、改修範囲は把握してるし、
動作環境も固定されてるとある機械の制御端末なので、VB6のプログラム改修してパッチ出します、とか真顔でやってるプロジェクトある。
よーやるわ、と思うが。
>>942
建設的にやれば？
JavaScriptはしょうがないにしても、今どきPHPを積極的に採用する理由が見当たらない
WordpressつこてるならPHP以外ないだろ
というかむしろWordpressとECぐらいしか新規案件見ない
そういうことか。
古いjavaならoracleがAPIを削除し始めたから、
そのうち強制移行だろうけどイントラネットみたいなところで生き続けて、
言語仕様の進化から取り残されるんだろうな。
VMレベルで互換性失うのはまだ先だろうけど。
javascriptはしょうがないで書くような言語でも無いかと。
よくできてると思うよ。
上からまっすぐ降りてくる言語しかできん奴はjs嫌いだろうけど。
型が柔軟なのも良いけどな。なんでも突っ込むのは頭おかしいが、代数的データ型として使う分には良い具合の無茶が出来る。awaitが使えるようになって、ますます良い具合。
phpは置けば動くあの簡単さが良いんだろ、多分。
よくわからんモノシリックFWに、低単価で寄せ集められたクズどもがどうしようもないゴミ山こさえて
どうにかこうにかまともな風に仕立て上げた頃に、新任のCTO就任
早々に言い出したのが「こんなレガシーではいけない！次は・・・Symfonyだ！」
あっという間にみんな撤退したよ
一応未だに企業は残ってるから、あれを保守して何とかやってるんだろうな
Symfonyエンジニアも絶賛募集してるから、レガシーからレガシーへの移行も諦めてないんだろう
あんなゴミでも営業や企画次第で優秀な金儲けの道具になるんだから
エンジニアリングって何だろう、って切なくなる思うことがあるよ
ASP生きてる会社もあるよ、聞いた所だと。
純然たるソフト屋なら対策するだろうけど、製造業やら医療のシステムってたとえイントラでもすぐにスクラッチで作れるもんじゃないしね。台帳保存の法規制とか諸々含め。
windows7のVDI環境もあるし、IEのエンタープライズモードもあるし、多分使わなくなっても5年は動態保存してる。
よほどのレガシー以外で普通に生き残ってるのは
それなりに理由がある。
すぐ優劣みたく言う人はスキル低そうとしか思わんな
自力で読み書きするなら何の問題もない
>>954
未だにCOBOLの求人あるぐらいだから"余程"じゃないなｗ
俺なんかは言語機能はさほど求めない方だけれど、
さすがに構造体みたいなデータをまとめるものは必要じゃないですかね。。
流行り廃りはランダムではないよ
ほとんどが静的型と動的型が原因だよ
basicが廃れてC/C++が残った原因
Lisperがリストばかり使ってタプルや構造体を使わない原因
動的型に近い性質をもつ継承やvirtualが排除されるかもしれない原因
PHP+静的型というのも悪くない気がする。
型なんて概念理解できるわけないだろ！いい加減にしろ！
それがlispのタプルかな
自称次世代さんたちはこれに何て返す？
でもペチパーは馬鹿だから奴隷のように安い単価で連れてこれますよ
2個組みならドット対、3個組みならドット対のcdrにドット対入れたものになって、あと4個以上もその繰り返し
表記的には全部ドット対にしてもリストの末尾だけドット対でもどっちでもいいが
あー。そういやそんなんあったな
ヴァカのプェチプヮーでも出来る内容ならプェチプヮーにやらしとけば良くね！？
いまだにﾍﾟﾁﾊﾟｰﾍﾟﾁﾊﾟｰ言ってる連中はどんだけﾍﾟﾁﾊﾟｰに恋い焦がれてるんだよ･･･
最初からただの荒らしだっただろ
まともに内容に触れてもないし
自分が勉強した言語より重宝されてて悔しいとか、
会社で自分が言ったことが通らずPHPが採用されたとかそういうつまらん理由だろ、あいつは。
PHPに関わった者はみんな不幸になる例
文字列処理は敵だよ
始まってもいない
割と先進的な機能が入ってるみたい。
あと一般の多次元配列とか考えると結局データベースになるっつー話もある。
そういう意味では統計扱う言語(R,python)は DataFrame とか用意してはいるな。
Racket、Clojureも全くできないわけではない
次世代言語Part7[Go Rust Swift Kotlin TypeScript]
http://mevius.5ch.net/test/read.cgi/tech/1508403098/
新しいスレッドを立ててください。
life time: 51日 23時間 51分 31秒
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 【滋賀】いなり寿司を万引きしたとして誤認逮捕され、82時間拘束された女性、涙ながらに苦しい胸の内を明かす… ★3 [Hitzeschleier★]
- 【サッカー】U-23日本代表、UAE代表に完封勝ちで2連勝！日韓戦を前に決勝トーナメント進出を決める [久太郎★]
- ロシア出身YouTuber、経済的困窮で「国ガチャ失敗」？嘆く日本人を一喝「給料13万？自分のせいやん」日本を「大当たり」とする理由は [muffin★]
- 【理研】日本人の祖先は「縄文系」「関西系」「東北系」の３系統か、ゲノム分析で従来の説「縄文と弥生」に疑問 ★2 [樽悶★]
- 築地市場跡地に5万人規模スタジアム建設へ 事業者は三井不動産など ★２ [ぐれ★]
- 大谷翔平を〝見誤った〟北村弁護士が謝罪「大嘘つきにだまされた自分を恥じております」 [muffin★]
- 【実況】博衣こよりがえちえちplate up🧪★5
- 【実況】博衣こよりがえちえちplate up🧪★4
- 【実況】博衣こよりがえちえちplate up🧪★6
- お前ら今何色のパンツ履いてるの
- なんかiwaraずっと重くね？
- 今からすき家の牛丼をキメちゃって良い？