次世代言語議論スレ[Rust Kotlin Haskell]第6世代 [無断転載禁止]©2ch.net YouTube動画>6本 ->画像>2枚

※前スレ
次世代言語議論スレ[Go Rust Scala Haskell]第5世代
http://mevius.2ch.net/test/read.cgi/tech/1497311647/

Goどこいった

Goは次世代じゃないのでｗ

Scalaは文字数の関係で消した
Kotlinがあるしまあええやろ

やったぜｗ

Haskellが残ってるとか

宛らHaskellオナニー会場だな。

あ、Haskellのこと何も知らなかった奴がHaskell攻撃してるｗ

屁臭いペチプァは死ね
臭いがうつるから寄ってくるなガイジが

Goはな、一瞬 勢いはあったからこれは結構伸びるなって思ってたけど、本当にどこいったの？

Go消されてて笑った

GoはGoogle開発じゃなかったら
見向きもされてなかったな
SwiftもAppleじゃなかったら

>>8
古い状態しか知らなかったのは認めるが、Haskellを攻撃してるんじゃないぞ。
Haskell信者に、オナニーすんなよって牽制してるだけ。

>>10
>>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 信者牽制しようとか草草草ァ！！！！！

>>15
余程Haskell好きなんだね。
そりゃ永遠の次世代に相応しいのかもしれんな。

Go消すなや。言語としては素朴だがエコシステムは他の言語でも取り入れてほしい部分が多いぞ。

Haskell推したくて仕方ないんでしょw
わざわざScala落としてるし。

しかし、Haskellなプロジェクト聞かんなぁ。グループ社内にも稼働してるプロジェクトなさげ。
どこでどう使ってるんだろう？

まあ、知識無いのはそうなんだろう。本気で使った事は無いし。
アンチ的な意味ではなくて、実用例知りたい。
信者なら信奉してる凄いコードとかプロダクトあるだろうに。
無いから次世代だって訳でも無いだろうしね

あんな間違いするとか書いたことすら無いんだよなあ

次世代言語ってのは出た時期じゃなくて言語の機能だぞ
Goは全然次世代言語じゃない

スレチかもしれませんが質問です。
爆サイというサイトで「なりすまし防止」でパスワードを入れたんですが、解析されて同じトリップを相手に使用されました。
気持ち悪くて怖くなり、それ以来やっていません。
62^4＝14776336通りもあるパスワードをどうやって解析したんでしょうか？
もし解析ができるなら、やり方までは聞きません。
解析ができるのかできないのかを知りたいです。お願いします。

これまでのスレチシリーズのなかでもトップクラスのスレチじゃね？

40bit(2^40≒1兆通り)暗号化が
総当たり攻撃であっという間に陥落するご時世ですが、何か？

スレチどころかマルチポストだぞ
あちこちに貼りまくってる

どうしてハスケラーってメンヘラばかりなの？

あれ？煽りは書けるのにプロダクトは出てこないんだ？

>>23
つまり、ここ2ちゃんのトリップも簡単に該当できるということでしょうか？
>>24
すみません。
ここと合わせて3ヵ所に書きました。
どこのカテゴリーで尋ねればよろしいでしょうか？

前スレでも書いたけど、うちの会社はネットワークインフラをdotで書くんだけど、それが論理矛盾してないかを確かめるツールはHaskellで書いてあるよ

>>27
DeepLaningでお前の書き込みから逆アセで住所特定したわ
震えて眠れよ

>>12
redhatに支援されてるのに泣かず飛ばすの
ceylonに謝れ！

>>29
そうなんですか。凄い詳しいんですね。ありがとうございます。
私みたいなクズ人間の住所を知られて、お伺いしてもらってもかまいません。
オフ会でもしますか？

>>31
きも

>>32
textPlusってアプリ入れてますか？
お電話します？
タダでは申し訳ないので、色々と教えていただけましたら、お礼はいたします。

>>29のレスを見事にボケ重ねで潰した来た格好

IP変えてマジビビりしてる雑魚ｗｗ

>>35
なにもしてないですよ？

>>20
機能かなぁ。
むしろポリシーとか思想とかそっちじゃない？
機能だとしても、温故知新でより整理されたのであれば必ずしも新しなくてもいいと思う。

おれも思想とかポリシーのが重要だと思う。
糞機能をなるべく排除した方がよいというのはとても前向きな発想。

>>20
時期じゃなくて機能で語れば
今でもPrologは次世代言語

prologの機能は有用だがyaccのような小物感しかない

>>39
そうだよ

次スレは実用言語のKotlin外してprolog入れようぜ

>>38
まさにこれ。 Goは引き算の美学がある。

* publicとかprivateとか本当に識別子として必用？削ろうぜ。
* classとstructって本当に両方必用？ structだけにちゃうぜ
* 構文規約、言語側で決めちゃうんで問答無用で従ってね。
* パッケージ管理っている？ 直接import文にgithubのurl使っちゃおうぜ。（最高!）

>>43 ruby から似たような匂いを感じる。

>>44
それはあるのかもしれない。

まつもとゆきひろの 言語のしくみ を読んでるけどそんな感じはする。
rubyの作者が作ってる言語streemも気になる。
言語としてRxの全てはストリーム。を体現する言語になるんだろうか。

>>43
引き算は使いやすくなる範囲でなら良い
Lispみたいに極端に単純化し過ぎて
可読性下げなければ

>>43
ギフハフが死んだらどうすんだろ

>>47
別にgithubではなくても、リポジトリ作れるし取ってこれるよ。
逆に、フォークするのがめんどいと問題になるぐらい。

まるでLispの可読性が低いかのような書き込みはやめ給へ

)))))))))

エディタが括弧ハイライトしてくれるし、)))))が読みにくいと感じたことはない。
いやメモ帳で書いてるんなら確かに読みにくいと思うけど

>>46
lisp つっても common lisp と scheme だとだいぶ違うけどね。
common lisp はだいぶ残してる方だよ。

>>43
リスト操作をforで書かせる言語のどこが引き算の美学？

goはまともにリスト扱えるようにしてから出なおして来い

>>53
forと言う単語に引きずられてるのでは？
チャンネルが尽きるまで、がforで書ける。
シーケンシャルに舐めるのであれば、バッファのあるチャンネルが実質、リストとして使うに充分。
マップでも同じ構文で書けるけど、キーでアクセスしない、Enumerator的なものは充分にチャンネルで捌ける。
かつ、そうしとくと入れる方も出す方も両方goroutineにできるので、思ってるより色々シンプルに片付くよ。

>>49
>>51
Lispは可読性の低さが普及しない原因

>>52
CLでも大差ないと思う

Clojureまで行って少し可読性
上がったかなっていう程度

>>56
具体的にどのあたりが読みにくい？
確かに視認性はよくないなと思うことはあって
エディタの助けがかなり必要だとは思うけど。

>>56
>Lispは可読性の低さが普及しない原因

そこまで断定的に書くってことはなんかエビデンスあんの？

こうなってくると未だに現役バリバリなC言語って凄くね？
適当なメモリブロックを適当な型に適当にキャストするだけで
配列としてアクセス出来たり、構造体としてアクセス出来たり
世の中には、こんな基本的な事すら出来ない言語もあるようだし

どんな言語だってヘボの目には可読性が悪い言語に見える。
エビデンスは>>56。

clojureの記号が読みやすいと思う奴居るんだ。
あれクソ構文だと思ってた。

Lisp族読みにくいって主張してる奴の中で、エアプじゃない奴ってどれくらいだ？

Lispって（）使いまくりなんだろ。だから可読性低いってイメージ
使ったことはないが。

>>44
rubyは足し算の醜学だろ一緒にすんな！
map/reduce, collect/inject これすらまとめられません笑
関数、ブロック、プロック、え？ラムダが流行りだって？じゃそれも笑
思想がないからあれもできるようにしましたこれもできるようにしましたで何一つまとめられません涙
goと真逆じゃねーか何でもかんでも未整理にぶっ混みやがって思想もへったくれもあるかあんなゴミ。
言い過ぎたがgoの引き算にすり寄っていい言語じゃないことは確かだろ

いやはや、いつもこのスレはゴミが集まってんねー

エビデンスのエクセルにはきちんと表紙に承認印をもらってから提出しなさい。

インデントしなきゃどんな言語も可読性悪いし、すればlispだって読めるだろ
普及期にC言語が一番使われてたからそれに似た言語が一番読みやすい人が多いってことだろ

それでもCライクな文法が一番流行ってるのは
それが読みやすさの本質を持ってるからだろ

ペェ～ルとかルビー（藁）とかさぁ・・・なんだい、あのゴミは

ブロックインデントの方が読み易いしC言語のように括弧を多用する言語は読み難いと思う

ブロックインデントってBNFとかで表現するときどうするんだろう
yaccとかに食わせられるんかね、良く知らんが

可読性が… みたいな事言ってる人はどうやってソース読んでるんだろ

まさかソースを(白黒)印刷して読んでるわけではあるまい？

英語と日本語と中国語どれが読みやすいかと同じじゃね？

漢字のような表意文字は抽象度が高く、短い語数で意味が凝縮されるから可読性は高まる
でも中国語のように英数字以外がすべて漢字になると、区切りや各単語の軽重が分かりにくく可読性が下がる面もある
ということで日本語は優れてると思うけど結局は慣れの問題が一番大きい

それ言ったら英語なんか動詞で文全体の構造が決まる言語だからな
基本五文型とか初めて習ったときは意味不明だったよ
日本語には無い考え方だ
着目している部分が全然違ってて流石だなとしか言いようがない

もっと言えば英語のような言語は構造重視、関係性重視の言語だと思うし
日本語のように述語が最後に来る形式は時系列重視の言語だと思う

あと、a とか the とかもマジ意味不明で
そんなもの無くても会話は成立するのになんでって感じだし
日本語には全くない感覚だからな
あるカテゴリーの中の一つ、とか、固有名詞、とか、えらく数学的で
普段からそんなこと考えながら会話してんのかよマジ半端ネーナって感じ
文法の中にそんなものを持ち込むこと自体が凄いし
言語が自然発生的に出来上がったのだとすると、脳の構造違いすぎるでしょ
世の中のことをそういうベン図みたいな捉え方するのが彼らの日常ってことだからな

a * (b * c) = (a * b) * c (可読性高)

(= (* a (* b c)) (* (* a b) c)) (中)

a.mul(b.mul(c)).eq(a.mul(b).mul(c)) (低)

(中)と(低)の括弧の数は同じ

RISCとCISCの違いだろ
つまり表示デバイスや読む人の能力によると

>>76
お前の表示デバイスだと>>75が違って見えるの？
頭おかしいな

>>74
意外に日本語では修飾語使うしかないシーンでも端的に話せるから便利だよ。
ラテン語ぐらい活用があればホントに単語に主語すら含まれてるから文章の密度が濃くできる。
aや数詞とtheは、日本語でも知らず知らずのうちに使ってるよ。

>>75
まともなlisp書くやつは、可読性中とやらみたいなの書かんだろ。
(= (* b c a)
　 (* a b c)
)
みたいになるんでないの？

>>77
表示可能な文字数が少なかったりプリンタだったりしたらRISCの方が効率いいだろ
お前が書く全てのプログラムは>>75程度なのか?
それともお前の頭がおかしいのか?

CISCの方が

PEG.jsつかえば俺言語が簡単に作れる。
jsの処理系使ってaltJS作るのに最適かもしれない。
こういうの触るとLISPってまんま構文木を言語と対応させたもんって感じ。

>>57
括弧が多いこと以外にも
JavaやRubyみたいな
ふつうの言語の文法と違いが
大きいところが読み書きしにくい

たとえば代入は＝じゃなくてsetqとか

それは最初に慣れた言語がそうだったからというだけでは
たまに初心者がなんでイコールが代入なの言うけど確かになが

C系の文法ばっかりになったのは個性が薄い感じがして寂しい
という漏れもそうじゃない文法を自分で書きたくはないけどねｗ

>>83
setqはset quoteに展開されるマクロで、setも関数。
ただの代入の構文ではない。
すべて式、みたいな流行りの言語のように、すべてリストで、リストの先頭を関数として解釈しとるだけ。

>>85
OOPは言語レベルでサポートされていなければならないってC++の作者が力説したから
これは文法とパラダイムは無関係という説を否定したようなもので
同じパラダイムをサポートするなら文法もほぼ同じになると考えられる

そんなこと言うとまたSmalltalkerが湧き出してくるぞ

>>72
a→具体的な意味を持たない。ok?
鋭→具体的な意味を持つ。まだ大丈夫？
具体的の反対は何か分かるかな？
分かんないか、ごめんね。正解は「抽象的」
漢字のような表意「文字」が(アルファベットのような表音「文字」と比べて)抽象度が高いなんてことはあり得るのかな？お母さんに聞いてみようね！

俺もそれは気になってたけど指摘しなかった
漢字を抽象度が高いというのは何か違うと思った

重要なのは意味とか音とか二つ以上の部品に分解することだよ
それらは対等に扱った方が対称性が高い
どっちが高レベルでどっちが低レベルかという問題にこだわるのは対称性が低い

>>89
「抽象度」という概念を知らないのね

1. x^100 + 9x^7 - 3x^2
2. x to the hundred plus nine x to the seventh minus three x squared.

「どっちが抽象度が高い？」と言うのと
「どっちがより具体的な意味を持つ(もしくは持たない)？」と言うのとは意味が違うんだよ

まぁつまり、読みやすさ・機能・シェア・WORA、すべてを兼ね備えたコットィンが最強ということだね

>>92
その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 はそれに対して 答えてるだけだと思うの。
そしてそれは 普遍的に決まるので正しいと思うの。

>>94
“アラビア数字、その他の数学記号は、代表的な表意文字である”
https://ja.wikipedia.org/wiki/表意文字

情報密度が高いと言えば理解してもらえるのかな？
2bを全部平仮名にしたものと比べれば一目瞭然でしょ
んで情報密度の違いは抽象度の違いによる結果だから

抽象度が高いと情報量は少なくなるだろ
たとえば写真は具体的で情報量が多い

漢字もアルファベットより具体的だから
一字あたりの情報量は多いが
覚える必要がある字数は多くなる

1平方メートルの絵と1秒の音は比較できないんだが
抽象化()で単位をあやふやにすれば比較できるのかな

俺もそう思う
基本的に抽象度が上がれば情報量は下がっていくものだと思う
プログラミングやってれば経験するものだと思うが
Object型は抽象度が高いが型に関する情報量はほぼ無い

>>99
よう、オフィスマ。元気かい？（笑）

具体的なほど高いのは選択情報量で、抽象的なほど高いのはその系が持ってる平均情報量かな

具体的な実装が隠蔽されているほど抽象化の度合いが高いという意味で、
漢字は2バイト(以上)を1文字に「抽象化」していて、
1文字あたりの「情報量」はアルファベットより多い

>>101
ママンにパンツ洗ってもらったか？（笑）

この抽象論議はなんか意味あんの？

どぴゅっ（笑）

2バイト以上を一文字に抽象化、ってのもわからんけど。
「筆や指、ヘラ、ナイフなどを使い、油性の絵の具を、板や布、紙など平面に、芸術性のある意匠を表現すべく塗布したもの」を「油彩画」と記載できるのは、情報密度が高く(3文字)抽象性が高い(『など』、を特定出来ない)と表現するならわかるけど、
英語でも「oils」、くどい奴でも「oil paintings」だし、抽象度や情報密度としてはあんまかわらんかと。
単に抽象度をあげると情報密度が下がるという訳ではなく、用途に対した適切な情報密度を提供するために抽象化するのかと。
情報量は減るけど情報密度が上がる方向に持ってくのが抽象化で、両方下がるのは標本化みたいなやつじゃない？

>>96をまとめると、
数学記号は表意文字。つまり
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の当初の主張「漢字など表意文字は表音文字にくらべて抽象度が高い」とは裏腹に。

抽象の解釈で揉めるとか草

抽象ってのは不要な情報を捨象するんだから
情報量は少なくなるに決まってるんだよ

必要な情報だけ抽出することで
量より質を求めてるわけであって

>>107
いいんでないの？
数学に強いであろうHaskellerさんなら、標本化と抽象化、情報量と情報密度を語ってくれるだろう。
きっと。

次世代じゃない、とか、文字数の関係、とか言って議題を恣意的に絞った罰に相応しい流れだと思うが。

はいガイジ

どの言語でも最低限、実装しなきゃいけない
言語仕様ってできないものなのかね

printf()みたいなのとかですら
言語ごとに"微妙に"違ってて
いちいち覚えなきゃいけないのって
アホらしくない?

言語を超えた共通規格を制定すると
数年も経つと想定されてない
技術が出てきて負の遺産になりそう

そんなもんだろ。
print 文を本当に統一するとしたら一番、低レイヤーな扱いしてる c に合わせるしかない。
てか統一厨ってなんで分かれてるのかについてほんとに思考しないよな。

共通規格って使わないものを入れるとムダだから
どうしても後追いの追加しかできなくて
そうすると時代遅れの規格になる

MSやグーグルやアップルみたいな大企業は
それを無視して需要のある新言語を作るだろうし
だから今の現状がこうなってるんだろう

Cに合わせると、そもそも標準出力って何？って話に行き着いてそこからの話になるので誰も幸せになれんぞ。
標準出力がない環境やら、sprintfとかは普通のlibcではでか過ぎるとか話とか、ファイルシステム？そんなのねえけど？みたいなめんどくさいのを経ての仕様策定になる。

どっかで線引かないと仕方ないけど、その線は言語次第で決めざるを得ない。
Rustの「マクロで展開」もありだろうし、GoやらPythonの「だいたい付いてるけど、それが動く環境以外ではそもそも動かない」もありだし、
Scalaとか古いPascalみたいな「VMが動く環境では動きますけど？VMポートしてよね(笑)」みたいなスタンスもアリなんだから。

仕様や規格って「守らなくてもそれで良い。むしろ守らないほうが(うちのシステムでは)確実に早く動く」って奴が絶対出てくるから、どれだけ未来の事考えて準備しても無駄。
今要るものを今要る範囲で作るのがいいんじゃねえの？
過去と今を見ずに未来や次世代の話する奴にろくな奴はおらん。

「次世代じゃないので外した」なんて、次世代全く見てないって事。

JavaScriptができてから
ES2015が出るまで20年も掛かってるから
各言語共通規格なんて100年掛かっても
できるかどうかってところだろ

そんなことよりはライブラリやモジュールの統一フォーマットが欲しいところ
どんな言語からも、どんな言語で書かれた関数でも、呼べるってやつ
どんな言語は言いすぎだが、大体のメジャー言語は似たような着地点に落ち着いてるし
このような重大なことは無理やりにでももっと黎明期に決めておくべきだったな
標準入出力用意しておいたので後は好きにしてくださいってのはちょっと

違う違う
個々で独自な処理なんて
いくらでもしたらいいけど
最低限、(例えば)printfって打てば
文字列出力するのは
保証しとけって話

ただしそれをやると、野良言語が沢山できる可能性もあるんだが
つまりはライブラリは標準仕様に準拠しているので
ライブラリは揃ってますんで
是非俺の糞言語を使ってくださいっていう
しかし今みたいにライブラリの互換性を盾にして
既得権な言語が常に上位に固定されて全くシェアが変動しないのも不健康
何の言語で書かれていてもかまわない、どうせ好きな言語から呼び出して使えるから
ってなってれば良かったんだが
移植とかマジ馬鹿らしいし

>>120
JVMか.netで動く言語でも使えば？
どんな環境で動くかも決まって無い上にさらに言語の定義すら無いとなると、呼び出せる訳ないかと。
あとは別プロセスとして通信するか。

>>121
文字列って何？パスカル文字列？ヌル終端？エンコーディングは？出力って何？
って話じゃん。独自の処理ではないと言いながら、既に充分独自の話。

だから終端文字がどれかなんて
どうでもいいのよ
対応する事を仕様にいれろって事

>>121
そのようなことは正にどうでもよいだろうというのが俺の意見
言語の多様性の観点からも、そんなことを縛っても意味はない
それよりは、どんな言語からでも、どんな言語のモジュール(ライブラリ)でも
呼び出せるって方が重要だと思うよ
もしそれが出来てれば、君は延々と自分の好きな言語だけ使ってれば良かったかもしれないし
そうじゃなかったとしても、どの言語からでもCのprintfが簡単に呼び出せるんなら
君の願いは達成するんだろう？

