【IT】「最も嫌いなプログラミング言語は何？」栄えある1位に輝いたのはあの言語
■ このスレッドは過去ログ倉庫に格納されています
プログラマが最も嫌うプログラミング言語に関する調査が行われ、かつてウェブ上で高いシェアを誇ったあの言語が堂々の1位に輝いた。
これはStack Overflowが実施したもので、結果は「Perl」がダントツの1位、次いで二番手グループが「Delphi」「VBA」、三番手グループが「PHP」「Objective-C」「Coffeescript」「Ruby」という結果になっている。調査方法はやや特殊で、同サイトのDeveloper Storyという求職ページに登録しているプログラマが「扱いたい」と回答している言語に加点、「扱いたくない」と回答している言語を減点するという方式によるもので、投票などによる選出よりもある意味で信頼できる結果と言える。同調査ではこのほか「嫌いな技術」についても同じ方法で調査を行っており、そちらはIEやFlashなどが上位に挙げられている。
https://internet.watch.impress.co.jp/docs/yajiuma/1089747.html いいお、ごめん。
あんまり考えても、今、CGI系ないからさ、
一緒にいたら友達になりたいタイプお。 まじな話、Perlの後継言語はPowerShellだと思う。
Perlができた経緯もシェル言語への不満で、
PowerShellはコンピュータサイエンスや現代的技術をベースに一から作り直した感じ ID:ohz972dw
面白いからコメント続けてくれ >>533
それでみんなに嫌われてるPerlだけど、極めた人が有用性が理解できるよ。
Perlが嫌われる１位になった理由を考察してみたけど、
一部のホームページにもこんな事が書かれてた。
ごく普通の言語（COBOL,C,Java,VB等）を知っている人が、
Perlをやり始めるといろいろと悩むことがあります。
暗号のような記号のオンパレード
文脈（コンテキスト）によって意味の違う関数
構造体がないデータ構造
同名で意味が違う変数
比較先がない比較
代入文がないのに代入される
正規表現の拡張
return文がないリターン値
foreach文がいつのまにかfor文に
サブルーチンなのに関数に
ファイル名がいつのまにかハンドル名に
是に加え文字化け。文字コードの扱いが途中でグチャグチャしすぎ。
この辺りから。
第31回 encoding：いつまでもjperlから抜け出せない方に
http://gihyo.jp/dev/serial/01/modern-perl/0031
第32回 Encode：日本語だけ扱えればよいのではなく
http://gihyo.jp/dev/serial/01/modern-perl/0032
第33回 enc2xs：標準の文字コード表にはない文字を変換する
http://gihyo.jp/dev/serial/01/modern-perl/0033
複数の文字コードを扱う似た様なモジュールや命令が幾つもある為に何が本命なのか迷う。
文字コードの扱いが面倒で厳しいので、本文の処理に集中できない。
Paypalなどの決済サイトでも、PythonやPHPやJAVAやASP.NETはコードがあるのに、
Perlだけ文字コードトラブルが多いのかユーザーが扱いきれない事が多いのか推奨されてないらしく出てこない。
Perl5辺りで、文字化け問題を内部UTF8に全部押し付ける事で解決を図ろうとした仕様を
標準化してしまったために、逆に色々な問題が起きて敬遠されてしまったんだろう。
Perl5になってからCPANで外部モジュールの追加で全部解決しようとした為に
言語処理がユーザーには理解しがたいものになってしまい、
その間に、PythonやPHPなども台頭してきて、極めたような人以外は使う人が少なくなってしまったみたい >>466
Kotlinは変数型は省略可能
スペルすら間違ってるあたり背伸びしてるのがミエミエ >>494
いやますます重要になってきているだろ
お前の使っているその言語のランタイムやライブラリが何でかかれているか少しは意識しろよと >>544
下の層の詳細や実装方法を知らなくても大丈夫
例えばそのC/C++で書いていてもCPU個別のアセンブラを意識する部分はカーネルの一部だけであるし
アセンブラで書いていてもCPU内部実装を意識することは稀で公表スペックまで把握していればよいし
さらに下位層には電気工学的にどうなのか、分子レベルでは、原子レベルでは、量子レベルでは、となる
つまり各プログラミング言語の仕様まで把握していればそのコンパイラやインタプリタで用いられている言語は気にしなくてよい >>545
上の層の言語の重要性が増すほど、その機能やらライブラリの充実やら高速化やらの需要が増す
で、それに答えるためにも下の層での開発効率がより重要になるんだな。
c++も保守的だった昔と比べて11以降楽に書くためのsyntaxシュガー導入やらライブラリの充実やらの勢いは凄い
まあ言語仕様や理解のための必要知識がガンガン肥大化していって素人お断りなところも加速している気もするが
でも本当にライブラリのユーザーとして振る舞うだけならコーディング量はLLと比べても大差ないレベルまで来ている 高レイヤー「低レイヤーは俺らの奴隷だから」
低レイヤー「高レイヤーの馬鹿どもには書けねーから」 >>547
レイヤーの高低に優劣さはない
そしてレイヤー間は独立していて互いにその内部の仕組みや実装をしらなくても利用できることが本質
それなのに>>546はそれを理解しないどころか論点をすり替えてc++を意味不明な方向で持ち上げているだけ 別レイヤーは意識しないでいい人間が大半だけど、だから低レイヤーは要らんとか言うのとは別の話 >>548
> レイヤーの高低に優劣さはない
CPUの設計をしてるエンジニアと、
Javaで業務システムをコーディングしてるエンジニアに
優劣はないと信じてるのね。 >>550
逆を返すとCしか知らない上にCやらせてもそこそこしか出来ない人もいれば
今時のモダン言語でWebシステムを超短納期で作れる人もいる
スキルとレイヤーは完全にXとYの関係であって、比べること自体愚かだ >>550
優劣はないよ
まさかどちらかが優秀だとでも思っているのかな
個々の人間には向き不向きはあれどどのレイヤーにもどの分野にも優秀な人とそうでない人がいるのは事実だけどね
いずれにしてもどんな優秀な人間でさえ1人であらゆるレイヤーあらゆる分野をカバーすることは不可能なので分担協調が不可欠
レイヤーが明確に分かれているとレイヤー間のインターフェース／プロトコルさえ守れば独立に作業できるので効率が良い 高レイヤー「レイヤーに優劣はない」
低レイヤー「低レイヤーは馬鹿には設計できない」 >>552
優劣があるかどうかはどうでも良いけど
報酬に大きな差があるのは事実。 >>554
高レイヤーと低レイヤーで収入に有意差ないぞ
スキルや政治力は顕著に差が出る >>554
どちらの報酬が大きいと思っているのでしょう？
レイヤーによる収入差はなく、むしろ同じレイヤーでも個人差による収入差の方が大きいでしょう Rubyは単に外人は知らないから扱いたくないというだけの事で、
それをdislikeと評するのはおかしいのではないでしょうか？ >>557
Rubyは単純に言語仕様&記法に癖があって使い勝手が良くない点と
メリットが皆無(以前はRoRがあった)という点でRubyを使うメリットが外人に限らず日本人にもない >>557
この調査日本人は殆ど関係ないみたいですけど。
外人さんはメリットがどうこう以前に
Rubyなんて名前しか知らんという人が大半なのではないでしょうか？ >>559
Ruby on Rails (RoR)によって外人さんもRubyを知っている
そして当時画期的だったRoRを高く評価していたのも外人さんたち
しかし他の言語でも同じようなフレームワークや改善されたものが次々と出現してRoRが没落
RoRというメリットを失ったRubyは単なる癖があって使いにくいプログラミング言語の地位に落ちてしまい嫌われている >>533
見做せません
文脈自由文法でなくなってしまいます
いわゆるdandling else問題
パーザ絡みで不利
メタが当たり前なご時世にelif/endif相当を導入しないのは愚策
endifなしだと不味い >>555
各レイヤーの底辺とトップを比べても意味ないよ？ >>563
もちろんその例の3つ(Perl,Ruby,Python)いずれもendifはある
Perlは「}」、Rubyは「end」、Pythonはインデントでendifを表現している
このうちなぜPerl,C,Java,JavaScript等で用いられる「}」形式が圧倒的にelse if問題で有利になるのかというと
丁寧に冗長に記述すればこのように最後が「}}」となる(条件が5つなら「}}}}}」)ところを
if (条件1) {
} else {
if (条件2) {
} else {
}
}
ここでelseの後ろのブロック内がif-else分だけなので「{」「}」を外して
if (条件1) {
} else if (条件2) {
} else {
}
と簡略に書ける点にある
つまりPerlでは「elsif」が必須ではなく単純に「else if」で代替でき、CやJavaと同じ記法となる
一方でRubyやPythonではこれができず複数のendが続いたり深いインデントとなる >>533
そのためRubyやPythonでは「elsif」や「elif」が必須となってしまうのである >>567
perlでは else if という記述は通らない。 Cでこのようにelseの後ろに{}無しの一文は通るが
if (value) {
printf("true\n");
} else
printf("false\n");
Perlでこのようにelseの後ろに{}無しの一文は通らないんだな(syntax error)
if (value) {
print "true\n";
} else
print "false\n";
記法なんでも有りのPerlがこの構文を許さない理由はなぜだろう？ >>569
else に限らず then 側も同じだろ
C なら
if (value)
printf("true\n");
else
printf("false\n");
でもいけるし
> 記法なんでも有りのPerlがこの構文を許さない理由はなぜだろう？
if() a = 1 if();
って書かれた時に
if() { a = 1 if() };
{ if() a = 1 } if();
のどっちなのかが分かりにくくなるからじゃね？ >>571
それはパーサー部分で優先度・左右結合力が決まっていればどちらかに一意にできると思う >>572
それはそうだが「人間に」分かりにくいって話かと >>493
よくわからんがプログラミング素人でも何となくわかる感じ？ >>30
Perlはプログラム初心者が最初に学ぶべき言語では無いだろう。
いきなりオライリーのPerlの聖典読んでもわからんだろうし。
最初にPerlのCGI的なものに集約して取り上げたような断片的で
直ぐに通用しなくなるようなものも含まれるようなのを読んだ人はつまずいただろう アセンブラプログラミングって言うくらいだから入るでしょう 組み込み系もアセンブラとか駆逐されてるな。
せいぜい非力な8ピンPICとかくらいだろ。 >>580
組み込みも殆どワンチップARM+Linuxになってるしな コンパイラ自体をアセンブラで組む必要なんて無いぜ。 >>584
UNIXって言うOSが有って、アセンブラじゃなくてC言語で作成されてるわけだけど >>585
便利だけどさ、あれ単なる静的型付けされたマクロやん
書く分には良いけど、デバッグの際に地獄を見る
後発言語のジェネリクスは本当にテンプレートの良いとこどりした感じで良い >>463
みたいな考えの人間おる？
俺もこっち派なんだが。JavaもKotlinも俺には合わない。
Pythonみたいに適当に動かせるほうが好き。
型宣言が無くてソース追えないというのはあまり理解できない。
JavaやKotlinはなんだかんだメソッド動かす（オブジェクト初期化するも含む）のに、
いちいち型をあわせるとか本当に面倒でさ。
メソッドが必要とする引数オブジェクトの型が
プリミティブ型ならまだいいけど、
生成するのが面倒なクラスのオブジェクトとかだと本当にイラつく。
一気にテストするのがだるくなる。
しかしテスト大賞のメソッドで使うオブジェクトのプロパティとかメソッドは
大抵一部で、大多数のプロパティは不要なのがうざい。
メソッドに不要なプロパティもオブジェクト生成のために再現しないといけない。
だから、関数が使うプロパティやメソッド名が引数のオブジェクトにあれば、
その型は気にしないって考え方のほうが好き。
ダック・タイピングって言うのかな？
メソッド流しながら引数となるオブジェクトに
必要なプロパティやメソッド確認できるから。
そのほうが俺はデバッグしやすくて嬉しい。 COBOLはあれはあれで昔は良かったんだろうけど
過去の遺物だな、 VBAはちょっとした処理だったら効率よい
大規模ならアホかと プログラマで食うのなら、Cはキチンと書けないとな
実際の仕事でCを使うか分からんが、必要なのはロジックなんだな >>590
そっちの人って、やたらタイプ数を減らそうとするよね。
コーディングにかける時間なんて開発のほんの一部なんだから、大した効果ないのに。 中小企業御用達のVBAだもんな呪縛からは逃れられん ちゃんとマスターする前に別言語の仕事をやることになりがち >>590
ほぼ完全に同意
現在は型を厳格に宣言することにほとんど意味はない
昔はコンパイラ等で最適化に有利だったが現在は自動で判別される >>590 は動的型付けの話っぽいが
>>598 は型推論の話っぽい
要するになにも理解してないんだろうな w >>599
だよねｗ
安全なプログラムに型システムは必須だよ 目的でものを考えてないから
型が必要とか思っちゃうんだろうなあ。
静的な言語の型推論と
動的な言語の目的は本質的に同じこと。 要は推論が得意な奴は
型はいらないと思える。
気付けない、推論ができない
地頭の悪い奴は多分型が無いと
読み取れないんだろ。きっと。 型推論がどんなもんかも理解できてない奴の戯れ言 w ⇒ >>603-604 C?
VB.NETさえできればいいんだよ
IF
ELSE
END IF
ほら、美しいだろ無駄な括弧はいらないし、型の定義も基本的に強制だし
ポインタなんて使わない
リファレンスも豊富だし
オブジェクト指向もできる
ほかの言語は回り道に過ぎない
VB.NETこそ至高なのです Your Highness ソース読めばわかるようなことをコメントしないと気がすまなかったり
すぐに手順書ばかり欲しがったり
なんでもかんでも冗長に書きたがったりするような奴が
きっと型を欲しがるのだと思う。
ソースからその人間の意図を理解できる勘が良いやつなら
そうした冗長性は無駄にしか思えないのだろう。
結局型を欲しがるか欲しがらないかは
人間としての資質の差だと思う。 冗長じゃないと
わからない、納得しないような地頭の悪い人に合わせてあげてるだけだよ。
目的論の話をしてる時に、
厳密性にこだわり話の筋を折るような人に
あげ足取られないようにするためにねｗ >>608
そんなあなたにはアセンブリ言語がおすすめです。 >>611
はっきり「中身のない長文」って書かんとわからんのかよ w VBAで食わしてもらってます。あまりに評判悪くて将来が心配です。他言語を身につけるなら何がいいですか？ PHPは言語仕様を読んでるだけでめまいがしてくる
なんであんな建て増し旅館みたいになってんだ >>618
PHPは馬鹿でも出来る。頭が馬鹿になりそうだとか
前に吹聴してるの見た事があるけど、あれは嘘なのか？ >>440
DOS時代にすべてアセンブラで書かれたという
TARGETという競馬データーベース・ソフトがあった
初めて使ったとき、あまりの速さにびびった
その後Windos版になるにあたってDelphiで書いたそうだ
少しでも処理の速さを考えて、と作者が言ってたな
それでもDOS版には及ぶべくもないが >>599
区別出来ない馬鹿がアホな書き込みしてるよね >>620
RDBなんてインデックスあるかどうか
ない場合はどう処理するかが全てなんだが？ >>220
では、昨今のoss時代、redisを使ってみよう。
あまりの速さに再び感動するだろう。
やはりoss時代の爆速インタプリタ luaと組み合わせれば軽い処理にわざわざ
javaで書こうとも思わなくなる。 俺は機械語が嫌いだったんたが、アレは何位だったんだろう？ >>630
俺もカッコ嫌いだから、F#とか割と好き
次点でPython >>607
マジレスだけど、VBAとExcel、Accessで業務の90%はカバーできると昔から言われているし、残りの10%をその他の言語がカバーしてるんです。ただ、誰でも容易にソース書けるのが逆にデメリットなんですよね。 ■ このスレッドは過去ログ倉庫に格納されています
