【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 Perlで、use strictプラグマが出てから、
javascriptでもstrictモードが出てきたんだよな。
正規表現とか、ヒアドキュメントとか、最初の頃に主にPerlで作られたり発達した機能は、
結構 他にも真似されて移植されてるな 20年以上前に作られた組込機器のアセンブラが一番大嫌い >>438
何と言ってもPerlはLLのミトコンドリアイブだよ >>438
最新のJavaScriptはPerlの便利で良い部分だけをほとんど引き継いだよ
例えばPerlの便利な特徴である配列とリストの取り扱いも
JavaScriptではスプレッド演算子と分割代入の対応という形で明瞭かつ高度に対応してPerlより便利 >>438
正規表現はed辺りが最初だし、ヒアドキュメントもshの方が早いだろ
そもそも30年ぐらいの歴史しかないperlが起源とかあり得んわ >>443
元祖の正規表現はed(正確にはその前のQED)が最初だけど
現在広く使われている拡張された強力な正規表現はPerlが最初で合ってるよ
これがPCRE(Perl Compatible Regular Expressions)という名前のライブラリになっており
Apache, Safari, nginx, flash, MySQL, PHPなど多くで用いられている 殆どのスクリプトは最終的にはparrot仮想マシン専用にコンパイルされたものを
実行する形になるだろうから速度的にはどれも変わらないような結果となるだろうな。
javascriotもJITコンパイルされたものはネイティブのマシン語実行と変わらない速度だろうから
どれを選ぶかはユーザー次第だな >>447
parrotってw
10年前から時間止まってるのかよ parrotよりWebAssemblyが現実的な状況になるかもしれない
Google、Mozilla、Microsoft、Appleが合意して全てのブラウザが対応しつつある >>324
現在のJavaScriptはfunctionを使わずに
アロー関数で (arg1, arg2) => { return arg1+arg2;} と書くことも可能
>>328
現在のJavaScriptにはブロックスコープ変数もある
従来のvarは使われなくなってブロックスコープも可能なletを変数宣言に用いる
constも使える
>>434
現在のJavaScriptの言語仕様で困る人はいないと思う
従来の問題点は何もかも解決されている JavaScriptは型が曖昧だからメンテしにくいんだよ
ひとりで開発するならなんとかなるけどさ 型キチガイ向けにはTypeScriptがある
現在のJavaScriptもしくはTypeScriptの言語仕様で困る人はいないと思う
もし不満がある人は具体的に述べてくれ >>452
うん
だからTypeScriptなしでは開発やってられないと思ってる >>450
F#の |> と同等の式をJavaScript で美しく書く方法ある？ >>454
パイプライン演算子「|>」は単なる関数合成だから
arg|>func1|>func2|>func3
と
func3(func2(func1(arg)))
は同じ
JavaScriptはメソッドチェーンも使えるので
arg.func1.func2.func3
と書くことも可能 >>451
そんな時のためにstrictがあるんだろう。
でも、strictプラグマってPerlなら需要があるだろうけど、
javascriptでは殆どstrictを実装しようとは思わないな。
他人と共同開発するなら記述を厳格にする必要があるだろうから必要だろうけど >>456
それ使ったところでメソッドの引数や戻り値の型が判別できる訳じゃないからなあ >>455
関数合成は分かってるんだが、関数のマトリョーシカみたいな記述になるのがキモくてね
メソッドチェーンのその記法、prototype汚さずにマジで動くのか？
後で試してみるが >>457
＞引数や戻り値の型が判別できる訳じゃないからなあ
typeof関数を利用するんじゃ駄目なのか？ >>459
ほとんどobject型って言われるだけじゃね？ そこでstrictモード
判別できるようになる
function not_strict() {
console.log(typeof this);
}
function use_strict() {
'use strict';
console.log(typeof this);
}
not_strict(123); // => object
use_strict(123); // => number いずれにせよ実行してみないと型が分からんのじゃ保守しにくいわな 主流の言語のほとんどはいずれも型宣言をしない言語
型宣言がないと保守しにくいと言ってるのはよっぽどの馬鹿だけ
もちろんいずれも型を調べることは可能
Python 「type(var)」
Perl 「ref($var)」
PHP 「gettype($var)」
Ruby 「var.class」
JavaScript 「typeof(var)」 型宣言の有無と
自動型変換などの型の強弱は
同じ概念じゃない 型キャストを常に明示的に指定しなければいけない窮屈な言語はダメだね >>463
主流の言語である
C C++ Java C# Kotolin Swift 等無視してワロタ
いずれも型宣言が必要
型宣言のない言語は保守しにくしチーム開発にも向いてないね
他人が作ったコードとか自分が数ヶ月前に書いたコードとか追いかけるのが難しくなってくるからな 型を意識したくないとか昔のVBerみたいなこと言ってんな
あいつら糞コード量産してたわ >>463
あなたは、テストは人力でやった方が力がつくと信じてる人ですね。 現実を見ろよ
Python, Perl, PHP, Ruby, JavaScriptは実際に多くのサイトで用いられている
型宣言なんか無くても実用的な運用が可能である決定的な証拠だ そりゃ開発効率無視して根性と工数かけりゃ運用できるわ むしろ開発効率が良いからPython, Perl, PHP, Ruby, JavaScriptなどが多くの現場で使われている 型宣無しで運用できるものはいいと思うけどな。
型宣で特に問題になるのは、数字か数値か少数の扱いが主だろう。
型宣必要でも無しの言語でも大した問題じゃない。
むしろ、スクリプトの方が効率はいいとおもう 静的型付け主義を唱えてる民の半数は
動的型付けを旧VBのバリアント型のような感覚で考えてそう >>469
DBとブラウザとの間で値のやり取りするだけのシステムばかり。 ここまで、トミーぴゅう太の日本語BASICは無し。 変数の型を推測するのって空気読む能力に似てる気がする。 pythonの公式の勉強サイトが有能すぎて、今までの教材不足による逃げが通用しなくなった >>474
うちの界隈はツール類・データ収集＆処理・サーバーサイド・ブラウザ上・アプリ全てJavaScript >>479
表記の違い程度は大した問題じゃない
PerlやRubyのelsifを嫌っているならば
Pythonのelifについて感想をどうぞｗ >>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系ないからさ、
一緒にいたら友達になりたいタイプお。 ■ このスレッドは過去ログ倉庫に格納されています
