将来性ないプログラミング言語。Delphi含まれず安心
■ このスレッドは過去ログ倉庫に格納されています
5 Programming Languages That Are Probably Doomed https://insights.dice.com/2019/07/29/5-programming-languages-probably-doomed/ Ruby Haskell Objective-C R Perl Objctive-Cはさすがに役目を終えつつあるしな Rubyは意外に流行らなかったな Haskellは・・どちらかといえばOcamlの方がやばいと思うんだが R シラネ perlはさすがにもうないな ただ、PythonとRubyなら、後者の方が見やすいと思う。 Pythonはブロックの終わりが分かりにくいことが間違いの原因に 成り易い。上の方のどこかのブロックの中に入っているのか、 それとも関数の基底の部分で書いているのかの判別にとても時間が かかることがある。特に他の人が作ったソースの場合。 Pythonは1関数、50行の制限をつけるべきだろう C/C++ や Ruby なら、} や end の個数が一目瞭然なので、余りネストが 深くなければ、今見ている行がどのブロックに入っているのか分かりやすいが、 Pythonだとネストが浅くてもどのブロックに入っているのか分からないこと がある。 >>6 Pythonで内部関数(?)を大量に書かれているソースの場合は特に、 親の関数の中なのか、内部関数の中なのか側から無いのでかなり 判読に時間がかかる。しかも間違ってもエラーが出ない。 宣言しなくても変数が使えてしまう事と相まって、処理系に 間違いを検出して貰える確率がとても低くなってしまっている。 バグを防ごうと思ったら、結局、ブロックの終わりをコメントで 明示しないといけなくなって、なら最初から { } 方式の方が 記述効率が良い。 >>8 誤:親の関数の中なのか、内部関数の中なのか側から無いのでかなり 正:親の関数の中なのか、内部関数の中なのかが分から無いのでかなり 大丈夫。25行程度なら、ひと目で どこがどこに対応してるかぐらいわかるだろう >>10 現実のソースは1関数が何百行になっていることが多い。 自分で書いたソースではない。 RはPythonに置き換わったしな てかググれないのが致命的w バイオインフォマティクスでは Bioconductor のおかげで R もよく使われてる >>13 Dは1.*の時代に今の仕様にあがってればいけてたと想うんだが... >>8 関数と関数の間は〜2行開けるとか、 結局のところ書き方しだいじゃね。 > 関数と関数の間は〜2行開けるとか、 なぜPythonはそれを強制しなかったのか? 書く人によってばらばらになって読みにくいではないか(笑) 「インデントでブロックを表すという文法」というだけなら (書きづらいの別として)そういう文法ってだけでいいんだが 「インデントでブロックを表すからコードが統一され可読性が上がるうんぬん」は眉唾 言語で矯正されないとインデントできないレベルのやつがインデントが統一された程度で コードの可読性が上がるわけ無いだろう >なぜPythonはそれを強制しなかったのか? 強制ってわけじゃないけどpep8ベースのリンターでチェックしてくれるからそれで十分じゃね emacsでもブロックを可視化してくれるけど そこに頼らないといけない時点で問題あるわな clispなんかは必須だけど > そこに頼らないといけない時点で問題あるわな どんな問題? ギド・ヴァン・ロッスムなんて無名の雑魚が設計し、名前もキモすぎる杜撰言語Pythonが 何でこんなに流行しているのか。 ロブ・パイクとケン・トンプソンという大物が入念に設計したGo言語がインタプリタでも 提供されれば、Pythonは終わるだろ。 ∩___∩ | | ノ\ ヽ | / ●゛ ● | | | ∪ ( _●_) ミ j 彡、 |∪| | J / ∩ノ ⊃ ヽ ( \ / _ノ | | .\ “ /__| | \ /___ / >>19 Pythonの場合、空行があると余計に分かりにくくなる。 何か文字がないてないと上の行のindentと同じが違うかの 区別が人間は勘違いしやすく、むしろ詰めた方がまだ分かりやすい。 だから、C++などで空行を空けて分かりやすくすることに慣れた人には 困った言語だと思う。 >>27 誤:何か文字がないてないと上の行のindentと同じが違うかの 正:何か文字が書いてないと上の行のindentと同じか違うかの aaa bbb ↑だと同じインデントに書いてあるとすぐ分かるが、 ddd aaa bbb ccc ↑こんなふうになっていると間違うことがある。 というか、ここに書いても多分、伝わらない。 実際の他人が書いたPythonのプログラムはブロックの範囲が分かりにくくて とても困るんだが、実際のソースを提示しないと分かって貰えないと思う。 これに関しては想像と実際で結構違うと思う。想像力の限界というか。 あと、自分で書いたコードでも、他の場所からコピペして少し修正して 使いたいようなことが良くあるが、その時にインデントの問題が出てきそうだ。 コピペしている途中に、ペースト先の以前のコードのブロックの範囲がどこだった か非常に混乱してしまいそう。実はC/C++でもペーストした後、ブロックの範囲が インデントを整え終えるまでの間は、ブロックの範囲の混乱が起きることが多い。 でも { や } の位置を頼りによく見て対処するしかない。 ところが Python の場合は、{や}がなくてインデントだけが頼りなので、 より危険度が増すと思う。 (一時的な)コピペでインデント変えたくない時は if True: 使え そもそもコピペしまくる香具師はセンス無いわ 剥いてないから辞めた方が良いマジで邪魔 >>33 いや、現実世界では、オイラのプログラミングの能力は物凄く高いと 評されているのであしからず。 >>34 類は友を呼ぶから、お前の周りもお前同様にレベル低いんだよ ドカタ世界で王様気取りウケるw >>39 その会社のその部署には(日本の中で)上辺の非常に一握りの人たちだけがいると 言われていたよ。別の会社からやってきた社長も最高レベルの人材が 集まってきていると言っていた。 まこなり社長が「とりあえずRubyやっとけ」とか言ってたの笑ってしまうw インデントが違ったらブロックのレベルが違うで十分だと思うけど 画面内に{}やendが見えててもインデントがむちゃくちゃみたいなプログラムのほうがよほどわかりにくい 他人が書いたJavaScriptとかいややわ〜 Ruby の新しい本が、一杯出てる。 独習シリーズも、Rails 本に参入した WEB+DB でも、RubyVM の作者、Cookpad の笹田耕一の連載が始まった WEB+DB Vol.111 号では、Rails 6・Julia の特集 科学技術計算用のJulia は、Ruby に似てる。 Python から、Julia に流れそう >>43 ブロックを識別するのにインデントと{}は、両方必要。 どちらが欠けても駄目。 >>43 {}やendは機械的に正否判定できるけど、インデントだと無理じゃね? ide支援が拡充していく現在の状況では弱点だと思う 機械的に正否判定できるからPythonが動くんだろ 機械的に成否判断できないから、Pythonにはインデント整形ツールがないんだろ の間違いでは? インデントだけでも機械には判断できても、人間は間違いやすい。 まあ、人並みの知能があれば間違えないけど、こればっかりは地頭の差がでるからねぇ あ、もしかして、Pythonが知能の高いAIやってる連中に流行ってて 底辺ドカタにいまいち人気が無いのは、インデントの所為? >>52 ライブラリを作る側の地頭が良い連中は気にしないから ライブラリがどんどんリッチになって行くんですね、分かります >>53 な?お前の話から大部分のライブラリを使う人の話が消え去ったやろ? そんなもんやで ライブラリやフレームワークが有るからその言語を使う。 Rubyを使うのはRailsがあるからやし、 Pythonを使うのはAI関連のライブラリが有るからやし。 Unityとか.NETとか、ウェブで使えるのはJavaScriptしかないとか 言語の良し悪しで決めることなんて無いんやで >>51 一応、メンサ会員になれる程度を遥かに超えるIQは持っていますが、Python のブロックの記法は間違いやすいと思っています。 >>55 Pythonなんて今のAIブーム来るずっと前からシステム周りのツールで使われてるやん JSのインデントというかブロックがわかりにくいのは、コールバック関数を多用するからだと思う JSはコードのフォーマット次第でコールバック関数のインデントがずれる ずれるという証拠を見せてください beforeとafterを書いて SQLもインラインテーブル使うと中のインデント狂うな 普通、C/C++などで関数呼び出しで引数が多くなったりすると、二行に 書くことになる。 そういった場合、Pythonのインデントの問題がトラブルの原因になったり しないのだろうか。 少なくとも、関数の中に内部関数を定義すると、物凄くPythonは読みにくく なることを他人のソースで経験した。 >>66 そうか? その辺の読みにくさはJavaの方が酷いぞ >>67 Javaでブロック範囲が分からないと思った事は一度も無い。 Pythonだと関数やブロックが立て続けに終了した場合、見た目で 訳が分からなくなり、解読に間違いが入り込みやすい。 ある命令が子関数の中に対するものだと思っていたら、親関数の 中だったり、逆だったりする。 ループのブロック、ifのブロックとの混乱も生じる。 ifブロックの中だと思っていたら、既にそれは終わっていたりする。 また、もうifブロックは終わっていると思っていたら、まだ 続いていたりする。 ifブロックの中に、さらに入れ子に何らかのブロックが入って、 それらも何個かが続けて「終了」した場合も、非常に混乱して 他人のソースの解読が難しくなる。 忘れたけど、実際にはもっと空行が入っていたり、命令数も多かったり、 内部関数も何段にも入っていたりするが、以下を見れば分かりにくさが分かって もらえるかもしれません: if ・・・ if ・・・ for ・・・ aaa bbb ccc >>70 実際には、もっと行数が多くて if や for 命令が画面内には表示 できなくて、エディタでは(見えない)画面の上の方にある。 上記の例だとまだ画面内に表示されているので良く見ると分かるが、 画面外にあるとずっと解読が難しくなる。 ロジック以前にブロックの範囲の読み間違えが生じてしまう。 C/C++ だと、画面範囲より上の方に if や for の始まりの部分があっても、例えば } } aaa(); ・・・ } bbb(); のようになってくれるので、aaa(); という命令がどのブロックに入っているのかは 分かりやすい。ところが、Pythonだと、以下の様にようになる。 aaa(); bbb(); これでは、ブロックが何回「終了」したのかも分かりにくい。 >>66 そりゃその他人の問題だろw わかりにくく書くのはどんな言語でもできるし Python信者「関数が長いと見にくいので次第に短い関数を書くようになるから教育的に優れている」 C/C++ の場合、三回ブロックが終わった後に aaa が書いてあると分かる: } } } aaa; Pythonの場合、以下の様になっていて、画面上のaaaの先頭に「定規」でも付けて エディタで上にスクロールして、ifやforや内部関数定義の冒頭(defかな?)などを見つけて どこと一致してるか確認してから、下にスクロールして意味を考えないといけない。 aaa; >>74 でも同じロジックでも、C/C++やC#やJavaやRubyで書いてあれば ブロックの範囲で悩むことは無かった。だから書き方の問題ではなく、 言語そのものの設計の問題だと考えられる。 他人のプログラムのロジックの難しさで悩むのはしょうがない。 しかし、ブロックの範囲がそもそも分からなくて悩むのはPython特有で 今までの言語では無かった悩みどころが入ってしまった。 定規とかアホすぎ 上下移動でカーソル位置は横に移動しないエディタとか 縦に補助線引けるエディタとか使えよ (もちろんそこまでしなくても読めるが馬鹿には必要な機能なんだろ) >>79 ちなみに、自分の IQは、メンサ会員になれるよりだいぶ上です。 まず、 if if for の入れ子とかおかしいからな こんな作り方しないよ >>81 そんなことないです。 その位は普通に有りますし、悪いプログラムでも汚いプログラムでもは有りません。 問題はソースの方にあるのではなく、Pythonの設計の方にあります。 じゃあPythonを改善したスゴい言語でも作れば? IQ高いんだろ 他のメジャーな言語はだいたいカッコか、そうでなければendとかfiとかキーワードでブロック作るもんな Pythonだけじゃん キスしてイチャイチャしたいだけでしょ スルーでいい >>1 で将来性のないプログラミング言語筆頭にRubyが挙げられてることから目を逸らしたい幼稚な工作でしょwww Rubyの未来は ウォウウォウウォウウォウ 世界が羨む パイパイPython >>80 統合失調症かよ ム板って何でこんなやつが多いんだ VSCode の拡張機能、Bracket Pair Colorizer, indent-rainbow などで、対応関係がわかる WEB+DBのJulia特集を読んだ http://medfreak.info/?p=4850 漏れも、同じ意見 Python ではプログラミングしづらいけど、 Julia は、do 〜 end など、Ruby に似てるから、プログラミングしやすい やっぱり、外人も同じように思ったから、Julia, Elixir などが作られた! Juliaは、Pythonのライブラリも呼べる NumPy がいらない。 ベクトル演算・行列積・線形代数・統計処理などが標準装備 LLVM のJIT だから速い 今後は皆、Pythonから、Juliaに流れそう >>94 >VSCode の拡張機能、Bracket Pair Colorizer, indent-rainbow などで、対応関係がわかる 解決策ありがとです >>94 漏れも、同じ、意見。 Rubyは、廃れる! VB6までが無い Perlが挙がってるのが個人的には不思議 >>43 その通りだな。 インデントが無茶苦茶でも通るからロジックのまとまりがどうなってるかわかりづらい。 仕方なく自分でインデントを整理するが。 ま、どんな言語でも作ってるやつがクソならクソなプログラムになってる。 時々イラっときて作り直した方が早い。 >>66 () {} などで括られた中はインデントを気にしなくても良い。 >>86 あのさ、そんな些細な事より、{} で括るとか、 if fi とかの方が余程コーディングの手間が多いぞ。 1タッチでも少ない方が良い。 そもそも、Python はスクリプト言語だと言うことを無視して話してる。 その都度実行されないといけないんだぞ。 間違えるわけがない。 書くのは一回、読むのは数十回 たった一回書くのが楽なことよりも 何十回も読むのが楽な方を選ぶ Perlに依存してるパッケージが減りつつあるような気がしないでもない >>101 何十回も試行錯誤して、採用するのは一つという世界がわからない? 何十回も試行錯誤してる。 その間、何十回も読んでいる。 うちもそうだけど知ってる範囲じゃperlはもう書かせない会社ばっかりだな 弱小うんこwebドカタ仕事専用のRoRのシェアが落ちてきたって本当ですか? まぁ一番将来性無いのは勉強止めた奴だけどな。派閥抗争ごっこする位なら新しい言語の一つでも覚えりゃいい。 保守はしたくないけどプロトタイピングにはいまでも有用 なんだかんだ文句いいながらも使えるひとが多い pythonのインデントでブロック作るのホント嫌い ちょっとした入力ミスでインデントがズレると死ぬ あれのせいでワンライナーを半ば強制されてるようなもので チューニングはしづらいし、可読性は下がる >>116 に対する反論。 俺の会社の奴らはインデント矯正されないと インデントめちゃくちゃにする。 可読性はもっと下がる。誰のせいか? 普通のプログラミング言語なら push 時にインデントチェックして拒否したり自動整形するようにできる python みたいなインデントでブロック作る言語はダメね >>117 フォーマッタ使えばよくね??? インデントが狂っても静的チェックでエラー出ないからバグの温床になるし 長くなったコードを改行するときにもインデントが必要になるから区別がつけづらいし ラムダ式書く場合も内容が複数行に渡る場合は関数内関数を定義する必要が出てきてこれがまた書き難いし読み辛い インデントブロックは俺も最初は見やすくていいじゃん!って思ってたけど 使い込むうちに不便な側面の方が強くなってきたわ インデントでブロックを作るやつはデバッグとか 動作検証したいだけってときに面倒だよね 自分で手書きするときはインデントするし 最終的には綺麗にするんだけど、 一部のコードをコメントアウトしたり 動きがわからんから、一部分抜き出して動きを見たりとか そういう作業中のじゃまになる。 >>117 emacsならC-c C-qでもいいし他のエディタも整形機能ついてるのあるんじゃないの pythonはエディタが特化してないとどうしようもない インデントだけで管理しなきゃいけないってのは悪手だ 経験上、インデント面倒臭いというやつのコードは汚い >>123 (上級者は)インデントするのが面倒くさいって言ってるんじゃないからな。 デバッグや動作検証などの一時的なコードまでインデントするのが面倒くさいって言ってるんだからな。 すぐ消すようなコードまでインデントする必要ないし 後で消すときに目立つようにあえてインデントを崩してる。 インデントと論理構造の一致が不要という人もいるだろうし コードはすべて大文字で書くべきという人もいるだろう コーディング規約の一貫性は不要だという人もいれば レビューは工数の無駄だという人もいるだろう そういうレベルのお話よね インデントとカッコで同じ情報を表してるんだから冗長なのは事実 知能が高いと冗長さは単純に無駄だが、低脳ドカタには冗長さも必要ってことだよ インデントとカッコが同じ情報だと思ったことがPythonの敗因だろうね インデントっていうのはスペースと同じなんだよ。 コンピュータからすれば意味はなくて、 人間が見やすくなるように人間のためのもの 意味がある情報だけで言えば、スペースは要らない カンマや演算子の前後にスペースは要らない 関数の引数だって,のみスペースは禁止にしたってよかったはずだ。 でもそうしなかったのは関数の引数を区切るカンマと 見やすくするためのスペースは別物だから Pythonは見やすくするためのインデントを意味と共通化してしまったから 見やすい記述に制限ができてしまった。 >>128 それに、ブロックの終了の記号が何にも無いのは明確さがなく、 ケアレスミスの元となる。レイアウト的なものは、空行を入れたり 少し違う業や関数からコピーして来たりするときにずれ易い。 ずれたときにブロックの終了記号があると助かる。 >>127 逆に助長性は安全性に繋がりやすい。例えば、C/C++の最後のセミコロン";" は無くてもコンパイラがその都度推定できる可能性はあるが、 有った方が確実だから有る。Rubyなんかは無くても分かるときはなくて良い 仕様ではあるが、大規模プログラムではそれが見つけにくいバグの原因に なる可能性がある。 >>127 文系の人は、lexical(字面)的な読解力が頭の良さだと勘違いしやすいが、 そうではない。字面ではなく本質的なところが重要。字面的な判別能力 を自慢にしてる人は、短いが見にくい変な書き方をして結局本人も間違う。 >>127 ちなみにおいらは、客観的に見て低脳ドカタではない。 高IQ、高学歴、高実績で評価は高い。 理系の短いは実行する行が少ない(定義文や空行は含めない) 文系の短いは書く量が少ない >>128 C/C++において、関数の引数を二行以上に渡って書きたいような時、 インデントと意味は、有る意味ではずれる。しかし、それぞれの引数の後ろに 一つずつコメントを書きたいようなときにはそのの書き方は見やすい : func( aaa, // これこれこういう意味。 bbb, // TYPE *pXxxx ); また、ターゲット別に #if #endif などでコードを変えたいような場合は、 インデントの関係がどうしても崩れる場合があるし、その場その場で マクロに対するインデントを重視するか、C/C++言語に対するインデントを 重視するか、どちらがいいかは一概には決まらない。 #if xxx TYPE aaa; ・・・ #else ・・・ #endif ↑TYPE aaa; の部分に、#if ブロックのインデントを付けた方がいい場合と、むしろ、その場の C/C++ のブロック宣言としてのインデントの位置を維持した方が分かりやすい場合とが有り、 どちらも優劣付けがたい。 >>133 文系の人は、文章そのものの雰囲気的な美しさに美学を見出す傾向がある。 芥川龍之介の「表現技巧(?)」が素晴らしいとか、○○氏の詩的表現は 真似できないとか。 しかし、それをプログラミングに持ち込んで欲しくない。ここでもそういう 表面的な美しさばかりにとらわれている人が多い気がする。 上級者はコードの書き方に拘って 見やすいように、意味が伝わりやすいよに書くんだが 低級者は無意味に見づらく書く(本人は見づらいことがわかってない。そこまで気が回らない) そういう低級者にインデントのみ、書き方を押し付けることが出来るが どちらにしろ低級者なので、クソコードにしかならない 低級者には補助輪程度の役目にしかならず、上級者には足かせとなる そういえば、プログラミングにおいても>>134 の場合のように、関数の 引数を折り返して書く場合、どの程度引数の前に空白やタブを入れるべきかは 人間が見たときの「見易さ」で決まる。それは関数名 func 部分の長さに よっても変化し得る。そして、何が美しいかは「美学」「美術」の領域に 入ってきてしまう可能性がある。だからプログラミングは芸術とも言われる。 その意味で、インデントに論理的な意味を与えすぎると、芸術的な 美しさが得られなくなってしまう可能性は高い。 まるで自分が将来性が無いって言われてるように感じてしまって必死なんよ 年収3000万超えてからが上級やぞ それまでは低脳ドカタ インデントで話を散らかしてRubyの将来性>>1 から意識を逸らしたいだけw デルファイは言語じゃ無くて、IMEの名前じゃね? あれ、中身言語はpascalだよな? Rubyに将来性はないし、使ってる99.999%は低脳ドカタ pythonはインデントガーとか言ってる人ってメモ帳でソースでも書いてるの?w メモ帳以外で書いたら、勝手にインデント揃えてくれるんか? 例えば、他から持ってきた複数行のコードをコピペしたときに インデント=ブロック構造というコードの意味になってるんだから 勝手に整形してくれるわけないな ペーストしたとこからの相対でインデント維持しないん? >>149 秀丸とか使ってそう(^^;; とりまVSCodeかatom入れようよ(^-^; >>150 無理だろ? 例えばこういうコードに def repeat_msg(msg, repeat=3): for i in range(repeat): print msg 他のコードで使われてる、インデントが異なるこの2行をコピペして print foo print bar def repeat_msg(msg, repeat=3): for i in range(repeat): print msg print foo print bar に勝手にインデント揃えてくれるエディタなんて思いつかん そもそも実現可能なのか?やる方法があるにしても、どこからコピペを 開始して、どこに移動してから貼り付けるとかパッと出てくる? コピー先の最初の行のインデントの深さだけ決めてコピーしたら 残りの行のインデントも自動的に揃えられるだろ >>153 草 ちょっとは最新のエディタも触ってみようぜ >>154 残念ながらそれは無理。 def repeat_msg(msg, repeat=3): for i in range(repeat): print msg | ここで貼り付けをすると こうなる。 def repeat_msg(msg, repeat=3): for i in range(repeat): print msg print foo print bar >>153 >>156 ここでPythonのインデント云々って言ってる人はこんなレベルだったの? WEB+DB vol.111 は、Ruby on Rails 6, Julia 特集だけど、 Python から、Julia へ流れそう Julia は、do 〜 end が使えて、Ruby風に改良されてる! Jupyter Notebook(JN)でも使える Windows で、RubyをJNで使っている人は、日本語でバグらないの? irb では、バグるけど RubyをVSCode で使っているけど、JNでも日本語でバグらないかどうか、知りたい >>156 自分の周りにコピペプログラマーがいないからちょっとびっくりなんだけど こういうレベルの人が世の中に結構いたりするの?! >>156 しかもそれ他の言語でも同じだよね例えばcならこうなるけどカッコで対応とれてるからってそのままこういう風に書き続けるのかキミは?w void repeat_msg(char *msg, int repeat){ for (int i = 0; i < repeat; i++){ printf("%s\n", msg) } printf("%s\n", foo) printf("%s\n", bar) printf("end.\n") } 敢えてやるなら def repeat_msg(msg, repeat=3): for i in range(repeat): print msg if True: print foo print bar こんな感じ コピペの方がインデント浅い時とか長い時は別関数造って呼ぶ とりあえずpythonで書き慣れると他の言語が鬱陶しくて仕方ないねインデントに限らず プログラミング言語の完成形に近いと思うわ 恒常的に動くシステムのソフトとかでもない限りpython一択だと思うわ あ、GUIアプリは知らん わい氏、第1得意言語haskell、第2得意言語ruby、無事死亡 pythonの何が完成系なんだよ。 変数のスコープがあいまいだし、 参照かコピーかあいまいだし、 ライブラリと同じ名前のファイル名つけたら悲惨だし 結局あいまいだからちょっと複雑なものを作るとうんざりする。 完成されたライブラリにちょっとパラメータ変えて流すには便利ってだけの代物 >>160 ある機能を他でも使うから関数化しようかなーとかあるわけだが >>167 ちょっと複雑なものなんてお前には作れないだろ モッサリ鈍重ウンコwebサイトは複雑でもなんでもないからね? あいまいではないな。 仕様どおりだ。 仕様が変だという話かな。 Python, Ruby っぽい、Julia 関数型なら、 Haskell っぽい、Elm。 Ruby っぽい、Elixir >>167 まあ無能な奴は厳しい規則設けて檻に入れとくしか飼いならす方法ないもんなあ プログラミング言語も同じで草 Pythonは30行以内でささっと書くスクリプトには向いている。 それより長大なプログラムを書くには苦行でしかない。 年収3000万以上の開発者がPythonでAIを書き(もちろん30行以上ある)、 年収300万以下の低脳ドカタは世界の片隅で30行しか書けないとブツブツ言っている 3000行くらいでささっと、やね 10kL以下ならpythonだわ 10年くらい前、Lightweight languageとかって盛り上がってた時は型に縛られはないから、早く楽しくプログラミングできるとか言ってたのにのね >>178 まあ間違いじゃない。問題は歴史が浅く、大規模のアプリが作られてなかったことによる 結局大規模になって、作った人じゃない人がメンテナンスするようになると 途端に、型がないと大変ということに気づく。 先人の智慧や蓄積を無視して 若いのが俺カッケーした結果がこれか 10年前の静的型といえばJava全盛期じゃん そりゃ動的型の方が良いってなるよ 今と比べちゃいかんでしょ C++もいちいち型指定するのめんどくさいってことでauto乱発だしな >>180 知恵や蓄積の結果生まれたpythonの方が優位なのは明らかなのに先人様がそれを認めない結果がこれなんやで 結局、ケースバイケースなんだよな Javaが向いてるケースがあれば、Rubyが向いてるケースもある それ理解せずLL最高とか言ってたのが10年前のはてなブックマークのホットエントリー 10年前に書かれたRubyを保守しろと言われたら悲惨だよね XMLとかJSONとかテキストベースの無駄構造データ受け渡しを流行らせた糞も反省汁 バイナリでバッチリ敷き詰めて 更に圧縮したら効率がいいだろ! SwiftはObjective-Cよりも先に死ぬよ さすがにそれは無理がある SwiftUI出てきたあたりで切り離してもおかしくない頃合い 依存してる領域もあるけどなんとかするだろ >>144 俺はObjectPascal言語の開発環境の名前がDelphiだと思ってるけど 違うかな もともとObjectPascalという言語だったが 魔改造し過ぎでもはやObjectPascalとは呼べなくなったから、 これからはDelphi言語だーって公式が言ったけど、 やっぱObjectPascalに戻すわーって言ったのがDelphiが使われなくなった頃 >>191 IMEじゃなくてIDEな わざとだろうけど >>192 Delphiと呼ばれる前の ObjectPascalのIDEは Paradoxとか言ってなかったか >>167 python のスコープなんてもっとも単純だろうよ。 >ライブラリと同じ名前のファイル名つけたら悲惨だし こんなバカなことで困る輩はいない。 コピーと参照のあいまいさはまあわかるが。 Paradoxはデスクトップデータベース Accessみたいなもん ParadoxはObjectPAL ObjectPascalの前身かこれ? >>201 ObjectPALとObjectPascalは別物だと思うよ Access - VBA Paradox - ObjectPAL Filemaker - こいつのスクリプトって名前なんていうの? >>195 まああと少しの間は大丈夫だろうからすぐに他の言語を覚えた方がいい とりあえずJavascriptならもう少し延命できると思う もう少しどころか立ち位置的にCOBOL越え確実だと思う。wasm関連技術では完全代替はまだまだまだまだ難しい。 別に好きだと言ってるわけじゃないので変な勘違いしないでよね! あ、phpじゃなくてjsのことだぞ。phpはまぁ…頑張れ Pascal自体は死んで久しい Delphiが単独で頑張ってるだけ dolphinてなんや、、excelのイルカを出す、あのプログラム言語のことか、、 Linux用にそんな名前のファイルマネージャーがあったような。 >>211 >Dolphin(ドルフィン)は、KDEデスクトップ環境で動作するファイルマネージャーである。 >>214 [追加] Dolphinという名のAndroid用のブラウザもあるらしい。 haskellが入ってるのは絶対おかしい 俺がこれから使おうとしてるのにありえない この記事はフェイクニュース 現場のリーダーはJavaはセキュリティの事故で将来性はないと言っていた。大手の金融プロジェクトでも不採用の方向なんだと。 もしアプリローンとかでJava使っているところがあったら、問題おきてニュースになってもおかしくないだろう。 Perlは個人でちょっとしたものを書くのに最高なんだけどな。 数値と文字列を雑に扱いたいときもよしなに対応してくれるし、 厳密にコントロールしたけりゃそういう書きかたもできる。 Pythonで書くときみたいにstr()とかint()とかちまちましたくないんよ。 よしなにってのがクセモノなんだぜ きっちりエラー出してそれ以上先へ逝かせてくれないpythonマゾ大好き perl糞つかえねぇω → strict ルールで縛る 結局毎回ルール適用なら最初からpython使えよωωω strictは必ず使っているので変数宣言についてはPythonと同程度の手間が かかってもいいんだけど、一番違いを感じるのは文字/数値変換なんだよね。 Perlの場合変数の型ではなく演算子で演算を区別してるから Pythonのようにいちいち型変換する必要もないし、 JavaScriptのように演算の中身を知るために変数の型を確認する必要もない。 ちょっとした調べものとか計算ごとをするのに最高だよPerl。 そういうのをやりたいときはVisualWorks使ってる 納品物以外は全部これ 勝手に変換はタチが悪い tclでファイル読み込んでデータを加工して出力してると連続のはずのデータがたまに飛ぶ ??と思ってよく見ると、データがたまたま整数になってると整数の割り算になって結果が狂うということがあった。 これを避けるには結局明示的な変換が必要でだったら最初からそういう仕様でよい a = "1" + 2; // 12 b = 1 + "2"; // 3 機械学習の前処理でPerl使ってるわ 正規表現でユニコードなどを雑に扱えるのってこの言語くらい 他の言語はマジでやってられん書き方強要される Perlを使ってると、雰囲気でそれっぽく動くけど 実際バグだらけのコードを書く癖がついて、 プログラミングの才能が破壊されて まともな言語では書けなくなるというよね 初学者なら当てはまるけど作法守ればそうでもない ただコードが野暮ったくなるから利点は消える >>228 その通り VB > Perl > php >>> 越えられない壁 >>> ruby >>> 越えられない壁 >>> python Perl、Ruby、Python、JSは、どれも型がないので間違いがあっても気付かない事が あるのが困る。Perlは関数の引数が番号式で、なおかつ、参照型引数の仕様が 引数の「型」が複雑な場合に、C/C++、Javaに比べてテキトーで思ったように 動かないことがあったので困った。 Pythonはブロックの終了が分かりにくいところが最悪。Rubyはブロックの終わり をendと長く書く必要があるのが最悪。 ありなしの話で言うと全部型はあるな。 本当に型がないというのはPrologとかだろ。 ないのは型じゃなくて定義時の型情報 定義時に型情報がないから、実行時にしか判断できない しかし一部の例外を除き、コードは特定の型(もしくは特定のインターフェース)を 前提としてたコードになってる。 特定の型でしか動かないのに、動かない方を渡すことが出来てしまう。 だから書いているコードの矛盾を検出できない 使い分けしないアホが悪い そんなに型に神経質なコードをpythonで書く阿呆がおるか × 型に神経質 ○ バグなしに神経質 正しく動くコードを書くのに 神経質になって何が悪い? Rustなら兎も角、JavaやC#みたいなユルユルなドカタ言語なら スクリプト言語と変わらんわ Javaは型については、スクリプト言語よりかなりちゃんとしているし、 いろいろな意味において曖昧さが少ない言語の1つ。Pythonには間違いやすさ がある。特にブロックの範囲について。 >>238 Java, C#がユルユルとか意味わからん またvar(型推論)とvariantの違いを理解できない老害が来てるのか?w Java is not a safe language https://lemire.me/blog/2019/03/28/java-is-not-a-safe-language/ ・Javaはオーバーフローをトラップしません(RustやSwiftなどの言語はします) ・Javaはデータの競合を許可します(Rustなどの言語ではデータの競合は許可されません) ・Javaにはnull安全性がありません(SwiftまたはKotlinでは言語の一部として安全な呼び出しまたはoptionalがあります) ・Javaには名前付き引数がありません(現代の多くのプログラミング言語には名前付き引数があります) https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/the-case-for-writing-network-drivers-in-high-level-languages.pdf The Case for Writing Network Drivers in High-Level Languages Table 5: Size of our implementations stripped down to the core feature set Lang. Lines of code Lines of C code C 831 831 Rust 961 0 Go 1640 0 C# 1266 34 Java 2885 188 OCaml 1177 28 Haskell 1001 0 Swift 1506 0 JavaScript 1004 262 Python 1242 (Cython) 77 Javaワロタwwww 雑食系エンジニア・KENTA の新着動画が来たー! Javaの方がRubyよりも求人が多いという勘違いについて Javaはもう死んだの? Part.2 https://mevius.5ch.net/test/read.cgi/tech/1566040070/110 問題ないなら、さっさと初期値を入れてしまえば 型の心配はしないで済むね nullを返してくるウンコ関数を撲滅しない限り無理 >・Javaには名前付き引数がありません(現代の多くのプログラミング言語には名前付き引数があります) VBAがいまだに使われてる理由として名前付き引数があると思う VBAが存続してんのはExcel操作のためだろ Excel使わなければこんなクソ言語使わん 名前付き引数を持ってる言語が ドカタの知ってる範囲ではVBAしか無かったんじゃない? >>1 「将来性ないプログラミング言語」 この表現は厳密な表現をかなり省略しているものであって じっさいには暗に色々な前提を含んでいることに注意しなればならない たとえば現代において「使用できない硬貨一覧」という表現があるとき そのリストに巨大な石の硬貨は書いてないが、だからといって石の通貨を 使えるという話ではないのは明らかだ それは現代ではもはやそれは流通していないのは誰の目にも明らかなので 敢えてリストに書く必要がないからである OfficeがPythonに対応したら、魔改造が始まったりしてな Py++ Visual Basicは昔のBASICとは違って構造化と型宣言に関して矯正されているから、 Pythonよりはまともな言語だよ。Cよりも優れている点もいくつかある。例えば、 ・Cのswitch文ではcaseに1つの値しか指定できないが、VBのselect文では範囲を指定できる。 ・Cではfor, if, whileの制御ブロックの終わりはどれも}だが、VBではnext, end if, wendで 書き分けられ、構造を把握しやすい。 ・Cでは同じ構造体(クラスを含む)変数のメンバにアクセスする文が続くとき、構造体変数名を いちいち書かなければならないが、VBではPascalのようにwith文で括り出せる。 だから、Pythonのような駄言語をExcelが採用する利点はないし、Pythonなんてキモい名前の 言語を商用ビジネスソフトに採用するはずがない。もしどうしても採り入れるなら、言語仕様の 大幅な矯正を施して、別の名前、例えばPythagorasにするだろうな。 pythonに勝てる点を絞り出した結果が型宣言の矯正とか悲しすぎるw そういやswitch相当の構造にラムダ式を書いたらわかりにくいからやめろって言われたことある >>252 C#AになってVBAみたいにExcel直でいじれる方が便利じゃね? VBA.NETでもいいけど Excel単体でEXEとか作れるようになったら助かる ランタイム必須にしてもソースをバージョン管理できたりするとファイル管理しやすくなるから 類似や派生のxlsxが増えすぎてやってられない そもそもExcel自体、COMみたいなモノなのにexe作れる訳ねーよ https://qiita.com/yniji/items/b38bc312e860027108ac 11月6日にreditの 'ask me anything' にマイクロソフトの Excel チームが登場して、 「いつExcelにPythonが搭載されるのか?」という質問に対して以下のように回答しています。 要するに、マイクロソフトが Excel に搭載するのは JavaScript であって、 Python を使いたいのであれば PyXLL か xlwings を使えということのようです。 いつの記事だよ んで、jsexcelに入ったの? すまんそれopenpyxlでよくね 今はcodelabアドインがいるね。おそらくそれを標準に取り込むんだろう。 Excelはブラウザでも動くわけだから JavaScriptを採用するのは当然だろうな >>272 そのWebブラウザが画面を表示している仮想WebブラウザならJavaScriptは関係ない。 仮想Webブラウザ(?)なわけないじゃん なんで特殊な物の話をしてんのさ、 一般的なものの話をしろ ん?まさかExcelのWeb版(Excel Online)があるのを知らないってオチか? Excel Onlineはブラウザで動くからVBAは使えない。 JavaScriptならブラウザで動くからスクリプトをサポートできる (他の言語でもトランスレートすれば不可能じゃないけど 将来はともかく、まずJavaScript APIを作らなければいけないわけで) 馬鹿はWindowsのexeがブラウザで動いていると思ってるのかね? Excel Onlineはウェブアプリですが? LibreOfficeやOpenOfficeはMS Officeのライバルとして 作られたけど、クラウド対応はできなかったよな クラウド対応はアプリを作るだけじゃ駄目 サービスとして運営しないといけない。無料ではやっていけない。 クラウドの時代になって、LibreOfficeやOpenOfficeは MS Officeの対抗馬では無くなってしまった。 Excel2016はWindowsアプリだからEXEバイナリじゃないとダメ、って言ってるようなもんだぞ The Top Programming Languages https://spectrum.ieee.org/static/interactive-the-top-programming-languages-2019 Ruby 19位 Haskell 29位 Objective-C 26位 R 5位 Perl 27位 参考までに Javaはセキュリティ問題のため、関東でSEのローン審査が不利になる理由を生み出した。 Delphiからのポーティング案件あったぞ まあ人こなさそうだったけど kotlin本かって見てるけど、やっぱ変な記述で覚えたくないなあ 最近の言語てどんどん癖が強くなってる >>166 やっぱりな。得意分野で見ても分かる。関数型とオブジェクト指向って結局同じ事してるよな。 泣かした事もある 冷たくしてもなお 寄り添う気持ちがあればいいのさ 俺にしてみりゃ これが最後の逃げ any my love so sweet typescriptはフワッと使えるのがいいのです 原理主義者はそこが分かってない PythonってJava並に速度速くなったの? 初期の超鈍足さの印象があってどうも使う気になれない 単発ものとかなら記述が簡単なのもあってコード作成時間と実行時間の総和を取れば圧勝 常用の製品とかで運用するなら無理ゲーの極み >>295 常用じゃ無理ってそれGoogleさんの前で同じこと言えるの? 海外のサイトを見ていたら、PythonでAIをやる場合、重たい処理は、 C++で書かれたライブラリを使うから、処理時間の99%は、C++のコードが 消費する、と書いている人がいた。つまり、この場合、Pythonは、C++の AIライブラリを呼び出す司令塔的な役割をしているだけなので、Pythonの 遅さが処理時間全体に与える影響は軽微なのだそうだ。 C++は嫌いだけど消える心配はないから 保守考えるならなおさらC++だろうな 意識高い系の言語はすぐ廃れるω Ruby でも、多次元配列・ベクトル演算用ライブラリのNArray は、C言語。 その速度は、数値計算専門言語のOctave にも匹敵する ary[ 1 ] たぶん、こういう、インデックスアクセスが遅いのだろう 一々、OS のAPI を使うから、遅いのだろう つまりPythonやって 必要なライブラリをC++で書けるようになればさいつよなのかな? PHPのようにPythonにも endifとかendforとかendforeachとかがあればいいのにね。 機械学習を応用したWebアプリで、Rubyとpythonで取り合ってるような領域は pythonがぜんぶ取るかもな >>302 ライブラリの自作はGPUのこと理解しないといけないから 最難関というイメージがある。実際どうなの >>306 GPUを使うならそうだし、そもそもAIの仕組みにとても詳しくなければならないので、 ニューラルネットワークの学習理論や、微分積分学(多変数関数の偏微分など)、 最急降下法、行列、ベクトルなどの数学などもしっかり理解して無いと作るのは 難しい。 >>308 CUDAならそこまで難しくはないよ マルチGPUとかで速度追求するなら別だけど 数学や学習理論に比べたら GPUプログラミングなんて超簡単 >>310 GPUプログラミング考えたらPythonで有る必要性は無いな 論理プログラミングでのPythonは意味有るが 要は適材適所で言語選べって事 begin end は嫌で、{} はいいの? 理由がわからん バカなんでしょう それか、Delphiが好きで好きで仕方ないんでしょう これ、ずっと"デルフィー"だとおもってたんだがじつは"デルファイ"なのか?? おどろいた これが{ }いけない BEGIN これは十分に美しい END 言語じゃなくてギリシャの地名だったらデルフィでいい 読みはデルファイだが、同じデルファイでもイントネーションに2通りあって、時々腹が立つことがある >>315 スコープ定義するのにいちいち5文字以上もタイプするのがアホらしいことがわからんのか? >>324 近頃のエディタは補完してくれるのだから五文字も打たないだろう シフトキーを打つのがめんどいというのはある だいたい「タイプ量」とか言いだすやつは 今時ピュアテキストエディタでソース打ちこんでるようなレガシーマン 近頃のは補完を無効になることができるんじゃないの? あるいは補完のカスタマイズができるんじゃないの? Linux用の64ビットのアプリケーションを開発できるんだから、Delphiには将来性あるでしょう Perlはgitで使われてるから死にはしないだろうけど、これから新しいのが出てくるか?と言われると…うん >>322-323 アメリカのフィラデルフィア(Phila DELPHI a)で開発されたプログラミング言語というわけじゃないんだな。 Ruby がオワコンだと、様々な矛盾点がある Rubyコミュニティーの強さと、 学校・Rails チュートリアルなど、Rails 関連の売上の増加、 組み込みのmruby で宇宙開発など、制御システムの増加、 Rails製サイトの時価総額の増加、Shopify 15兆円、Airbnb 10兆円、GitHub 8千億円、 Ruby/Go の神、Vagrant の作者・Mitchell Hashimoto のHashicorp 5千億円 ruby信者は嫌われ者なのを自覚しろ あちこち関係ないスレに書き込むゴミ もうスレが伸びない言語、つまり Ruby Python Swift PHP VB 先駆者には布教の義務があると、あわしろ氏が言ってたな。 Perlはもう指と体が覚えてるからなあ 使い捨てプログラムやシステムバッチはどうしてもPerlでやってしまう >>336 Swiftだけは、iOSやMacOSが世界中で使われている限り、Objective-CのようにAppleが見捨てない限り、Apple専属プログラミング言語として今後も安泰では。 obCで必要十分なのでは、既にflutterも完成されてるし。 >>339 そうかな? そもそもandroidもそうだがネイティブで作っている所はかなり減っているのではないの? 機種依存の実装は少なくとも必要だろうから全く要らないとは言わないものの UnityとかWebViewを埋め込んでいるだけみたいなものが主流だし 勉強で覚えるならいいけど、本格的に覚えてもなぁ・・・とは思う >>342 現在は、というより今後も、機種依存ネイティブ依存のコンパイラ型言語より、実行環境(Unity、.NET、Javaバーチャルマシンなど)に依存した、中間コードを吐く中間言語が一般的になっていくんだったのか。了解、なるほどね。 >>343 スマホ対応の場合は特にゲームはiOSだけという訳にも行かないから 両方対応出来るUnityやUnrealEngine,Cocos2dxみたいなクロスプラットフォームなものを 使った方が効率は良いと言うのが大きいと思う 近頃はゲームだけじゃなくとも両対応するためにビジネス系でもUnity使う場合もあるらしいが ビジネス系はwebviewを埋め込むwebアプリの方が良いかなと思ったりする ただアプリとしての提供をしたいのでwebviewを埋め込み多少制御するコードを ネイティブで書く事は良くあるのかなと思う >>345 PCだけじゃなくスマートフォンまで含めるとメジャーなOSやCPUの数が増えたうえ、移植の需要もあるから、とてもOSやCPUに依存したソフトウェアなんて作成していられないんだね。 Linuxなんて異なるディストリビューションでは実行ファイルに互換性がないどころか、同一ディストリビューションでさえバージョンアップなどでカーネルのバージョンが変わると、実行ファイルが動作しなくなるそうだね。だからLinuxではソースコードで配布して各自の環境でコンパイルして動作する実行ファイルを自分で作成する文化が広まった、というのを最近知った。 解説ありがとう。 Objectibe-CはSwiftに代わられたし、 PerlもPHP・Ruby・Python等に代わられたからそこまでは分かるんだけど、 あとの3つはまだ現役で、しばらく使われる気がするんだけどなぁ アップル自体が終わって欲しいわ iOSとかいらないし、macもいらない >>348-350 じつはAppleはMicrosoft以上に安泰では? 稼ぎ頭のiPhoneは携帯電話キャリア大手三社の看板商品でもあるし。 MacのほうもYouTuberをはじめとした映像関係者、画像関係者、音楽関係者の御用達で、さり気なくYouTuberが宣伝役をも兼ねているし。 日本のOSシェア(2009年1月〜2020年1月) - YouTube s://www.youtube.com/watch?v=nw3ktljBNxg 世界のOSシェアランキング - YouTube s://www.youtube.com/watch?v=MKkzNY0hrQ0 >>352 続き 2020.09までのデータあり Most Popular Operating Systems 2009-2020 人気OSの世界シェア率 - YouTube s://www.youtube.com/watch?v=jsWkIbYL1jE Windows一強時代は終わり群雄割拠時代へ突入したチャンスに、日本もiTRON、μiTRONなどの産業用TRONで粘るだけじゃなく、デスクトップ用途(ビジネス用、家庭用、教育用ほか)のBTRONの研究開発実用化を、もう一度復活させるよう努力、工夫、マーケティングをし、10年後20年後のソフトウェア大国を今からでも国を挙げて目指すべきじゃないかと思う。今こそチャンス中のチャンスだろ。 米国をしのぐIT技術 日本製OS「トロン」の世界標準化をつぶしたのは誰だ - YouTube s://www.youtube.com/watch?v=K5Nmco6dNVk Appleはハードウェアメーカーになる。 swiftのサポートはしない。 >>353 ‐354のソフトウェア大国になるのと並行して、日本は半導体の研究開発設計大国をも、10年後20年後を見据えて今から目指し始めるべきだろう。 とくに、メモリだけじゃなくCPU、GPU、通信コントローラ、メモリコントローラ、制御チップ、一体化したSoCほか、要所要所の基幹コントロールICなども積極的に抑え、世界のトップ2かトップ3くらいは常に維持できるようになるべき。 イギリスの教育用PCの開発目的で設立されたARMが、今やモバイル機器の主力SoCに成長したことからも学ぶべき。そればかりかARM製品は、AppleのM1CPU、nVidiaのGPUの開発のベースにもなっていて、今やARMは世界中を席巻しているわけで。 台湾も昔から地道に、いろんな開発設計会社がLANやWiFiの通信コントローラを開発したり、Intel互換CPUを開発したりしてる。 モバイル機器用SoCに至っては近年では中国Huaweiや韓国Samsungも独自開発し、自社製品に採用している。 日本はソフトウェアと基幹コントロール系半導体の両方で、世界トップ級の研究開発設計大国を、ぜひ今こそ国を挙げて目指すべきだろう。 日本の技術は世界一いいいいと、あわしろ氏が言ってたけどな。 AppleにとってiPhone本体やMacintosh本体の売上は絶大なはず。さらにiOS、Mac OSXというソフトウェアと、iPhone AppStoreやiTunesというWebサービスプラットフォームをも支配する。この三者による徹底したユーザ囲い込み戦略こそがApple躍進の原動力だと思う。 Appleが、ハードウェアのみ、ソフトウェアのみ、Webサービスのみ、のどれかに特化することは、当分の間は考えにくいのでは。 >>356 学ぶだけでお腹いっぱいになって、そのまま寝落ちして終わるのが日本の常。 昔の武士の手習いと同じでね。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる