Linuxは、開発環境が40年前と同レベル

1login:Penguin2018/03/10(土) 12:14:37.34ID:F9RE316x
間違ってもらっては困るのは、それはコマンドライン・メインなのが主因ではないということ。
本当の一因は、本来手書きでも簡単な Makefile の作成をわざわざ難しくしてしま
う autotools を権威に流されたのか多くのプロジェクトが使ってしまっている事にある。
高々 Makefile 1つ作るためにも以下のような工程を踏まなければならない。
本来、典型的には、ソースファイルである *.c, *.cxx, *.cpp を指定するだけ
でも自動生成する事が出来るはずなのに、ツール類が馬鹿だからそうなってない。
なのに、「Linuxはプログラマーには便利」などと嘘情報が流れるから、普及しない。
しかも、カレントディレクトリのスクリプトの実行に「./configure」などと「./」
の指定が必要なのも馬鹿丸出し。ファイル名に大文字小文字の区別がされているのも馬鹿。
ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが
$ find . -name '*.c' | xargs -n 1 -i cp -p {} /xxx/aaa
などとしなくてはならず長すぎ、馬鹿ですか? しかも、'*.c'の部分が、*.c と書かれている
説明が溢れているがそれだとbashが展開してしまうのでたまたま上手く行く事はあっても、
実際には正しくない。また、mountしないとディスクが認識出来ないのも初代PC-8001の
レベル。PC-8801で自動マウントできるようになったのに(いつの時代(苦笑))。まずは、
不便さを認めるなければ、改善すらままならないのにそれすら全否定。正直に便利と思って
るなら井の中の蛙で馬鹿で無知なだけだ。そして、僅か1点でも間違いがあれば全てが間違って
いるように全否定してしまうLinux信奉者の愚かさもアホとしか言いようがない。

692login:Penguin2018/10/27(土) 12:40:53.22ID:vvEvYZjK
jsonが爆発的に普及したきっかけはバイナリ保存はしたくないけど、オブジェクトをそのまま保存したいって需要だから
設定に使うとしても開発者よりなんだよな。linuxは開発者フレンドリーだから開発者マインド無いときついってのは理解できるけども。

693login:Penguin2018/10/27(土) 16:29:50.82ID:SAg19bbX
階層が深くないならiniが見やすくていい
階層が深いならyamlだし、記述性ならxmlだし、どれも一長一短あるけど、テキストエディタで開く設定ファイルならiniは使いやすい

694login:Penguin2018/10/27(土) 18:49:59.82ID:O58iUbEz
複数行コメントを書けて、日本語も問題ない、Ruby が良い

=begin
複数行
コメント
=end

695login:Penguin2018/11/14(水) 13:34:30.81ID:9Y41hzLp
Windows界はいろんな産業ロボットを使ってモノを生産しているのに
Linux界はいまだに手作りでモノを生産しているようなもんだからね。

696login:Penguin2018/11/14(水) 13:43:53.49ID:gyZLFZAz
工事ライン止まる恐怖

697login:Penguin2018/11/14(水) 15:34:23.73ID:R9HUvO/L
>>1

Unix は世界最古のOSらしいので、最初は良かれと思って決めたものが、
使ってみると使いにくかった、ということはあるかもしれない。
一例として、

$ コマンド名 パラメータ >a

などとして、リダイレクトするとき、stdout と stderr が分かれている
のも、現実的には不便。

$ . スクリプト名

と先頭にピリオドをつけないと環境変数がスクリプトによって設定できない
のも不便。

どちらも、DOS では修正されていた。DOS の方が後発だから。

698login:Penguin2018/11/14(水) 15:46:04.08ID:9Y41hzLp
資本制企業はいかに人件費を削って量産するかを常に考えている。
少ないプログラマでより多くをと。
ところがオープンソースの世界はコーディングすること自体が楽しい
って人々の集いだからな。効率化へのインセンティブが小さい。

699login:Penguin2018/11/14(水) 16:12:37.60ID:R9HUvO/L
>>697
別の環境変数で処理したいなら別の端末を開けば良いわけだから、
スクリプト内での設定を反映しないという仕様は、今となっては
アリガタ迷惑だと思う。

ただ、行儀の悪いわけの分からんスパゲッティーで解読するのも
時間の無駄なスクリプトも多いが。

