次世代言語15 Go Rust Bosque Kotlin TypeScript
■ このスレッドは過去ログ倉庫に格納されています
スレタイ以外の言語もok
前スレ
次世代言語15 Go Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1541331010/ 「ただの」と言い切ってしまう感性のやつはプログラムをやらない方がみんな幸せそうだと思うよ。 手続き型でコードをたくさん書くのが幸せと感じる、個人の趣味と混同するようなレベルの低いプログラマーとは
いっしょに仕事したくないね >>305 どこが? むしろ COBOL の方が冗談きついだろ。 COBOLは何十年前のコードがそのまま動くし
今書いたコードが突然非互換アップデートで死ぬ心配もない マシンには読めても人には読めなくなる。マシンが読むには不要な意味や意図が読めないのなら、そのシステムは進化も変化もできなくなる COBOLが悪いんやない
設計も実装もできない趣味で手続き型量産してる>>302みたいなガイジがCOBOL書いたから悪いんや >>307 全くどうしようもない奴だな。 誰がCOBOL で書かれたシステムをメンテナンスするんだ?
COBOL なんて老人ホームの人間しかメンテナンス出来ないぞ。 少し強調しすぎたが。
言語と言うのはどんなニッチな言語でもかなりの期間は使い続けられるが、それをメンテナンスできる人間が継続して育つかと言うのとは別問題。 COBOLはついこの前まで原発を動かしていた
メンテナンス出来る人間は一応いる
というか今でも日本のどこかで動かしてるんじゃないの? というか今でも日本のどこかで動かしてるんじゃないの?というのは原発のこと >>311
COBOLなんか誰でもできる
不足しているのはCOBOL工ではなく、メインフレームを運用できる技術者
オープン系より遥かに難易度が高く、高度な修練が必要とされる職人芸の世界 >>311
python2とかRuby1.xとかPHP4とかのメンテは
人が育つとかの次元じゃねーぞ 今から本気の本気でscala勉強しようとする人はいるのか?
しかも超優秀で使い物になる人で >>315
cobolのシステムより価値がなく
cobol並にレガシーな言語
悪夢だわな >>317
COBOLは言語処理系自体が消えるとかは
無いのでそこはちょっと違う コンテキストによって使えるAPI制限できる言語ってありますか?
割込みコンテキストとかイベントループでsleep禁止のような >>319
言語自体に?聞いたことない
というかコーディングルールで決めてLINTみたいなもので自動チェックさせるんじゃない? あとはRoslynのAnalyzerはめっちゃ強力で自由度も高い コンテキストってのを明示的にsleepに渡すのがセオリーだよな
つまりsleepの引数を一個増やす
ただしコンテキストの捏造はないものとする
その型のコンストラクタ使用禁止
同じ型の変数定義禁止またはその変数への代入禁止や所有権移動禁止 例えば英語圏の外の人がいくら勉強しても英語のセンスがないとか
英語の本格的な発音を聞いただけで笑ってしまうとか
感性とかセンスとか言ってる場合じゃないだろ >>104 Python 実装系の一つ PyPy は、静的型付けの有る RPython と言うPython のサブセットで書かれている。
RPython はC のソースコードなどを吐き出す。 しかもJIT で動く。
概ね、PyPy は、CPython (本家のPython) より4倍くらい早い。( JIT の効果 )
RPython で作られたRuby実装 で Topaz が有るが早いみたい。(実験的に作られただけ見たい)
同じくRPython でPHP実装 も作られてる。 つまりCってことなんだよな
なら最初からCで書けって話になる >>327 最初からCで書いた実装が、CPython なんだよ。
それよりなぜ早くなるかと言うと、VM 上でJIT が動くからだよ。
PyPy がインタプリタとして動くときは、C のコードを吐き出すんじゃなくて、バイトコードを吐き出し、そのバイトコードをVM 上でJIT が動かしている。
CPython もバイトコードインタプリタなんだけどJIT で動いていない。 その一部をJIT で動くようにしたのがNumba >>319
そういう問題を技術で解決しようと思うのが間違ってる。
322の意見のようなクソシンタックスを無駄に増やすだけだから。 >>330
こういう極論言うバカにコードを触らせるなということ。 冗談抜きにほとんどの事例において「バカにコードをいじらせない」が
ベストソリューションなケースはかなり多いのになんで採用されないのかね? >そういう問題を技術で解決しようと思うのが間違ってる。
こういう極論? 今現在では極論じゃなくて正論だと思う
精神論じゃなくて技術や設計で解消ということではないかな
コーディング時にsleep自体禁止しても他のメソッド内でsleep使ってたりするのを避けたいのかもしれないけど
もし外部の言語で作ったDLLで使ってたりするとわからない
内部で動的にコード生成してたらすり抜ける(そもそもこれはアウト)
sleep単体だけならいいけどあれこれ禁止するならシグネチャーが複雑になる
結局あっても頼りきりにもできないけどめんどくさい制約にしかならないと思う だってジャップランド土人村にはその「バカ」が9割じゃん ユーザーからぼくの考えた最強issueがガンガン上がって来ていらない機能がどんどん追加されて
学習コストが高いだけの誰も使わないクソ言語 しかし、バカ予備軍こと質問者が現れた時点で早くなんとかしようと思わなかったのかね
それらしい答えが出てから慌てて文句言っても遅い 一応JavaのSecurityManagerでできるけど
信頼できないリモートコード制限用の機能だから
普通のアプリじゃ使いにくい >>319
基盤実装とスクリプトに分けるとかは?
スクリプトに対してはいろいろ禁止できるかと >>340
どんな感じで禁止できますか?
静的にみつけられるでしょうか?
例を教えてもらえるとうれしいです。 >>341
単純にスクリプトにsleep APIを公開しない、みたいなのを考えてた なるほど・・・
しかしスクリプト側で使用可能APIを一括で管理ってできるでしょうか?
例えば仮にPythonだとして標準のライブラリのimport禁止など可能なんでしょうか? luaはそこらへん簡単でredisとか標準ライブラリが割と無い
python組み込みは詳しくないけど可能そうなもんだけどな いずれにせよ、そういう言語ってなさそうですね。
仕事でリアルタイム系のシステム組んでいるのですが、sleepしない、blockしないとか、
他にもdead lockしないとか、定期的にこれらのルールをやぶるコードが紛れるので
なんとかならないかと思っています。
静的解析のツールで解決できたりするのでしょうか? 並列性とか非同期性がそういう問題の根源なので、
直列実行しかできないスクリプトに切り出して、
基盤側を単純にしたらいいのではと思ってしまう
リアルタイム系の経験が無いからよくわからんけど 明らかにsleep呼んでる側がおかしいのにsleepの内部で何か対策考えるとか
それがバカだって言ってんだよ。
そういうのを解決しようと思えば最終的にグローバル変数から状況を読み込んで
「いい感じに処理する」みたいなクソなことがまかり通るようになる。
こんな当たり前のことを「精神論」とか言って遠ざけて
無駄な技術をゴテゴテ投入すれば解決すると思う方がよっぽど精神論だわ。 リアルタイム系ならそもそも言語の選択肢が殆ど無いような 外部ツールで特定の処理を呼んでないか調べる位しかできないだろ >>348
はい、普段C/C++なんですがもう卒業したい気分でいっぱいです・・・
実はRustはもしかしたらという気持ちで質問させてもらいました。(Rustの詳細知りません)
原理的には型システムで解決できる問題のような気がするんですけどね 何がもしかしたらじゃボケ
そんな甘ったれた根性を次世代言語スレに持ち込むな ひーイェッサー
お言葉ですがその調子だとMicroPythonに逃げられるっす
(リモコンそんなので作られた日には電池持ちがおそろしいことになりそう) >>352 もう少し他の人にわかるように話してくれないかな。 少し興味のある言葉が出てきたので。
micro:bit か何かをリモコンとして使おうとしてる? わかりやすさの基本は嘘を書かないことだ
それ以外のことを改善しても誤差程度にしかならん >>321で出てるけどRoslynでできないんかな? 最近の話の流れは、 >>345 の続きかな?
>>345 RTOSは使ってるんでしょ?
MicroPython なんて持ち出してるってことは、RTOSを入れていない?
RasberryPi だと、RTOSとして RT Preempt なんて使ってるね。
RTOSを入れていればそれほど言語に厳しい制約をかけなくてもよさそうな気がするけど。
このサイトを見ると似たようなサイズのアプリケーションに、RTOS(Zephyr)(ゼファーと読むのかな)をいれてMicroPython で動かしてるね。
https://open-degu.com/downloads/20190315_degu.pdf
Zephyr入門
https://qiita.com/ueba/items/c5fe99bedd8862854ebd
OSサイズは11KBとコンパクト
PyPi にもラッパーが登録されているのでPythonからも使える。
日本だから、μT-Kernel(μITron)が普及するとよいと思うけど。
μT-Kernel 2.0がベースのIEEE 2050-2018がIEEE標準として正式に成立
https://www.tron.org/ja/2018/09/press0911/ await asyncが使えればsleepでスレッドをブロックしないのに 割り込みハンドラの話だろうからawaitの仕組み(イベントループ+コールバック)でどうにかなるものじゃないと思うよ >>360
Pythonの話にはのりましたが、実際にはスクリプトでそのあたりの処理書くのは採用できないです
GC走る言語はsleepされるのといっしょですからね
Roslynってのは知りませんでしたが.NET限定の技術なんですかね? >>363
RoslynはC#/VB.NETのコンパイラー
DiagnosticsやRefactoringのAPIも提供してて、簡単にAnalyzerを書ける 既に上がっている次世代言語のスコープではなく
そのような要望を満たすものがない 新しい言語を一通り触ってjavaScriptかC言語に戻ってくる
C/C++とか書く奴いるけどC++も大概クソだからな
結局Cでできるように書き直したほうが簡潔になるっていう Cに戻ると言いながらJSと二刀流してるだろ
二刀流が正統派にでもなったら革新的じゃないか >>363 自分でgc をenable disable にしてコントロールしたり、gc を自分で呼んで(collect) 明示的にgc を起こさせるのいうような方法でリアルタイム性は確保できるんじゃないの?
MicroPythonですらそれらの方法が利用できる。
沢山のIoT デバイスで使われてるだろうから、GC が勝手に動く心配をする必要はないように思うけど?
例えばRTOS Zephyr では、main thread とidle thread で区別してる。 俺かっこいいはポジティブ思考
リーナスはネガティブ思考のくせに建設的だぞ >>367
C言語にデストラクタ的な機能が入ればすごく嬉しい。 >>373
リーナスは人間的にはだいぶクソな奴らしいが
技術的な意見についてはさすがにおかしなことはいってない
カーネルレイヤーにC++が相応わしいかというとたしかに微妙だ
だが、アプリレイヤでC++でなくCのほうが良いというのはただの勉強不足 「神がいないと言うのは勉強不足。もっと勉強しろ。そうしたら分かる」 足りないのは勉強でも努力でもない
勉強でも努力でもない何かが存在することくらいはすぐ分かりそうなものだが
必死に勉強したらしいのに分かってない奴がそこにいるのが証拠だ Linus と Unix を掛け合わせて、Linux にしたんだな。
良いネーミングになったけど。
昔々、安価に使える記憶媒体が5’ のフロッピーディスクしかなかった頃、初めて取り寄せたUnix は、512KB のフロッピーディスク12枚に入って送られてきた。
6MB だよね。
その頃からCがもてはやされ始めた。 C もUnix も基本はシンプル。 >>374
それだったらgoのdefer文入れた方がいいわ。
デストラクタはcには馴染まん。 リーナスの持論からいくと、メモリ管理を手のひらでコロコロできるレベルの低レイヤーが触れない言語は等しくファックなんだよ
つまり次世代言語は まあメモリ管理を隠蔽しようとするからおかしなことになってる感はあるよな 人類の95割はメモリ管理なんてできんだろ
GCのコストをペイできるほど高速でファックな処理なんて人類の95割には必要ない >>381
linusが主張してるのはOSみたいな低レイヤーいじる時だけの話だぞ。
c++みたいにどっちもいけるわー言ってどっちもクソな物を嫌っとるだけ。 gitは低レイヤーじゃなくね
上のリンクにもあるけどlinusは前提条件無しでC++嫌ってる まぁ昔のc++に酷い目にあったら、そりゃ嫌になるよ。 最近のC++はメモリアライメント指定が標準になったりゴミだったアロケータ周りがだいぶ改善されてるから組み込みとかにも使いやすくなってるんじゃないの >>383 1桁桁を間違えてるぞ。 よくプログラムが書けるな。 レイヤーっていうかカーネルとGUIを分離しないのはSmalltalkとかObjCとかの伝統か? LinusのC++嫌いには↓みたいなこともあるんじゃない?
C with classesだったのに
よってたかっていじくりまわしてあんなわけわかんない仕様になった 議論をする理由は、嫌っているからではなく、言いたいことがあるからじゃないか
嫌ならC++使わなければいいだけ
だが、言いたいことがあるなら言うに決まってる 使わなければいいはその通りだが
あいつらは人に使わせようと押し付けてくる圧が半端ない LinuxをC++で書き直せっていう意味不明な圧力をかけてくる馬鹿が数万人から数百万人規模でいて
そいつらに会うたびにC++、C++って言われるんだろ
誰だって切れるだろ 怒るのは人を動かす最適な手段ではないということを学んだだけで
別に中身は変わってないだろう多分 OSの仕様も自分で作ったんじゃないだろ
コピーレフト実装
述べて作らず 言語関係での近年の快挙は、LLVM の成功だろうな。 ■ このスレッドは過去ログ倉庫に格納されています