>あとは別プロセスとして通信するか。

それも構わないと思う
通信のフォーマットが統一されてれば
後は処理系がそれに対応すればよいんじゃないかなー
RDBとのやり取りも、それですれば良かった話
さらにはネットワーク越しに呼び出したり

そういう標準が一つ欲しかったね、って話
今更遅いが

J S O N R E S T

商売なら有料版と無料版を統一するわけがない
趣味で作るならユーザーの願望よりも作者の都合が優先される

>>124
アホか。対応する事を仕様で決めるためには、何に対応しないといけないか定義出来てないと、対応しようが無いだろう。
何をどうしたいのかわからん。俺ラッパー一枚で済むんじゃねえのそれ。

>>126
今までもCorbaとか色々あったけど、結局は一番無難かつ使われてるHTTPになるんだろうなって感じかな。
前にも同じ発想を書いた気がするけど、なんだかんだでこなれてるし、いつ使うねんと思ってたし、RFCにも「どっかで役に立つ」みたいな記載されてたUPGRADEのおかげでWebSocket使えたりしてるし。
もうちょい早く、なら処理系で対応するよりOSに頼った方が良いんだろうな。UNIXドメインソケットとか。

124みたいな奴が書いた酷いCがあったはずだと思って探したらすぐあったわ。
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.8.2.html

もう20年以上前になるのか。歴史は繰り返すんだな。

>>130
糞ﾜﾛﾋﾟｵ
あんたただの気狂いなだけじゃなくて物知りやね

ガイジID:SQFm1IPCの言いたいこと全く理解せずにディスったり謎リンク貼ってるガイジ本当に草だ……w
ガイジVSガイジって感じやね

でもまあ共通規格を立てようって発想自体は
まっとうな意識ではあると思うよ

HTML5とJSに人が集まってるのも
今一番の共通規格っぽいからなんじゃね？

>>132
ID:SQFm1IPC「ぼきプェチピィ～しか書けましぇ～ん
他の言語もプェチピィみたいになればいいと思いましゅ、アヘアヘ」

こうやろ
ガイジウムとりすぎか？

>>133
そりゃブラウザっていう共通実行環境があるっつーのに、
各々のメーカーの都合で規格がずれてるって状況があるからでしょ。

なんもないところにとりあえずグローバルな規格作ろうとか誰かの自己満足にしか
ならんことを言い出すからバカにされるんだよ。

その前にHTML5やJSが他の言語と、例えばCのprintfと仕様が同じになってるとか
そういう他言語を意識したつくりになってるってわけじゃないから今回の件では不適切な例だよ
どう贔屓目に見てもHTML5とJSは他の言語とは違った異質なもので
ぜんぜん寄せてきてないよ
こういったものを例に挙げて肯定的にとらえる文体なら
よりいっそう各言語で共通の文法～～は要らないってことになる
これは意訳すれば全部Javaで書けばよくね？って言ってるようなもので
他言語を巻き込んで文法を共通にするとかとは反対のベクトルの意見に見える

文法に共通な部分を持たせるっつっても、使用感だけの問題であって
PythonでRubyのコードが走るようになるわけじゃないし
大体のメジャー言語はC言語の文法に寄せてきてるから
その意味で特に不満はないな
細かな仕様が違うのはそりゃ当たり前でしょ

言語として最低限サポートしなければならない仕様を作って
それを満たしていればC上でもJava上でもPython上でもRuby上でもPHP上でも
とりあえずは動く、っていうなら、有りかもしれないけど、あり得ないでしょ
全然違った概念とメカニズムで動いているのに

>>131
これ、確か本で読んだと思う。確かに10代だったかもしれん。
>>132
伝わってるやつが居るのに、まだお前は馬鹿な事言いづけるのかなぁ。

>>137
おまえがID:SQFm1IPCの言いたいことを全く理解してないんだよ
おまえだよおまえ

>>138
どー言うこと？

要は、puts("文字列");
程度のコードはどの言語でも寸分違わぬ同じ動きをすることによって、学習コストを下げたい、って話だと受け取ったが。

そして、それは無理、言語の良いところを殺す。極論は>>130。こんなことするならPascalで書けと。

そもそもさー。"文字列"がすごい、ものによっては言語設計の軸になりうるものなのに、「文字列を出す程度の関数」が低レベルで各言語共通にできる訳ないっしょ。

>>138
まー、代わりに説明しといて。あとで読むわ。

クライアントの統一が無理でもサーバーは統一できるんじゃないかっていう安心感
を土台にして成功したのがJS

C++がCを土台にしたみたいに

>>139
なーんでそこまで分かってて
『「文字列を出す程度の関数」が低レベルで各言語共通にできる訳ないっしょ。』
なんてレスが出来るのかわからん。
あとこの文脈でおまえがどういう意味で「低レベル」という単語を使ってるのかわからん

少しのズレ承知でありたいていに言えば、こいつは「内部でどういう動作するかなんてどうでもいいからとにかく、端末のある環境なら、putとかではなくprintfと書けば端末に表示することを保証しろ」と言ってんだよ

本当に>>129で言う「俺ラッパー一枚で済む話」なんだけど、それを現実に実行してしまうと、それこそ>>130の記事のコードの出来上がりだから「最初から統一していて欲しい」と願うんだろうなきっと

>少しのズレ承知でありたいていに言えば、こいつは「内部でどういう動作するかなんて
>どうでもいいからとにかく、端末のある環境なら、putとかではなくprintfと書けば
>端末に表示することを保証しろ」と言ってんだよ

だからそのことが否定されているのでは？
何言ってんだ？

エスペラント語みたいなものだな
まぁ無理だろう
それより通貨を行き来できるようにする方が良い

>>144
だからただID:SQFm1IPCを否定するレスには俺は文句つけてないだろ？俺もID:SQFm1IPCはガイジだと思うし。

いつまでも「低レベルで」とか「文字列の仕組み」とか言ってる奴はおかしいって言ってるんだ

はいはい、一通りの文字列入出力関数も覚えられないバカは
プログラマにはならないほうがいいと思いますよ。

>>142
ムリだよ。
多少のズレがある時点で仕様では無いし、言語仕様レベルから>>130の無茶苦茶感出てくるぞ。

低レベルってのは、ごめん、いつもこれ伝えづらいな。
システムコールとか呼ぶようなオペレーション、かな。

ちなみに、putsではなくて、printfなら、フォーマットはやるんだよね？Cの形で。

>>146
文字列の仕組みは知らないと今時の言語でも辛いだろ。
そんな事気にした事もないなら、一生気にしないだろうけど。

俺、20年プログラム組んでるけど
文字列未だに理解不能（笑）

utf8だったり、sjisだったり
c#になってからstringが
なんの文字コードで扱ってるかまったく理解してない

sjisのファイルから読み込んだ文字列と
utf8のファイルから読み込んだ文字列とか
c#のstringではどうなってるか知らんｗ
どの段階かで変換されるのか保持されるのかわかってないｗ

日時の文字列のカルチャとかいうのもよくわからない
無指定だとos依存になってバグるし
じゃあc#のstringって何使われてるの?
osに依存するの?とかマジよくわからん

初心者スレで聞いてみたかったｗ

>>148
確かにprintfのfはフォーマットのfだったと思うけど、Fortranではprintでフォーマットもするんだし、言語仕様レベルで滅茶苦茶は言い過ぎでしょ

そりゃfはあったほうがいいと思うけど、fがないと言語仕様レベルで滅茶滅茶ってことはない

そして、厳密な名前にしたことで得られるメリットより、全部printにしたことによる学習コストの低下を優先しろとガイジID:SQFm1IPCを主張するんだよなあ

まあID:SQFm1IPCはなんでfがついてるのかも知らなかったと思うけど、それは「文字列の仕組み」と連呼して彼に伝わるものではないし関係ないな

文字列の実装を隠蔽できていない言語はクソ

けっきょく、みんな近視眼的に言葉尻を捉えてるだけで
この話題の本質わかってないのなｗ

>>154
なんかよくわからんけど、エンジニアガイジと話すと撹乱されて本質が見えなくなる。多分普通の文より解釈がしんどくてそっちにリソース割くんだろうな。
正直>>151も書いていて微妙とは思ったし、昨日思ったこととなんか違う気はする。
もし本質が見えているならちょいと書いてくれると助かる

少し思ったことを書くか。

まあとりあえず c の printf からはじめるけど、これってバイト列からそのまま、出力する形式としては
とても普通な形式なわけだ。低レイヤーから見ても最低限のものになってる。

ただ、一方で型に対していい加減で %d とかと , 以下のところに放り込む変数が
ずれてたら簡単にアボーンするってなことが言われて cout << とか
まあ他の高級言語の print なんかがでてきたわけ。

じゃあ c もそうすりゃいいじゃんと思うだろうけれど、実際そんな高級なことすると
システムプログラミングみたいな生な現場だとその高級なとこにバグが潜む可能性が
高いし、そもそも無駄なメモリ食うし
ってな理由で拒むわけ。

とりあえず単純な見方をするなら上記のような理由で統一はされない。

ああ、やっぱりコイツもわかってないｗ

>>151
言い過ぎでも無いのでは？
printfでも、言語によっては概念が無いので使えない(はず)の%pとか、じゃあ%sは何を取る？%cは？と、収拾がつかんかと。
まずメモリの値を何かに出すって事が実はすごく面倒だって分かってほしいけどな。安易な事言うやつには。

仕様で決めたいならミニマムなのが要るかと。

>>157
何がわかってないか説明してくれる？
わかってないって言うのは簡単なんだし、説明できないって事は自分もわかってないって事と取るけど。

「最低限言語というからにはこの命令をこういう引数で呼べる事」
ってのは、語順が変わる言語は守れない。

なら引数の順番は見逃すわと言ったら、次は型の問題。

型の定義と表現の定義は○○準拠な、となると、それを持ってない言語は用意すべきかとなる。

その辺見逃すわ、人間が見て理解できる形で！となると、見る人間がどんな人間か(言語は何か)でかなり変わる。少数とかだとフランスでの地獄の,とスペースに殺される形。

それも見逃すわ、うまいことやって！となると、
もう定義なんか残ってなくない？

