【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 >>5
VBAが嫌われるのは古い設計のシステムで更新する仕事が多いから。
トラブルの原因の多くは古い設計だが、古い設計だから新しくするという仕事がもらえているのに、現場は元のシステムが古いことを目の敵にする。
1位から3位グループ全部そう。 >>6
スクリプトかどうかなんてのは嫌われるかどうかには関係ない。
ストロングタイプな言語とは使い道が違う。
ましてJavaScriptはラン環境が特殊だからな。 >>11
スクリプト言語もあるしそうでない言語もある。 >>9
別にC/C++でもC#でもSwiftでも良いのではないかね？ >>12
スクリプト言語とマネージドコード言語の区別がついていないようだね。
まだ人にコメントするのは早いな。 >>13
現在のオブジェクト指向言語のほとんどは手続き言語であって、宣言型の言語はSQL以外ほとんどないのだが？ >>12
スクリプト言語が中間コード吐く言語なら、C#も中間コード吐くからスクリプト言語になるだろう間抜け。 >>16
CとかJAVAはストロングタイプな言語で、例えて言えばプロの大工が使う工具のようなもの。
使いにくいし取っつきにくいし、扱いも大変で、整備もしないとすぐダメになる。
でも、DIYの店で買ってきた2x4の材料を安い工具でくっつけてハイ出来上がりでは出来ないものが作れる。 >>20
VMとDLLは異なる。
君の言い方を借りればVMは静的なライブラリ結合とは比較にならないオーバーヘッドが発生する。
だからダッカーみたいな技術が出てくる。
まあ、でもあんたのセンスは悪くないより >>23
なら.net frame workを使うWindows 上のC/C++/C#以下全部ダメなのか？
なんでお前はそんなに馬鹿なの？ >>30
普通の言語は表記法の大元を辿るとだいたいAlgolに行き着く。
だから、だいたいの書き方は似てくる。
他方Perl はAlgolの影響を受けたCなどから強い影響を受けているものの、文法自体はawkというテキスト処理に特化したツールの影響を強く受けている。
AwKはsedなどのストリームエディタの派生ツールで、要するに基本は文章を置換したり、整形するためのもの。
perlのそもそもの目的がそっち方向だったから、その分野のほとんど唯一の普及したツールであるawkを意識するのは突然だった。
だから全く異なる文法にならざるを得ない。 >>44
初見で、Rubyが何やってるかわからないというのは、百人一首は外国語だと思ってましたと同じくらいのヤバさ。 >>32
結局C++が次世代の主力と万人に思われながらフェードアウトしつつあるのはその表記があまりに複雑すぎるから。
それなら、メインの仕事以外ではpythonで良いじゃないのとなる。 >>38
なんでこんな程度の駆け出しにもならないアマチュアが俺語りを始めるのか？
お馬鹿なお前が大半の言語が合わないのは当たり前だろ。 >>58
ダメじゃないさ。文字列操作なら今でもトップレベルだろう。
でも、大昔のAlgolから始まった手続き型の言語の表記法は構造化、オブジェクト指向などを取り入れながら成熟し普及している。
Perlはその言語表記とは全く系統が異なるので、表記法から学習しなくてはいけなくなって、多くのプログラム作成者に負担になっているのだ。
Lispやprologのような人工知能言語やその拡張もそうだが、そっちは利用者が限られている,
SQLもかなり違っているが、あれはデータベース操作限定で、かつ面倒いことは隠蔽されることが多くなってる。 >>67
なんで君は、データストリームのオーダーとcompileの速度のような比較できないことを比較するの？
レーシングカーは1秒間に100m近く動くから、オートマチックじゃ間に合わないとか言ってるみたいな話だな。 >>66
そもそも言語仕様や言語のデザインで解決すべき問題ではない。
システム説明のレベルで解決すべき問題。 >>115
ソース出して。本人達はそんなこと一言も言ってない。 >>114
そんな話は10年前に終わってる。
今はそんな風に作られたシステムの更新しなきゃいけなくなって、それでプログラマーのヘイトを集めてる。 >>119
まあ、製作者の中心は海軍の将校様だからな。
タイプ量が増えるように設計しているという今とは全く逆の設計だ。 >>102
F#は無理だよね。
なんか実用的なシステムとは、無縁の人だね。
大学の院生とか？ >>126
そんなのいくらでも回避可能だろう？
とか思うような人はPerl使いでなくてもPerlをけなしたりしないか。 perlは最強の言語なのになぁ。
保守性が悪いって言うけどそんなことはないぞ。
アホが作ったコードがすぐわかるし、書き直すべきかの判断に困らない。
pythonとかrubyって、コーダーのレベルがわかるまで時間かかりすぎ。 >>131
Cだってstdioインクルードするし、なんだったらCOBOLなら使用者組織からターゲットのハード仕様まで書かせるぞ。 >>135
今は二つの方面からの攻撃がある。
昔からある攻撃は、簡便なwebページの処理に特化しているので、本格的に使用する際にはセキュリティ上やその他諸々の配慮が必要なのに雑誌やネットのサンプルのコピペと切り貼りで作ったようなプログラムが多くて、悲惨だというもの。
特にメンテ役になると頭を抱えることになる。
できれば諸々配慮したシステムにして欲しいが、依頼主からすると、動いているから問題ないとなる。
最近のphpプログラマー自身からの攻撃は、言語仕様が高度になりすぎて、わからなくなつているというもの。
これは前者のクレームに対応したということもあるが、php自体の使用範囲が拡大して汎用の言語として使われるようになり、それに対応出来るような言語となることが求められたという側面もある。
ただ、最新のバージョン7は普及が始まった3からの表記法とは全く異なるだけに、以前からの仕事を普通にこなしたいweb関係の業者から怨みの声が出ている。 >>140
すでに利用はPerlをはるかに凌いでいる。
UNIXの世界では標準になっている。
Windowsの世界でも開発者界隈では標準的なものになってるね。 >>142
没落したかはわからない。
暁光が作られる前の日本一のスパコンはIntelCPUで大規模なAIの基盤となるもの。
なんかネットの片手間記事の受け売りしかできない連中が多いね。 >>147
金になっても面倒臭いなというのは嫌につながるだろう。
新しい技術でサクッと進みたいのに、以降元がこれだからサクッと進まないって感じのランキングに見えるが。 >>149
でも現実には基幹系はPL|sqlで情報系はDelphiなんていう企業は稀によくある。特に金融。 >>174
なんでphoがwebで圧倒的と思ったの？
現実はJavaにシェアで勝ったことは一度もない。
だって大規模なweb開発ではJavaが圧倒的に多いから。 >>176
嫌われることは少ない言語じゃないの？
Cでスクラッチから開発したなら現場主導ではないことが多いからドキュメント類が残ってるだろうし、そうでなくてもプロの開発者ならコメントはしっかり残してる。
で、プログラムの構造もMakefileとかで最低限のところはわかるし、プロジェクトファイルがあればもっと色々分かる。
headerファイルに変数の情報は最低限あるし、構造体とかはどっかで必ず宣言されてる。
以降元としては充分だよね。 >>199
作れるのが嫌われるのではない。
あなたがいなくなったり、全社的なシステムの導入をするときにあなたの作ったそのシステムを解析して、同一の挙動をするプログラムを作るのが苦痛で恨まれるのだ。
同じようなとか、仕事に便利なようになら良いのだけど。
実際の仕事してたあなたが作った時とは違って、システム開発業者はあなたの作ったものと全く同じものを作ることが求められる。
プログラムの詳しい説明もないVBプログラムのリスト見ながら、変数名に一喜一憂し、do until とdo whileの使い分けに悶絶し、数字だった変数が文字として処理されてる部分の仕様確認で時間を浪費する。 >>209
お前は何もわかっていない。
本当に実務がわからない奴だな。 >>215
そもそもレイルズなければ広まりもしなかったのだがな。 >>225
何も知らない素人乙。
自然言語なら津軽弁でも京都言葉でも良いし、多少の間違いはいつでも修正できるがプログラムはそうはいかない。
かっこの位置が一つズレただけで全く動かなくなるし、最悪の時は動いても絶妙のタイミングで悲劇をもたらす。 わけわからないジジイ降臨ですまない
パールやらアセンブラやら、みんながしらない言語でやってたのよ。
皆はしらないかも、だが、
ほかのやり方が良いとおもったら、
ちゃんと、温故知新しろよ。 彼に対してそう言い方や、
本当に自分が正しいとしっかりしないかぎり
ダメだと思うのは俺は変ですか？ >>522
おじいちゃん。
やっと見つけた、ここにいたんだ。
さ､帰ろう >>524
皆より先にネンネ行こう、
恥ずかしながら、35である。
皆が若い民であると思うが、
本当によろしくね。 >>525
なんだよ、35歳なら、はなたれ小僧にもいかない
おっぱいおいしいの年代だ。
（続けるつもりならだが） 大変だがガンバレ！ ID:ohz972dwのように文句をつけたり否定したりするだけなら誰でもできる行為
文句以外にも少し情報を出してくれてはいるがプログラミング言語スレの話題としては少し物足りない
否定するなら正解や別案や改善方法または興味深い話題を振ってくれるとよい ５２６さん、すまんけど、おっぱいあんまり好きではないっす。。。
母さんができる、できないことを、自らに嫁にゴタゴタ言うのは、
と。。。
鼻たれですが、自らの心と判断なさって。 >>219
自分も「ぴゅう太」の語が浮かびました(笑) COBOLは扱いがどうのうこうのよりも、もう、話題になる事が無くなったって事やろ
まあ、まだ動いている所はありそうだけど、クローズなシステムでバグさえでなければ
そのまま死ぬまで動いてもらえば良いって感じな所も多そうだし >>480
"else if"を合成でelseif・elsif・elifと書くのはSyntax Sugar(糖衣構文)に過ぎないとみなせる
つまりelse ifへと置き換えてコーディングすることも可能
例えばその中でもPerlは一番自然にelsifを単純にelse ifに置き換えても動く（C言語と同じ表記になる）
if (cond1) {
} else if (cond2) {
} else if (cond3) {
} else {
}
ところがRubyはend方式ので同様にelse ifに置き換えると末尾にendが3つと不自然になる
if cond1
else if cond2
else if cond3
else
end end end
さらにPythonはインデント方式なので同様にelifをelse ifに置き換えるとインデント地獄で読みにくい書きにくい
if cond1:
else:
if cond2:
else:
if cond3:
else:
このように3者が全く異なる結果となってしまう いいお、ごめん。
あんまり考えても、今、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とかくらいだろ。 ■ このスレッドは過去ログ倉庫に格納されています