700login:Penguin2018/11/14(水) 16:31:47.06ID:R9HUvO/L
>>697
stdout と stderr と時系列的に合わせて出力しないと、解読しにくい
場合があるので、結局、2つの出力を合成したいことが多く、

1&>2 a

だったか、覚えていられないような変な記号を書かなくてはならない。

あと、tee コマンドも覚えにくい。

701login:Penguin2018/11/14(水) 18:19:54.67ID:NypCRQ0z
というか何もかも覚えられない

脳が退化しているのか?

702login:Penguin2018/11/15(木) 11:00:41.86ID:xZi0sQ1j
&> a
と、
1>&2 a

の両方の書き方があったり、export が必要あったり無かったり、
そんなアホみたいなものは、むしろ高級な脳であるほど覚えられない。

高級な脳は、共通原理や一般法則だけを覚えようとし、単純で無意味な情報は
削除される傾向があるから。

703login:Penguin2018/11/15(木) 11:06:16.36ID:xZi0sQ1j
>>1
なんという愚かなOSなんだろう。
DOSと同じことがこんなに長くなる :

[DOS]
$ コマンド名 >a

[Linux]
$ コマンド名 1>a 2>&1

704login:Penguin2018/11/15(木) 11:18:44.03ID:ZYarPIhK
bashが使える環境ならbashでいいです

705login:Penguin2018/11/15(木) 14:57:10.66ID:jf56ooyw
>>703

> [DOS]
> $ コマンド名 >a
        ↑間違い

> [Linux]
> $ コマンド名 1>a 2>&1
        ↑1は不要

正しくはこうだよ

[DOS]
$ コマンド名 >a 2>&1
[Linux]
$ コマンド名 >a 2>&1


参考
http://tooljp.com/windows/doc/stdout-stderr/stdout-stderr.html
> (4)標準出力と標準エラー出力を同じファイルにリダイレクト
> mycmd.exe > stdout-stderr.txt 2>&1

706login:Penguin2018/11/15(木) 16:10:24.15ID:xZi0sQ1j
>>705
DOS に関しては、そもそも原則として多くのツールが、stderr を使わない流儀
だったので、stdout だけをリダイレクトすれば十分だったんだ。
だから、その意味で、

[DOS]
$ コマンド名 >a

は間違ってない。

要は、トータルの使い勝手で考えた場合だから。

707login:Penguin2018/11/15(木) 16:17:52.58ID:ygBKpHRC
何言ってんだこいつ

708login:Penguin2018/11/15(木) 16:35:44.99ID:xZi0sQ1j
理念はどうあれ、結果的に使いにくいということだ。

709login:Penguin2018/11/15(木) 19:22:40.55ID:jf56ooyw
ほらほら、間違いを指摘されて、
焦ってきてるぜwww

710login:Penguin2018/11/15(木) 19:26:14.30ID:BbyfSDoN
つまり、DOSコマンドは設計に沿わないアプリが多かったということかな?

711login:Penguin2018/11/15(木) 19:33:50.35ID:xZi0sQ1j
>>709
いや違う。
最初からそれを前提にしていたので間違ってない。
あなたは、DOSの事知らないからそんなこと言ってるのでは。

712login:Penguin2018/11/15(木) 19:35:22.15ID:xZi0sQ1j
>>710
いや、むしろ、stderr を滅多に使わないのがDOSの流儀だった。
少なくとも、コンパイラのエラー表示は100%、stdout に出ていたし、
その他のフリーソフトなんかの表示もほぼ、そうだった。

713login:Penguin2018/11/15(木) 19:36:28.21ID:xZi0sQ1j
使いにくくなるだけなのに、stderr を使っているソフトが多いのは、Unix系の
プログラマには、実は真の意味では頭の悪いのがいっぱい混じっているから
ではないか。

714login:Penguin2018/11/15(木) 19:47:41.79ID:BbyfSDoN
明言していない前提
他社を憶測で知らないもの扱い
ごく主観的な流儀
主観的な使いにくさでOSの草分け的な開発者を無能扱い

これだけでまともに取り合う気がなくなる。