>>158
ない概念は非対応にして%sはその言語で主に扱う文字列にすりゃ満足するだろうよID:SQFm1IPCは
なんならフォーマット機能すらなくしてfortranのprint*の挙動にしてすら満足するだろうよ

だから、Hello Worldなんてお題目があるんよ。どんな言語にも。

>>160
もう別物じゃん。

>>162
別物でいいんだよ。ID:SQFm1IPCみたいな手合いはそういうこと気にしない。printfと打てば出力すれば満足なんだから

ID:qZ0SgL8Y == ID:SQFm1IPC

>>164
そんなガイジといっしょにすんな

>>161
これは正論だ
テスト駆動でライブラリをテストする感覚
だが慣れたらテストではなく有名なソフトのソースを読めるからテストいらない

>>163
なんかわかってきた。本質ではない形でだけど。
標準出力と標準ライブラリとかそういうキチッとした話ではなくて、「printfデバッグで使うための関数」程度の存在として同じような名前で同じような仕様の関数が欲しい、って事か。
>>166
最初にやるようなつまんねー演習課題は、地味に奥が深いんよ。
はいはい画面に出ましたね。予想してたけど。って思うのも当然だけど。
帳票エンジン作った時にDSLのチュートリアルも書いたんだけど、書く側として見ると新しかったと言うか、新鮮だった。

Javaが依然としてナンバー1だが、それに取って代わるのは何か？
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 を追い落としてほしい。

>>167
細部は微妙だけど、まあ大方そんなもんだよ。大分近かろう

このスレ共通認識擦り合わせ出来なすぎだろどうなってんだ

「Ruby風味のプログラミング言語」四天王現る！Elixir,Crystal,Opal,Mirahまとめ #ruby
https://codeiq.jp/magazine/2015/07/26120/

>>170
擦り合わせしたいと言うと荒らし扱いされるから気をつけてね。

さんざん宣伝された「コミュ力」でさえ
プログラムにコミュ力が必須という共通認識は出来ない

頭の悪い人がちょっと覚える労力を避けるために
頭の良い人が多大な無駄な苦労をするのは
社会的損失だ

抽象化思考能力が欠如してるから
自分の知ってる分野・レイヤーの視点で語りたがる

>>170
兜合わせとかいやらしい

2ちゃんとスーパーハカーによると抽象的思考にはアルファベットよりも漢字を使うのがいいらしい。
プログラミングも漢字でやるといいらしい。

>>177
そういう結論になる事が抽象化思考力の欠如してる何よりの証

アルファベット仕様キーボードで入力してる限りは
入力速度がアルファベット＞非アルファベットになるのはどうしようもない

>>179
タブキーと補完使わないの？
俺、和文のあとに、同じ内容の英文つけたメール書くことあるけど、あきらかにタイプ数は和文の方が少ないよ。

抽象思考したいならLabViewとかSPSSあたりでブロック図とかフィルタのグラフで思考するのが一番早かろう。

今の世の中に抽象的思考が足りないって実感あるの？ないでしょ
そんなことよりユーモアが足りないと思う

ユーモアが足りないように感じるのは
ネットのおかげか世の中がマトモという言い方はおかしいけど
正解を引くひとが多くなってきたから
明らかにおかしい状況を
ユーモアで笑い飛ばす必要性があまりなくなってきたんだと思う
苦痛な環境に置かれても、ある種納得してるっつーか

でもプログラミングの世界はまだまだ黎明期に当たるのか
偉い人でも、おかしなことしている人がいっぱいいて

↑まだまだこういうユーモアが有ったりする
今後ある程度成熟していくと、もうこういうユーモアも見れなくなると思うと残念だね
と同時に、正しいことを知っているだけでは勝負にならなくなる
実力が問われるね

そんな残念、杞憂だよ

糞バカジャップランド土人が
山ほど遺してくれたコボルやペェチプゥの保守案件があるからね

>>182
DrinkをCoffeeのメソッドにしてることに最高に納得いかない。
設計者出てこい！

>>182
これ何がアカンの？

「お前が飲むんかーい！」ってツッコミたくなる

>>182
bool値はIsEmpty()がいいなー

次世代言語スレでisHogeは無いだろ…

関数やメソッドの呼び出しに()を使う言語は滅亡すべきだな

明示的に call とか書くのはあんま流行らんぞ。
おれはそれくらい明示的でいいかなと思うのだが。

Coffeeが空かどうかのStateをインターフェースで持たせて、StateはVisitorを受け入れるのが伝統的なやり方かね
次世代だとCoffeeが空かどうかのStateは、インターフェースじゃなくて、型クラスで制限して、パターンマッチで処理を切り分けるって感じかね

Human john;
Cup cup;
...
if (cup.isEmpty)
{
cup = new Coffee();
}
else
{
john.Drink(cup.Drop());
}

まずそもそもコーヒーをモデル化とかしないから

>>192
Drinkの中でdropを呼べよ

久しぶりに見たんだけどなんでまだスレタイにRustなんて欠陥言語があんの？

Rustの何が欠陥？？
いい言語だと思うけど

>>196
強いて言うなら学習コストだ高いとか。
インタラクティブに勉強する教材とか欲しい。
nodeSchoolみたいなやつ

>>194
おまえはcupをdrinkするガイジなのか？

ここでもキャットドア問題再燃w
ほんと使えるなこれ

>>196
ちょっと込み入ったもの書こうとすると即座にコンパイラがあらゆるコード受け付けなくなる言語のどこがいいんだ？

なおC++コードはきちんと動くことは実証済でな

>>194
Human you;
Cup cup = Mix(new Coffee(), new Poison());
you.Drink(cup.Drop());

Rustには保守しにくいコードを事前に排除する意味もあるようなｗ
ぶっちゃけ書き捨てプロトタイプには向かない言語

>>200みたいなコンパイルエラーを嫌う人種ってどういうひとなの？
インタプリタ最強みたいな感じなのかな？
ランタイムでこけるより、コンパイラでエラー出たほうがいいじゃん

>>189
>>190
今どきのメジャー言語は
たいてい関数名＋括弧だけじゃないか？

いちいちcallとか書いてたらコードがcallだらけになるし
関数定義のfunctionすら面倒だっていう声があるから
いちいち関数を明示的に呼び出す言語は流行らないよ

callって明示的に書く言語ってなんだよ
Fortranくらいしか書いたことない

>>196
言語はいいんだけどまだ普及してないからライブラリが辛い

「f(x)」以上に「関数」らしい表現を見た事無いがな。

call書かないとカッコ書けないVBAとかが、callだらけになるかな。

f x
でいいだろ

>>208
これは同意

たしかに。
lispのS式は自然なんだなぁ。

でも、けっきょく
f (ｘ ＋ 1) みたいないことしたり
f () みたいなことするなら括弧的なもの必要になるし
単に省略してるだけでしかないのでは？

f(x+1)はともかく、f()は関数というよりはサブルーチンなんだよな。Fortran以外の言語はあんまり区別しないけど

値を返すのが関数、返さないのが手続きだろう。

>>211
だよね。Lispだと(f x)
どの言語でも定義と実行の区別は必要なんじゃないかな

>>211
Nim ならどっちも不要だな

括弧ないと関数だと区別できないとか

関数と変数とかで名前空間分けるのが普通なのかな
一緒のがシンプルな気がするけどダメなの?
this.objみたいにスコープで名前空間分けたらダメかな

Common Lispは名前空間分けてるけどSchemeは同じだよね
個人的には分けないほうが好きだな

関数の()が要らないなら
配列の[]も要らないね

>>218
正直、そんな文法の言語
使いづらそう……

括弧を開く位置には何か記号が要るが閉じる記号は要らないな
最後のセミコロンが要らないのと同じ

$かな？

>>220
ｐｙてょｎのことか
ブロックあった方が正直みやすいわ
初心者にも、視覚的にここからここまでがまとまりだと説明しやすい
インデント強制はいいけど、いきなりインデントがどうとか説明しても、イミフやろ

むしろpythonの方が見やすい