715login:Penguin2018/11/15(木) 20:26:24.23ID:BbyfSDoN
元々、stdoutとstderrが分れているのには理由がある。
理由もなしに分けたりしないという想像力があれば憶測でモノを言うと恥ずかしいことぐらいわかりそうなもんだが。
標準出力がUIを兼ねていたのでユーザーへのメッセージがerrで塗りつぶされるのが良くないし、
出力結果を次のコマンドに渡すときなどにerrメッセージが混ざると困るし、
コマンドが入力待ちの状態の時、errなんか出たらなにで止まってるのかわからないからな。
当時は無視するしか無いerrもあって切り分けるしかなかった。
例えば標準出力をファイルを書き込んでる最中にエラーを出力するにはstderrに出すべきだろ。
それを使いにくくなるとは。。。

716login:Penguin2018/11/16(金) 00:27:49.09ID:tzv3Gduj
>>715
コンパイラの出力をパイプで渡していくのは時代遅れだと思う。
今は、ファイルに書いて渡せば良い。

717login:Penguin2018/11/16(金) 01:05:00.97ID:tzv3Gduj
>>714
古い時代とはまた違った、今の時代に合った CUI の流儀がある。
Unix好きの人には、古いものを維持し続けようとする人が多すぎるのか、
または、古いソースを使いまわし続けすぎているためか、古い流儀のまま
になっているために効率が下がっている。

718login:Penguin2018/11/16(金) 05:47:32.05ID:dRD9J7hj
DOSはパイプの文化じゃないわな

719login:Penguin2018/11/16(金) 05:51:52.18ID:0i6TmJsP
>>716
ファイルに書いて渡すと遅くなる
ディスクが遅いとかいう話じゃなくて
並列処理ができなくなるという話

720login:Penguin2018/11/16(金) 10:12:56.67ID:tzv3Gduj
>>719
実際のコンパイルは、a1.c, a2.c, a3.c, ・・・ などを別のCPUコアに渡して、
マルチコアでコンパイルするので、既にCPUコアが完全に使用しきられている。
なので、それ以上、コアに空きが無いので、パイプを使っても並列度が
上がることはほぼ無い。

一方、いったんファイルに書いてもファイル・バッファにキャッシュされ、
実際のディスクへの書き込みは、全く行われないか、または、ずっと後
になってから行われ、コンパイル作業中にはRAM上でデータの受け渡し
が行われるためディスクの遅さは全く関係しないと言っても過言ではない。

721login:Penguin2018/11/16(金) 10:26:25.63ID:0i6TmJsP
>>720
パイプを使っている今はね。
ファイルを作ると遅くなるって言ってるの
今のやり方が最適なの。だからCPUコアを使い切れている

722login:Penguin2018/11/16(金) 10:53:36.15ID:tzv3Gduj
>>721
パイプを使っても、0.000001% 位しか速度差が出ないのに、
gccなどのコマンドラインはめちゃくちゃ使いにくくなる。

723login:Penguin2018/11/16(金) 11:29:58.77ID:CImKgAch
コンパイラのエラーメッセージは標準出力に出て問題ないだろ。*nix系でも出るぞ。何いってんだこいつ。

724login:Penguin2018/11/16(金) 13:08:48.23ID:tzv3Gduj
>>723
よく読め。そんな事言ってない。

725login:Penguin2018/11/16(金) 13:44:14.78ID:0i6TmJsP
パイプを使わないと動画をリアルタイムにエンコード出来ない

726login:Penguin2018/11/16(金) 15:18:51.23ID:tzv3Gduj
>>725
別にパイプを使うなとは言ってない。
そういうケースでは使っていい。

727login:Penguin2018/11/16(金) 15:24:14.00ID:0i6TmJsP
どうやら時代遅れなのはお前の頭だと気づいたようだなw

728login:Penguin2018/11/16(金) 15:29:21.83ID:tzv3Gduj
違うな。
古いものと新しいものを逆さに捕らえる人がいて困る。

729login:Penguin2018/11/16(金) 15:33:24.49ID:CImKgAch
そもそもstderrの使い方知らなかっただけじゃないの?

730login:Penguin2018/11/16(金) 16:17:03.41ID:tzv3Gduj
>>729
そんなことない。
stderr が有っても敢えて使っていなかった DOS の選択は賢いと思ってる。