a[b + c] + d + f(x + e) + 100
↓
a[ b + c + d + f(x + c + 100

なるほど素晴らしいアイデアだな

>>224
実を言うとセミコロンの省略でも同じ失敗をしてるんだよな
y=f; (x)();
↓
y=f(x)()

Haskell ならこうかな
(a !! b + c) + d + (f $ x + e) + 100

>>224
ガイジ

>>225
改行しろガイジ
(x)←意味分からんぞガイジい

!!って+より優先度雑魚かったんか

括弧の意味は二つある
優先順位を明示する、または関数呼び出し
どっちの意味か分からんから関数呼び出しの意味で括弧を使うのはもうやめたほうがいい

>>228
!! の方が優先順位高かった ゆるして

タプルやらにも()を使うのが普通だし
無意味な主張だな

括弧を使った関数呼び出しは関数にタプルを適用していると見ることもできる

>>220
>最後のセミコロンが要らないのと同じ

それなら、最後のコロンも要らないだろ

インデントを強制する言語の中で、
Haskell や Occam は文末は改行のみだけど、
ｐｙてょｎ(>>222)だけが要らないコロンを強制する

pythonって中途半端だよな
高階関数とかドットチェーンしづらくして、平易な書き方を強制したい
と見せかけてあの可読性ゴミ屑なリスト内包表記糞とかいう糞を強制してくる真性ガイジ
間違いなく俺が設計した方がいい言語できるね

変数宣言の無い言語は大体糞
変数スコープがぶっ壊れてる

>>235
for/ifの中から飛び散る糞とかほんと糞

高階関数とドットチェーンし辛いのはそうだけど、リスト内包読みにくいっていうのは理解できない

条件分岐や反復なんてもんはどんなに言語が良くなっても
馬鹿が書けばどこまでもくそにすることなんてできんだよ。

>>234
＞間違いなく俺が設計した方がいい言語できるね
無理無理
無名言語がひとつ増えるだけ

以前仕事でRuby書いてて、()省略すると自分はいいんだけど他人が書いたコードは変数だかメソッドだか分からなくて面倒な事多かったから無しだなぁ

IDEの機能を言語と一緒にして例えば
アンダーバーとか、色とか、枠線をつけられるようにしてブロックを表せたりとか
そういうGUI的に拡張させるアイディアって無いのかな？

.Netがやりまくってるだろ

確かにhaskellの$で閉じカッコは要らないは惹かれる。
他の言語でも採用されればいいのに。

でもそれって、表記上、末尾の括弧を省略できるって状況だから可能ってだけで
実際は括弧付いてるようなもんなんじゃないの？

>>241
特定の開発環境に依存するのはリスクを感じる
言語の機能でなくてjavaのdocletやpythonのdoctestみたいに自由な部分で拡張すればいいんじゃないの
拡張可能にさえしといてあげれば、数多の楽したがるエンジニアが稀にいいもの作ってくれるよ
だから言語はシンプルがいい

>>だから言語はシンプルがいい

これはちょっとすでに古い考え方だよ
今の人気言語は最初から機能てんこ盛りだし
ほとんどの言語はいろんな形でで最初から拡張可能
lispやschemeですら充分に複雑だよ

そうだな
初心者はIDEに統合されててなんでも言語がやってくれる方がいいな
フレームワークとか作ってると競合しないように気を遣うが

＞今の人気言語は最初から機能てんこ盛り
Scalaなんかは最初からいろんな機能盛り込んでるな
そのおかげで言語仕様が複雑になって覚えにくいけど

>>241
IDEの機能はIDEに任せた方がいいんじゃないの
たとえばシンタックスハイライトとかIDE側の機能を
言語側に仕様を入れる必要ないと思う

そこをあえてやりたいなら
アノテーションで拡張可能にするかな

メールなんかでHTML形式があるけど
あんな感じでHTML形式でプログラムを書く
そうするとソースコードの途中にコードを説明する画像を挟み込むことが出来るし
音楽を入れて音声で説明してもよい
さらにはJSを駆使して動的なことをしてもよい
で、それで何のプログラムを書くかというとHTMLを書く
ブラウザで表示させる
ソースコードのソースコードがあるということだ
素晴らしいね

>>249
それをあえて入れるところに意味があって
人はあくまでプログラム自身に集中するべきじゃないかな

OSと言語とIDEを選ぶのは大変だからね
言語を選ぶだけで他の全てが自動的に決まるのが理想のように思える

現実には言語を変更するだけで他の選択肢も強制的に変更させられることがよくある

>>250
文芸的プログラミングの事かな？

>>250
XMLで可能だけど誰もやってないような
javadocで十分だな

YouTubeで稼げるジャンルは〇〇動画です。YouTube講座


最新トップYoutuberの年収は10億円、1億円の時代はもう古い
http://www.himatubushisp.com/entry/2017/05/10/224945
Youtuberヒカルが月収を明らかに!!おはよう朝日です出演


第１回案件王ランキング！YouTuberで１番稼いでるのは誰だ！

;t=61s
ユーチューバーの儲けのカラクリを徹底検証！

;t=504s
【給料公開】チャンネル登録者4万人突破記念！YouTuberの月収公開！

;t=326s
誰も言わないなら俺がYouTuberのギャラ相場を教えます

;t=118s

最高月収5000万円だとさ。年収じゃなくて「月収」な
おまえらもyoutubeに動画投稿したほうがいい
手っ取り早く視聴数稼ぐには有名ユーチューバーへの物申す系動画がオススメ
しばたーやよりひとやkunやぽんちやモンスタージョンなどを真似すればいい

docのマークダウン対応くらいはあった方が便利だけど
愛生病院みたいなsrc読みたくねえだろ

コメントみたいな曖昧な仕組みじゃなくて
コードのメタデータとして言語機能が積極的に管理していく方向に発展して欲しいね

愛生病院は懐かしい・・・と思ったら
2013年まであったのかよ、恐ろしすぎ
病院の先生ってやっぱ頭良いんだなって思うのは
未だかつて愛生病院のサイトより見てて不安になるサイトには出会ったことが無い
やろうとしてできるものではない
そんなことが片手間で出来るんだから、医者って本当に凄い
http://web.archive.org/web/20130515083615/http://www.aiseikai.or.jp/
↑魚拓
若い人で知らない人は一度勉強したほうが良い
昔のインターネットがいかに刺激的だったかが良くわかるだろう

>病院の先生ってやっぱ頭良いんだな

目の前にある具体例と真逆の結論を出すのがすごい
これが抽象化か

真逆も何も医者は頭が良いものだろ

MSが提唱してるlanguage server protocol(LSP)はまさにIDEの機能を
言語側で提供しましょうってアイデアだけどね。
TypeScriptで採用してる(採用しようとしてる？)。

言語のシンタックスに一番詳しいのは言語自身なんだからIDEの機能を提供してくれるのは理にかなってると思うけどね。

俺としては、言語を新しく使うたびに初期段階で補完機能に悩むのはしんどいので
新興言語はかならずLSPを用意しておいて欲しい

参考：
http://qiita.com/atsushieno/items/ce31df9bd88e98eec5c4

>>261
投稿先間違いました。m(_ _)m

>>259
どう見ても皮肉だろ

>>131
これどゆ意味？
C診断室ってCやってる奴なら今でもわりと有名だと思うんだけど

expert Cに似たようなマクロが載ってるけどね
ALGOLだったと思ったけれど

>>130
ふり返るとこういう言語拡張はLispならアリだし
むしろ今の時代のDSLを先取りしているな
C言語中心の昔じゃ受け入れられなかっただけで

ナシだわ。こんなん横行したらまた歴史が逆回転始めるよ

Lispはそういうことをしてもそう簡単にはLispらしさを失わないからええで

んなわきゃーない
じゃあ、Ｍ式で書けよ

M式はちょっと……

modula-2 俺の青春の言語

ジジイどころじゃねえ

最近の新しい言語を覚える動機が
馬鹿がマウントしてくるので、コードを荒らされないようにするため
ってなことが増えてる。
悲しい話だよ。

>>273
マウントとの関連性がわからんのだが。ってかマウントがわからん。

自分のソースが荒らされる(≒自分では社内政治も含めて『直せない』)ほどの影響力ってマウントじゃ無くて、ついていけてない実力差であって、あんまりマウントマウント言うべき事で無い気がする。
現に、新しい言語を覚えるモチベーションになってるならなおさらでは？

自分で言語作れば？

人によって得意なことは違うので一概には言えない

自分で言語書くのはマジで勉強にはなるからな。
負債作るだけだから実務では余程求められない限りやるべきでは無いけど。

言語つくるよりは構文解析器作ったほうが小回り効いて良い

すl良

>>276
サーバルちゃんすこ

>>278
意味不明すぎる…
yacc的なのを言ってるなら既存ので十分すぎる

言語作ったらパーサーも勿論作るっしょ。
yacc要るほどの自作言語なら言語自作らんほうが幸せ。
セルフホストするときに苦労が増える。

>>282
何言ってんのこいつ
yaccは糞としても、今時構文解析に専用ツール使わねえ方がめんどいだろ

パーサーとパーサージェネレータの違いがわかってないのが数名いるな

>>283
構文解析に専用ツール作るならわかるけど、少なくとも+++++の解釈が不能とかいや出来るとかくだらん事は考えたくないし、フルにそいつの機能使うわけでもないのに、ビルドするために依存したくはなくない？
そいつでコンパイルできるソースが出るパーサジェネレータが欲しい。それが面倒なぐらいなら、その言語で手書きできるパーサの範囲の言語にしろって事。

どうせ遊びと勉強のためなんだから手っ取り早く色々試せたほうがいいに決まってるだろ
BNF書くこと自体も勉強になる
パーサ手書きの練習なんぞ電卓レベルで一回やれば十分
あんなもんただの単純作業だ

とにかく「あ」の文章は読みづらくて脳に入ってこない
他の人の書く文章と明らかに違う
そもそもの何かが違うとしか言えない
何が違うかは分からんが、とにかく違う

そしていつもの事だけど、こいつが居るだけで話の論点がズレる
話を長引かせる能力だけは本当にすごい

>>287-288
そりゃお前だって2レスも(しかも無駄に)してるんだから長くなるんじゃねえの？
「何が間違ってるかわからないけど間違っているに違いない、なぜなら俺がそう思うから」みたいな感想文の代わりに建設的な否定でもすりゃ、早く話終わるんじゃねえの？
自分で論点ずらして話を長引かせる瞬間の>>287を書いて気付いてない無能にはそれは無理なの？

話の意図を汲めずこうやって短絡的に反応するのは典型的な発達障害でしょ
「あ」に忠告しておくが、君は特に>>289のように概念的な話をしようとすると本当に全く人に伝わらないから注意した方がいい
>>285のように具体的な物事に照らして話をしてくれれば、まだ少しは理解できる

こいつ読み辛さを指摘されるとすぐ発狂するよな
これまで何度も指摘してやってんだから素直に認めて頑張って直せや

単に知ったか自己弁護野郎だから
そいつつついても何の得もねえぞ
そいつはお前らに相手してもらうことだけを目的としてる

情報工学の基礎すらしらん自称イット産業のニートよりかは
いくらかマシなレスしてるから許せるよ

クダクダ言ってるが実用的にはDSLで十分

>>290
汲んでないのはそもそも汲もうとしてない。
書かれていることを書かれているように理解して、書かれていない事を推測しないのは基本じゃないの？
そんなとこ汲むから全員が思い込みで話して、散らかるんじゃないの？

具体的に照らせても無いのに否定してるやつにそれ言っといて。
>>291
理解できない馬鹿に合わせて説明屋になるつもり無いから。
土俵にも立ててない事をまず恥じてから書いてほしいと言う嫌味だとまで言わないといかんの？

理解できない馬鹿と来たか。俺の言いたいことを理解出来てない馬鹿はお前だ

発達の相手すんな

>>295
あのさ、みんなが努力して君の言いたいことを汲んでくれてるから話が成り立ってるんだぞ?
このスレに限らず、おそらくリアルでもそうだと思う。
皆がその努力を放棄したら本当に君は誰にも理解されなくなってしまう。
最低でもその努力に対する感謝だけは忘れちゃいけない。君のことを思って言ってるんだ。

>>286
ほんとそれ
本格運用するでもない、自作言語の字句解析や構文解析を自前で実装とか、ムダもいいとこ
そういうのは流行ってからやるもんだし

>>289翻訳

2つも駄レスしてる奴がそれ言う？
理解しようともせずヘイト感想文撒くぐらいなら、しっかり否定できる意見書けばいいじゃん
ま、>>287-288みたいな自己矛盾したレスしちゃう無能には無理かな？

まあ、俺もこいつは恣意的に長文レスするからあんま好きじゃないが、
少なくとも知識もない上、中身の伴わない批判しかしない単発の糞よりはマシだと思うわ

なんかもう話題が次世代というより辞世代

>>298
それはわかっとるよ。
語弊があったな。「自分が理解できない事を『理解できていない』と認識できない」と言うわ。
なぜ理解出来ないのかヒントでも出してくれんと、なんともしようがない。

>>299
自作言語で、新しい構文考えた時に、今まであった言語とは違う形でパースしたいとか、そういう事考えたら、パーサーは作ったほうがいいと思う。
行き着く先はどうせBNFと既存の色んなパーサジェネレータなんだろうけど、それが何故かを理解しないまま適当にパーサージェネレータ使うのは危ないと思うな。
まぁ、原動機の仕組みを知らんでも車には乗れると言えば言えるけど。

お前の書き込みのどこがマズイのか、1,2スレくらい前にさんざん教えてやっただろうが
まるでヒントを貰ってないような書き込みはやめろや

ガイジに構ってないで建設的な話をするべきだな

ID:wvHXgSou　←発達ガイジwww

思わず統一性ない書き込みしたのはすまんやで

ほな俺は出張旅行いってくるわ！海外前ノリは毎回楽しみ。
ではー

それをわざわざ報告する構ってちゃんっぷりよ
二度と帰ってくるなよ

それを構うやつが居るから居付いちゃうんだよ
みんなもうさすがに分かったと思うけど

…わかった
この「あ」って人の書き方、頭に入ってこない感じに既視感があると思ったら、一昔前の専門書の和訳だ。
自分の言葉で表現し直すか、元の英文を想像するかしないと理解できないところがそっくり

多分日本人なんだろうけど、どういうプロセスでそういう文章になるのかね？

怪しいことを言って突っ込まれたら適宜解釈を変更できるように、分かりやすく具体的なことを言うのを避けてるだけだろ

プログラム的に言えば、やたら細かいクラスに沢山分割されてて
しかもそれらが同一レベルで扱われてて
全体の流れが分からない、って感じか？

多分一度に頭で扱える文章の長さが極端に短くて
継ぎはぎだらけになって読みにくいとか
そういうことだと思う
それプラス、オブジェクト指向のやりすぎで
文章の流れがおろそかになってるとか

例えば
>負債作るだけだから実務では余程求められない限りやるべきでは無いけど。
だと、普通なら
>負債作るだけだから余程求められない限り実務ではやらない方がいいけど。
だろう
「実務では」の位置がおかしいのと、「べき」の後ろに「無い」の否定は読みにくい
そういうのの積み重ねで読みにくくなってる

句読点を入れろってだけだろ
馬鹿なのか？チョンか？ガイジか？
現役ニートはさすがだな

脳内メモリ不足のADHDっぽいな
運動と瞑想すると軽減されるぞ

>>316
一歩間違うと読点過剰症候群に陥るんだよな

よくわからんがとにかく結論を最初に書くとよいらしい
どうすれば改善するかダラダラ考えるより、改善は不可能って最初に書けばよい

なんでどの次世代言語も似たような機能ばっかりになっちゃうんだろう
もっと独自性出そうって思わないのかな？

独自性満載のペチプァでもやって、どうぞ

作者が便利と思った機能は絶対載せるんだから自然とそうなるだろうよ

c++ なんか明らかに他の言語にあるならおれんとこにも入れんと
みたいな発想だよな。

chapelはどう？気になってるけど触ったことがない

Goとかは俺の思想感が強くて、むしろちょっと他の言語の真似して欲しいってなるの。ジェネリクスとか

>>319
いい機会だからスレタイに入ってるやつ含めて、どれを次世代言語として想定してるか列挙したって。

次世代言語っていうからには、いつの「次世代」を想定しているのかも書いてね
まさか30年後には普及する、とか言わないよね

smalltalkを次世代言語にしよう

SmalltalkのIDEは
次世代IDEのモデルになってもおかしくない

それをモデルにして生まれた数々の分散オブジェクト指向技術はとっくの昔にことごとく爆死したよ

いやErlangなんかはSmalltalk（とProlog）に
影響を受けてるから全滅したわけじゃない

影響を受けてたらいいのか……

影響を受けまくったPHPさんはどうなりましたか（漣声）

プログラミングが義務教育化するみたいだけど、
どの言語でどのアプリケーションをネタに教えるんだろうね。

C→土方
Java→土方
PHP→ガイジ
JavaScript→土方

Pythonやろなぁ

scratchでしょ
高度なのは教師がついていけないし

小学校って鶴亀算が正義で方程式はズルの異世界なんだろ

鶴亀算みたいな小学校算数の
独自の世界でだけ通用する
ガラパゴスなの嫌い

正直教育者の教育から始まるからなぁ。
javaとかなったら泣くわ。
Goも特殊すぎてないし。
やっぱりPythonじゃないかな。海外じゃ教育用としても使われてるんでしょ？

教育者の教育
丸投げの丸投げ
お前らいつも丸投げしてるな

良い話かな
我々は曲がりなりにもプロなわけだし、家庭教師や個人授業で誰でも稼げるようになる

JavaだろうがPythonだろうが、現場の教師が対応できるわけないじゃん
しかも小学生やで
普通にScratchやって簡単なアルゴリズム作るまでで終わり

ガイジ教師が糞ポンコツ利権中華パッドのトラブル対応するだけで終わりそう

pythonはヘビの絵があかんわ。
ヘビ嫌いの子がプログラミング嫌いになりかねない。

30年後に普及する次世代言語Haskellがいいと思うよ。
実際彼らが活躍するのはそれくらいだろうし。

Haskellもうちょい速い処理系出ないかな……

趣味でやるならともかく
義務教育として小学生がプログラミングを勉強する必要性って全くないよな
小学生の貴重な時間の無駄遣い

事務方とか、プログラムできたらもっと効率よく仕事できると思う

スクラッチで書き捨てのを書けるようにするだけでだいぶ違うと思う。

>>348
何がだいぶ違うの？

そんなこと言ったら家庭科の授業もいらなくなるしな
PC触れない機会なんて絶対無いんだからやるのはいいことだろ
メインは理論的な思考を養うことだろうけどな

プログラミングを学んだ結果がそんな非論理的な主張しかできない人間なら、
必要性が無いに同意するわ

プログラミングっていうほど論理か？
ソリティアとかフリーセルでいいじゃん
パズルゲームこそ論理そのものだと思う

PCの使い方やコンピュータやWebそのものについて勉強するのと
プログラミングの勉強をするのとじゃ意味が違うよね？

理論的な思考は小学生なら算数を中心に他の教科で勉強した方がいいでしょ
図画工作で物理的なものを作ってたりしたほうがよっぽど脳が発達すると思うわ

実用性というなら、法律の授業でも設けたらどうだろうか、と俺は思う
あと、経済のことも全くやらないよね
で、結局、テレビで池上さんとかでしょ
どーなん

正規表現使って一気にファイル編集するとか
そういうのは教えてもいいかもね。
それくらいやってくれって思うこと多いし。

頼むからプログラミングを学ばないでくれ
http://jp.techcrunch.com/2016/05/17/20160510please-dont-learn-to-code/

プログラミングって専門的ではあるんだが
そのベースとなってる部分にあまり学術性が無いというか
例えば電気回路で言うところのオームの法則など
そういう学校で扱いやすい話題があまりない
疎結合やモジューラビリティー、テスト性とか
すぐにえらく専門的で現実的で「実技」な話に発展する
学校で扱いやすいのは、せいぜい論理演算などの離散数学ぐらいか

もともとやらせたいことを順番に並べて書いておけば
コンピュータが逐次実行してくれるってだけだし
そのような仕組み的概念など、一瞬で理解できてしまう
足し算よりも簡単な概念だ

ただし、コンピュータに、何を、どうやらせるか、の話になると難しいが
これは電子回路で言えば、理想素子など存在しない現実世界で
実際に回路を組む場合のノウハウの話であって、えらく専門的だ

それでも学校でプログラムをするなら
きっと目的に向けて手続きプランを立てる力を養うためなんだろう

それか将来ソフトウェアエンジニアになるのを早期に諦めされる意味合いは有るか
例えば、もし音楽の授業が無ければ、俺は自分に才能が無いことに気づかず
ミュージシャンになりたいと思っていたかもしれないしな
そのような面はあるかもしれない、向き不向きがあるからな

>>357
特別に一回だけ教える
お前のレスは、このスレに不要

>>354
現状のって話だと動きが速くて教育内容がすぐ陳腐化してしまうんじゃないか

>>357
そうか？
アルゴリズムなんて数学に近いと思うが

>>357
明らかに素人の戯言すぎる…
アルゴリズム云々置いておいても、
形式言語とか式の簡約とか、もろにプログラミングそのものを扱ってる分野なんていくらでもあるのに…

話の筋がズレてるし、その元の話もスレ違い。他人をこき下ろすのに夢中になってるのは見苦しいです

子供向けでって言うとラズパイ使ってマインクラフトをカスタマイズするみたいな教育あったよね。
マインクラフトそんなに面白いんか

＞もともとやらせたいことを順番に並べて書いておけば
＞コンピュータが逐次実行してくれるってだけだし
とりあえずこいつがコンピューター科学全く知らないで戯れ言ほざいてる下流コーダーなのはわかった

自動運転で運転手を解雇するのに夢中になってるかと思えば
読書やゲームをするだけのために教師を雇う
この需要の乱高下が見苦しい

つまらない仕事はPythonにさせるための布石やぞ

何か反論がいっぱいあるようだけど
小学生や中学生が理解できるか？って部分が抜け落ちてる
論理演算などの離散数学ぐらいならまぁなんとか
それ以上は難しいだろう

教えたいのはもっとプログラミングの概念の基礎だろ

>>368
お前にとって小中学生に理解できないことは「学術性がない」んだな

そりゃ今は義務教育の話だからな
> 例えば電気回路で言うところのオームの法則など
> そういう学校で扱いやすい話題があまりない
の「学校」は小中学校を意味しているのは明らかだろ？

プログラミングを教えて日本国民を論理的にしてしまうと
政府は国民を騙せなくなるから義務教育では教えないだろうな

>>371
義務教育で扱える程度の内容に乏しいって意味で「学術性がない」なんて強い語を使うなよ紛らわしいわ

>>372
歴史では昔の政府が国民を騙していたと教えてるんだろ
エビデンスを集めるのに数十年かかるようなので
エビデンス重視の教育では不確定な最新情報を教えるわけにはいかない

義務教育期間にプログラミングを教育するのなら、
問題に直面したときに次の3つの意志が自然に芽生えるよう教育してもらいたい。

1. 問題を直列に分けて考えようとする意志
Aを解決するにはBが必要、BにはCが必要・・・と考えること。

2. 問題を分割統治して考えようとする意志
平行して解ける小問題に分けることと、それらを合成すること。

3. 問題を状態遷移の観点で考えようとする意志

こういう意志が自然に芽生える子は、
プログラミング以外でも問題解決能力が高いと思う。

そもそも、次世代言語に求められる
機能や概念みたいなのって何よ

論理の対義語が多すぎて困る
物理
心理
データ

>>376
メンテナンスしやすいコードが少ない労力で書けること？

>>378
でも、今の言語でも充分
メンテしやすいし、これ以上コードを書く労力を減らすなんて無理じゃない?

うーん。「今の言語」が何を指すのか良くわからんから同意も反対もしかねるなあ

じゃあ、例えば、深層学習やA.I.的なものを言語やIDEに組み込んで
ほとんど（全く）コードを書かないで半自動でプログラミングするとかって次世代？

今までの世代交代ってどこだったの?

深層学習でそんなもん実装しようとしたら何を入力にすればいいのか良くわからんが、万一出来たら次世代。かなあ？

>>360
違うよ
最も大事な近代史を教えないのは
衆愚政治をしやすくするためだよ

次世代というよりも今求められてるのは並行処理が簡単に実装できる仕組みを言語側で用意すること。
CPUのシングルコア性能が頭打ちになって後はマルチコア化するしか無いから。
次はGPUを勝手に使ってくれる言語とかかね。

>>383
入力はクラウドからビッグデータ的なものとかランダムに垂れ流しに叩き込んで
そこから深層学習でパターン化できたものを
勝手にプログラム化するとか

AIと小中学生に教えるのは完全情報ゲーム
次世代は不完全とか不完備とかいうのをやれば需要は確実にある

政府が義務教育で国民に絶対教えたくないのは十分条件と必要条件だな。
これを教えないからマスコミを使って簡単に騙すことができる。

>>386
えーと。失礼ながら深層学習のご経験は？
ちょっと深層学習組んだことのある人の発言には見えなかったもので……

○次受けが多いほど退場率が早くなる。高くなる

直受けの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) クラウドテック　プログラマーズ

>>384
それなら都合の良い解釈で教えた方がいいだろ

>>391
江戸時代のミナトモノチンポコリンが紫式部とセックスしてひり出した国産みが、日本の始まりです。
君たちは十分勉強した。頑張った。
だから大学にいったらたくさん遊んで、頭クルッパーになるまで酒浴びて、友達とセックスして、
楽しい思い出たくさん作りましょう。
就職したら、よくわかんないけど税金と年金を払えば一生安泰。美しい日本をトラストミー。


これが中世ジャップランド土人村の教育方針。
そもそも、現代史の存在すら知らなくてよいのです。

なんだ教育どころか躾も受けなかったやつか

これ陰謀論だからね
異常な言動をするのは、想定外なことをやらないと陰謀を阻止できないという理由だね

次世代言語の持つべき機能は何ぞや、と考えてもらちが明かない
その前に、次世代とは一体いつの事か、だろう
次世代はいつ到来するのか
到来しないなら意味が無い
来もしない架空の次世代を議論しているだけになる
かつて次世代言語と言われたD言語は普及する前に陳腐化して消えた
実際スレタイにもD言語は入ってないし、話題にも上がらない

例えば30年後じゃ遠すぎて議論する意味が無い
今現役の人は既に現場を退いているだろうし
今大学生で言語に興味がある人でも30年後じゃ50歳
30年後にメジャーになるなら25年後から学び始めても間に合う
今から30年前は1987年、30年は遠い
その前に30年後じゃスレタイに挙がってる言語も陳腐化しているかもしれない

なんで、次世代は5～10年後が妥当だろう、と俺は思う
今ある言語で5～10年後に普及してなかったら、その先もずっと普及しないんだろう

これほど中身のない長文レスも珍しい

ただやはり俺は問いたいんだよ
次世代とはいつの事なのか？

機能だけじゃなくて、ちゃんと時間軸があって
その中で流行り廃りがあってやってることだから
時間無視して機能だけ着目してもプランが見えないだろ

むしろ機能がどうであれ、5年後に普及している言語は
次世代言語と言えるだろう？正に一時代

当然今普及しているC#やC++だって貪欲に新しい機能を取り入れていくわけで
その中で5~10年後を目途に食い込んでいけるかどうかなんだよ

次世代ってのはそんな時間がどうしたこうしたとかの話じゃないよ
流行り廃りとかも関係無い

そう狭い視点で考えずにもっと広い視野をもった方がいいよ

そんな短いスパンにするんならPythonだわ
次スレからスレタイにPython入れとけ

>>396
構うな、放置しろ
今度はコイツがここに居付こうとしてる

次世代って機械学習になるんじゃない。
行列計算とかするときに勝手にクラウド経由で計算リソースを取ってこれるようになる。plan9ってそういうosだって聞いた。

一行目と二行目以降が関係なくてワロタ

>>398
明日から本気出す
ってやつ？

次世代はドメイン特化言語の時代になり、汎用言語は廃れます。

>>404
ドメイン毎に覚えなきゃならんのか
めんどくさい時代になりそうだな

勘違いしてるみたいだけど、エンタープライズITでいうDSLってのは
「専業エンジニアでなくてもビジネスドメインの専門家自身で使いこなせる言語」のことな
言語そのものは汎用言語でも構わない

次世代言語はプログラム開発言語じゃなくなるよ
口語で伝えればそれでプログラム組んでくれるように成る
「この前教えた利子計算の方法あるでしょ？　それでこれ計算しといて」
「都会の中にワーゲンビートルの車表示して、太陽光は七夕の東京あたりの午前10時の薄曇りって感じで、街は勝手に作っといて、あ、車は運転下手なおばさん設定で」
とかね

>>407
「自然言語でプログラミング」このたかだか12文字で表現できる主張に、何行かけているのやら。
お前がやると簡単な集計のために一日中PCとおしゃべりしてそうだなw

>>405
今だって結局、現場ごとに複数言語覚えるんだから一緒だろ。

CeylonがEclipse Ceylonに
https://www.infoq.com/jp/news/2017/09/ceylon-joins-eclipse-foundation

>>407の例はプログラミングと呼ぶのか？
単にプログラムを使ってるだけに思えるが

>>409
うーんそんなにコロコロ現場変わらんしな

>>412
なら次世代だろうと同じ言語でいいんでないの。
同じような仕事なら言語変える必要ないだろうし。

>>407
PHPみたいな冗長この上ない糞コードを永遠書く糞

>>408
適切な抽象化ができる糞

糞杉内

>>411
運動会の「プログラム」とコンピュータの「プログラム」は同じことだよ。
式次第。次こうしてその次はああして…とつらつら書いてある。
それにしたがって動くのが人かコンピューターかというだけの違い。
人とコンピュータには違った特徴があるけどね。
人は融通が利くがコンピュータは違う(厳密)とか、人は単純計算が遅いとか…
要するにお前も毎日会社で上司のいい加減なプログラムを柔軟に解釈して実行してる計算の遅い手足のついてるポンコツコンピュータみたいなもんだ。

>>413
現状はc#で充分だわ

Ceylonがeclipseに移管されたらideサポートはeclipseの方が充実するんだろうか。
ここに専用スレないし日本語の情報も少なくてまだマイナーだよね。Ceylon.

>>417
IntelliJ IDEAのKotlin に対抗するためにEclipse が動いたんじゃね？

ScalaにもKotlinにもJava8にもなれなかったセイロンちゃん

>>415
式とお前さんが本来言いたい文じゃ、順序性の観点で全然違うんですが
最近この手の完全な門外漢がこのスレ出入りしまくってるのなんで？
どっかで流行ってるのこのスレ？

GUIプログラミングは次世代?
言語ではないかもだけど
次元が違うかな

ここで求められているのはそういう次元の話ではないだろ

口語で
GUIで
要は文字を使わなければいいと思ってるだろ
あとGPUみたいな回路にも文字がない

ビジュアル的な資料からコードを生成してほしいね

そんなもんできても
これこれのドット判定は信用が薄いからほにゃららの色に統一すべきとか
糞みたいな運用しだすだけだよｗ

言葉で説明されるより、疑似コードでも何でもいいから
コードで説明された方が分かりやすい場合も多いし
その時点で・・・

あと、科学的観点からみると、再現性が無ければならないというのもあるし
品質の面からみてもそうだし
再現性が無ければバグ取りも苦労するだろう
正確無慈悲なところがコンピュータの良さでもあるわけで

GUIプログラミングじゃなくて
ビジュアルプログラミングのことだったか
それは言語というよりツールの話だね

昔prograph っていうビジュアルプログラミング言語があったな。
大昔の話だけどね。

大昔っていつ？
室町時代頃？

Lisp すこ。common Lisp汚いから嫌い

>>420
ちょｗｗｗ「式」次第だから式だと思ったってこと？
小学生かよw国語の勉強頑張れよー

>>432
プログラムでは式と文は厳密に区別するものだよ
勉強になったな生ゴミ

>>433
で？ｗｗｗ
>>415のどこに式と文について書いてあるの？ｗｗｗ
あれ？ｗもしかして「式」次第だから式だと思ったってこと？
小学生かよw国語の勉強頑張れよー

そもそも予定という意味のprogramme と手続きを記述したコードを混同して、
それを例えになってない例えにしてる時点で頭が悪いんだが、
まあそこは許してやろうか

>>434
演目を集めたものが式という解釈では、
プログラムとはプログラム次第であるとかいう頭の悪い主張になるけどいいのかな？
あ、もしかしてそれすら理解できない？

>>435
そもそも？ｗｗｗ
式と文はどうなったんでちゅかー？ｗｗｗ

これマジか？

>>436
>演目を集めたものが式という解釈では、
ん？ｗ誰がどこを解釈してそうなったのかな？ｗｗｗ
とりあえずどこを解釈したのか引用して示してみ？
小学生のくせに藁人形論法使ってごまかしにかかるとかｗｗｗ

>>431
純Lispの原理はシンプルで良いけど
CLの実装がいろいろ汚いんだよな

特にこのスレだしClojureでいいと思う

>>437
>>439
で結局語彙の乏しい雑な煽りには必死だが、何の説明と反論もできないと
お前病院でIQ測定して手帳もらってきた方がいいぞ、将来のためにも

ただいま。

>>407
それ、あんま良くわかってない(特に営業上がりの)PMがやってる事じゃない？
その下がPMの発言を汲み、そして纏まらなかったらメシ打ちで機嫌を取り、深堀してヒアリングさせて、なんとかごまかすという人間だけが出来る事をやって、
それでも死屍累々になる今よりもっと酷くなるかと。

客の言ったことだけに基づいてシステムを作るのが不可能なのは当然でしょ
最も重要なのは客の言葉よりもアーキテクトやエンジニア自身の経験や常識だ
人間も結局、事例を学習して継ぎ接ぎしてるだけだよ
そう考えると、それが機械に置き換わるのは案外夢物語ではないよ

Clojureはjavaの上にあるのが特色だけど、この特色がどうしても好きになれない。どうせならLLVMの上にでも乗せてくれれば良かったのにって思う

>>443
継ぎ接ぎで解決する部分と、研開で本気でやらなきゃいかん部分がどーしても出てくるかと。
うちも知財部はチェックはしてくれるけど、明細書は自分で書かにゃならんし、継ぎ接ぎではやっぱ拒絶査定食らうし、弁理士の得意分野なら「新規性に疑問を持たれるのでもうちょい頑張って」って言われて知財部からかえってくるよ。

>>441
何の説明も反論も出来ていないとは、まさにお前のことだな。自己紹介乙。

>>415
>運動会の「プログラム」とコンピュータの「プログラム」は同じことだよ。
>式次第。次こうしてその次はああして…とつらつら書いてある。

に対しお前は
>>420と>>433で式だ文だとトンチンカンなことを言っているが、
一体>>415のどこに式と文に関する記述が出てくるのか、まず発端のそこを説明しろよ。
いくら聞いても
>>435、>>436と下手なごまかし藁人形捏造して逃げてばかり。

「式」次第だから式だと思ったってこと？小学生かよw国語の勉強頑張れよー

そのへんHaskellはバックエンド選び放題でいいよな
Win版はうざいけど

副作用がガンガン使えるHaskellってつくれないのかな？
内部でモナドに変換してくれて解決してくれるようなんでいいから

人がそういうのをいちいち気にして
プログラミングしなきゃいけないってちょっと次世代的にダサくない？

プログラムと言う単語が悪いわな。
もう少し語源に近づいて「(ある目的のために)予め書かれたもの(pro(羅pre 前以て)-gamme(羅gram 書く))」とすると、運動会のプログラムも電算機のプログラムも同じものなんだが。
書かれた順に行うからプログラムでも無いよ。
紅組優勝の場合は○○、とか、もっと言っちゃえば午前中に雨が降った場合、午後のこの演目は土が乾くまで他の演目を先に行う、なんてのも運動会のプログラム。
それを読んで行う>>415の半分は「スケジュール」。ジョブスケジューラがやるべき事。

>>448
それってHaskellの意味あるか？逆ならわかるけど

どっちにしろ式だの文だのは関係ない話やな。

F#に型クラスさえ導入されればHaskellなんて見向きもしないのに

>>452
コンピュテーション式あるだろ

>>448
ずっとIOかStateの中に居ればいいと思うよ
do記法が副作用すなわち手続きを自動的にモナドに変換してくれるよ

あれはモナドか

Haskellの型システムを理解できていたら副作用ガンガン使えるよ
型システムをいちいち気にしないやつはPythonを使えよ

>>449
どうでもいいがラテン語かね？
普通ラテン語で、書く、となるとscribo、（略）、、scriptumじゃね？

>>457
ごめん、思い切り間違えた。希だな。

>>454 >>456
そういうのを取っ払って使えるようにして欲しいのよ
型クラスとかdo記法も隠蔽してシステムの方で勝手に管理してくれればいいじゃん

ぶっちゃけhaskell使ってどんくらい開発効率上がるか知りたい。
railsみたく10倍開発スピード上がるって文句のフレームワークでないのかな。

個人的にはgolangのgoaがそれに匹敵する気がする。
webpaiに特化したフレームワークでswagger.jsonも吐いてくれる。
クライアントライブラリまで自動生成できる。

プログラムを作る事と使う事の
区別が付かないやつ多数発見

むしろ、作る事≒使う事になっていくだろうな
ある意味先祖返り的な感じだけど
分けることが意味が無い方向に進んでいくと思う
やりたいことを思いついたら、それでプログラム完了したと同じみたいな

>>462
それはもうプログラミングとは呼ばなくなるんだよ
すでに通ってきた道

作る事と使う事の境界線が時代とともに移動することはあっても
分ける事に意味が無くなることはない
概念に名前を付けるというのは分けることそのものだから

概念に名前を付けるとか付けないとか、それ自体が意味が無くなるよ

人間は概念に名前がついてると、そいつの素性を知らなくてもなんとなく完璧に理解した気になるステキな特性を持っとるからな。
js界隈のFluxとか使い古しの技術の詰め合わせだし、disりの為の池沼、ガイジ、アスペらへんの言葉も同じ。
精神医学やら臨床心理学、障害者心理学やっても無いのになぁ、って思うわ。やった人間からすると。

もう、それって古い考え方だよ

ユーザーが作者に文句を言うことができなくなっていく
使う人≒作る人だから

意味がわかんない
使う人≒作る人だって、言えばいいじゃない

>>446
ごまかしって、今お前がやってる下手くそな例えのポエムで自爆してる事？

文や式云々は確かに俺個人の解釈の一つだ
で、それで？
いつまでもまもな解釈を提示できない時点で、意味のないレスと自分で反復的に証明してる用なもんだぞ

ちゃんと理解できてるか？知恵遅れ

>>444
Javaのライブラリが使えるのが大きい
ClojureがLispの中で今一番流行してるのもそこ

>>460
関数型言語で開発効率は
言うほど上がらないよ
上がるならもっと採用されてる

>>470
知ってる。知ってるけど、知った上で鬱陶しく感じてるんや色々と

言語で開発効率が上がるのではない
その言語を使いこなせるエンジニアだから開発効率が上がるのだ
流行に流されず手に馴染んだものを使いたまえ

それはちょっと違うな
言語の性質そのものが生産性を大きく向上させることはないのは同意するが、
その言語に習熟しているかどうかもそれほど重要ではない
最も重要なのは、学習コストを受け入れて生産性の向上を図ることのできるエンジニアは優秀なエンジニアである、ということだ

あと生産性については使い分けがあるな

関数型は記号処理が中心なら簡潔に書けるが
ゲームみたいな
状態遷移が中心の開発対象に向かない

あとCRUDとか定型的なアプリなら
ライブラリやフレームワークの方が
生産性の要素として大きい

結果メジャーなOO言語の方が使いやすい

言語で効率に差はない君の主張は「HelloWorld程度なら」という前提らしいので真に受けてはいけない

デマを真に受けるだけで効率100倍ぐらい悪化するよな
言語は変えてもせいぜい2倍程度だろう
だから言語の差は意味がないと考えられる

oO（アセンブラでアプリケーション全部書くのからはC++2011でも100倍は確実だと思うけど）

お前らは気持ちよくかけるオナニー言語が欲しいんだろ
普及するのは入りやすくて変化の少ない言語だろ

なのでどっちみち生産性とか実用性は無視していいんじゃないか

>>479
これなー
別にC/C++で実行速度も解決できるしほぼなんでもできるからな

言語で何をするかが重要なのであって案の定スレ開いてみたら言語の欠点じゃなくわけのわからんこと抜かしてるし

多分こいつら下の階層のプログラマーじゃないだろ

というか下の階層にいたらこんなスレ開かないか
めんごめんご

>>477
>>478
100倍は大げさ
機械語と高級言語だったら100倍ありそうだけど

アセンブリとCで10倍くらいかな
アセンブリとC++で20倍くらい？

まあ確かに普段何のプログラム書いてんだよってのはかなり重要かな。

アセンブリとRubyなら15倍くらいかな

そもそも次世代ってどれも対して変わらんだろ。GUIでプログラミングとか今までにない要素ぶち込むならまだしもどれも劣化python/C++じゃん

java/kotlinなんか仮想化すんなら別に言語javaである必要はないしな
次世代取りたきゃandroidみたいにほぼ強制的にやらせればいい

よってkotlinだろう

このスレは終わりである
完

うぉおおおおおおお
議論スレの終わりを初めてみた!!!!

今北産業

>>488
次世代は
javaの進化系
スレ完

記念パピコ

俺が自演してるみたいに思われるだろ
やめろ

自演パピコ

>>485
＞今までにない要素ぶち込む
じゃVR/AR/MR or（amazon Echoみたいな）スピーカーデバイスだけで
プログラミングできる言語作れと？
確かに次世代っぽくはあるかもねｗ

どう考えても次世代はルーストだろう

他言語もそろそろRustのぱくりを考えているだろう
例えば参照カウントが2以上なら例外を投げるだけの機能

Rustが色んな意味で新しい事は確かだ

VRで作業は少しアリかもしれんけどな。単純に視野的に。
Oculus買ったけど、Unityでアプリのウィンドウをキャプチャしたものを浮かべてたくさんの仮想ディスプレイのようにして遊んだけど楽しかった。NASA感ある。
でもキーボードとトラックボール以上の入力装置は無いな。空間をつかむって思ってるより難しかったわ。

でも何より熱いのと、その仮想ディスプレイを浮かべる部分作る作業は酔う。

キーを押した感覚とかフィードバックがないとな
タッチパネルの課題としても研究してる人いるけど

良く知らないんだけど、関数型の言語って関数を動的生成してるんだろうか？
C++のラムダはしてないけど

そんなことしなくても推論したシグネチャ通りの関数をコンパイル時に生成すれば十分。

クロージャとか関数オブジェクトはそう簡単にはいかんくね？
C++だと結構ダイナミックに引数変更してくるし