731login:Penguin2018/11/18(日) 01:55:09.21ID:Vr4U8zB+
>>1
gcc や clang も、include path の設定が無視されることがある。
複雑に複数の言語処理系がインストールされている場合に、
include path が勝手に「コマンドPATHから推定して」 決められて
しまい、それを修正したいために、環境変数などを設定しても
優先順位がおかしくて、なかなか修正されないことがある。
しかも、その状況を確認するには、-v オプションを付けて
出てくる長いメッセージを解読しなくてはならない。

また実は、バイナリになってしまってからは修正すること
が難しいパス設定が存在することもある。
その場合は、ソースから make する際に、./configure
のパラメータで決められてしまっている。

つまり、バイナリレベルでは、動作が変えられるように
出来ていない欠陥品が多い。

732login:Penguin2018/11/18(日) 15:40:41.51ID:3P44tPJl
$ prog1 | prog2 | prog3 > job1.out
$ # で済むところを
$ prog1 > tmp1
$ prog2 < tmp1 > tmp2
$ prog3 < tmp2 > job1.out
$ rm tmp1 tmp2
$ # ってやるのか?

733login:Penguin2018/11/18(日) 17:57:25.79ID:Vr4U8zB+
>>732
最初のようなパイプでつなぐような表記を、コマンドラインから打つこと自体、問題なんだよ。
むしろ、ファイル名を指定して、少しずつ進んでいくほうが賢い。コマンドラインからだと。

型のあるプログラムだとコンパイラがエラーを出してくれる確率も高いが、
コマンドラインからだと、わずかな間違いが重大な問題に発展しやすい。

それに、どうせ、打ち間違える確率が高いので、何度も試すことになり、最初から
実行し直しになることが多い。


$apt-cyg show | grep -i nantoka

$コマンド名 | less

みたいなことやら無くちゃならない頻度が高すぎ。長すぎて馬鹿だ。
こんな設計思想、ダメだ。

734login:Penguin2018/11/19(月) 17:47:26.62ID:+NP8NhMG
正直期待してなかったけど、初めてまともな返答をしてくれたね。
君は自分が世界の中心ではないということを理解すべきだ。
君のために存在するものなど何もない。
それでも適切な方法で助けを求めることはできるはずだ。
〇〇をうまく使えないという理由で〇〇の作者の頭が悪いなどというなら
誰も助けてくれないし君にとって良いことなど何も起こらない。
まあ、それはそれとして、シェルのヒストリ機能や行編集機能は使ってる?
ターミナルエミュレータの copy&paste は?
これらを使ってもまだ大変だと感じるなら Emacs なんかが助けになるかもしれない。

735login:Penguin2018/11/22(木) 15:34:28.06ID:RrnXOV1/
You! Visual Studio codeをinstallしチャイナyo!

736login:Penguin2018/11/22(木) 18:57:40.31ID:oP/fZ4BU
ビジュアルスタジオは使いやすいよ。
まじお勧め。

737login:Penguin2018/11/22(木) 22:43:59.51ID:UVJrC35/
#ifdef なんかも設定に応じて認識して、ちゃんとコードの色に反映してくれるからねえ。

738login:Penguin2018/11/23(金) 08:49:45.51ID:YQZUc9qP
バランスが取れておらず、かつ、統一感もない。
それが Linux。

また、安さ以外に売りが無いのに最新のハードと最高の通信環境を要求する。

739login:Penguin2018/11/23(金) 11:11:59.14ID:j6ao89z3
最新のハードを要求する前に、最新のハードのドライバを用意したまえ。

740login:Penguin2018/11/23(金) 15:11:40.84ID:YQZUc9qP
WINE もバイナリは新しい Linuxを要求するのに、Emulator としては、
64BIT Windows はサポートしていなかったりする。
つまり、新しいハードでしか動かないのに、古いOSしかエミュレートできない。

訳分からん。

741 ◆P0jSlC5fJs 2019/01/09(水) 23:33:32.72ID:7ix8aRrY
>>735
VSCodiumのほうがいいよ

742login:Penguin2019/01/17(木) 19:03:06.80ID:0ZKqMBG3
あたらしいプログラムはPowerShelも対応するようにして
徐々に移行していったらええのに

新着レスの表示
レスを投稿する