【IT】PythonがJavaに迫る勢い - 7月の開発言語ランキング [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
2017年7月の「PYPL PopularitY of Programming Language」が公開された。PYPLはGoogle検索エンジンにおいてプログラミング言語のチュートリアルが検索された回数から、対象となるプログラミング言語がどれだけ話題になっているかをインデックス化したもの。チュートリアルの検索回数を人気度と位置づけてランキングしている。
2017年7月におけるインデックスは次のとおり。
順位 プログラミング言語 インデックス値 推移
1 Java 22.6% ↓
2 Python 16.4% ↑
3 PHP 9.1% ↓
4 C# 8.2% ↓
5 Javascript 8.0% ↑
6 C++ 6.6% ↓
7 C 6.5% ↓
8 R 3.7% ↑
9 Objective-C 3.6% ↓
10 Swift 2.8% ↓
11 Matlab 2.5% ↓
12 Ruby 1.8% ↓
13 VBA 1.4% ↓
14 VisualBasic 1.3% ↓
15 Scala 1.2% ↑
16 TypeScript 1.2% ↑
17 Perl 0.8% ↓
18 Go 0.5% ↑
19 lua 0.4% ↓
20 Kotlin 0.4% ↑
21 Delphi 0.3% ↓
22 Rust 0.3% =
23 Haskell 0.3% =
http://n.mynv.jp/news/2017/07/07/053/images/002l.jpg
http://n.mynv.jp/news/2017/07/07/053/images/003l.jpg
長期に渡ってJavaが第1位を維持しているが、シェアは徐々に下がってきている。ほかのプログラミング言語ランキングでも同様の傾向を示している。PYPLプログラミング言語ランキングではPythonが高いポイントを獲得しており、そのポイントは徐々にJavaに迫ってきている。Pythonは採用されるシーンを増やしており、このままの傾向が続いた場合はPythonがJavaを超える可能性がある。
http://news.mynavi.jp/news/2017/07/07/053/ >>497
設計せずにいきあたりばったりで書いてるから ちなみにnode.jsはシングルスレッドでてきてる
libevent系のシステムコール使って擬似的にマルチスレッドみたいな動作にみせかけてるけど
実際はタスクシステムみたいなもの >>499
カーネル層はもう何十年も前から非同期処理メインじゃない？
>>500
シングルスレッドのjsには限界があるってこと？ 普通の手続き型しか知らないと
非同期のイベントドリブン形の動きがイメージしにくいと思う
アセンブラのインターラプトとか知ってるとすぐに分かるけどw >>502
ちゃんと設計すればnode.jsだろうがマルチスレッドだろうが限界はない
どちらも状態遷移表というものに抽象化されていれば非同期機構がなんであれ関係ない
ちなみに性能的にはマルチスレッドより、シングルスレッドによる擬似的マルチスレッドの方が速い >>504
それもそうか
所詮は状態遷移の結果か
疑似マルチの方が性能良いってのは切り替えコストと処理コストとの比じゃない？ パイソン用の書籍を効率良く売るための世論操作だったりしてw >>505
スレッドの立ち上げとかファイルアクセスとか処理をブロックするものを極力無くした(ノンブロッキングI/O)事で、軽量化と高速化を実現した Ｃとアセンブラ知ってれば、他の言語がやれる事は全て
やれるんだが。 最速で所要資源も最小で済む。
問題は、生産性だけだわ。
Ｊａｖａは、大規模で汎用的なシステム組むには、恐らく生産性が最強。
パイソンは、やっぱＡＩ絡みで伸びて来てる。
Ｒなんかも上向きなのは、その関係だろ？
Ｊａｖａｓｃｒｉｐｔは、Ｗｅｂアプリを統括的に組めるからだな。 エリック・シュミット
字句解析器生成プログラム lex の共同開発者でもある
2001年3月にGoogleの会長
The problem was fixed, Singhal says, by a breakthrough late in
2002 that utilized Ludwig Wittgenstein’s theories on how words
are defined by context. As Google crawled and archived billions
of documents and web pages, it analyzed which words were close to
each other. “Hot dog” would be found in searches that also
contained “bread” and “mustard” and “baseball games”—not
“puppies with roasting fur.
As late as 2002, the founders still sounded bitter when
explaining why Schmidt was hired. “Basically, we needed adult
supervision,” said Brin, adding that their VC investors “feel
more comfortable with us now—what do they think two hooligans
are going to do with their millions?” The transition was rocky,
but as the years went by, Page and Brin seemed to genuinely
appreciate Schmidt’s contribution. Page would come to describe
the CEO’s hiring as “brilliant.” >>507
うん？結局スレッドの切り替えコストが高くつく場合は疑似マルチの方が速いってだけのことだよね？ >>510
node.jsはイベントループでリクエストを受け取り、即座に応答し、次のリクエストを受けることが出来る。
実際の処理が終わったらコールバックを呼び出す。
処理が終わる前にどんどんリクエストを受けることが出来るので、外からはマルチタスクに見える。
今までのJavaマルチスレッドは複数人によるキャッチボールだとすると、Node.jsはバケツリレーのようなもの。 イベントループの考え方そのものは新しいものではなくてウィンドウUIのボタンやマウスのクリックのイベントと同じで、Node.jsのコールバックは、ボタンやマウスクリックのリスナーと同じ。 ただし、イベントハンドラの中で待つという事はやらない。
待つべき事象が発生したら指定されたコールバック関数が
呼び出される事でリクエストの処理が完了する。
元請けが１人で、単純な処理しかやらない多数の下請けに
受けた順にドンドン投げて行くような処理かな。
それら下請けからの部品が納品されたら、それを組み立て包装して
リクエスト先に発送するような、そんな動きですかね？ >>511
リクエストを受け取ったらプロセス起動しているだけでは？WWWサーバ側の
実装としては当たり前だと思うけど？ スレッドだとメモリ共有だし、同じ
プロセスが死ぬと道連れ。 >>489
>>491
> むしろシュミットが以前SunでJavaやってた人
来歴を見るとシュミットはSunOSからSolarisの方が長く、Javaの全てを見ているわけではない
Javaの設計に関わってはいても、ゴスリンとビル・ジョイ（viの開発者で、NFS、SPARC プロセッサ、Java、Jiniに貢献）がコア開発者と言って良い
「1988年の社内報的なビデオの中で、会長のスコット・マクネリが描いた同社の組織図において、ビル・ジョイは誰よりも（会長のマクネリよりも）
上に位置し、ジョイの上司を示す矢印は上方向を指しているのみ、というものだったという（彼の上司は、ただ天のみ、という意と解されている）」
シュミットは >>509 にあるように字句解析プログラムによる文脈検索抽出を成功させたことで当初心良く思ってなかった（他の記事では2人が当初から大歓迎という情報もある）創業者
を認めさせた
Javaについてはラリー・ペイジが1996～1997年に使っていたが、ガーベッジコレクションか何らかのバグで頻繁にクラッシュしていた
その後、知り合いに頼んでPythonに書き換えたら、今度は同時処理が10件程度の鈍足アプリとなり行き詰まりそれもボツ（原因は教授の分析によると言語が遅いから）、その後Javaに戻っていたと考えていたが
ソースの年が正しいなら、1998年秋のサービスの本格開始時点でC/C++に移行していた可能性は高い
1998年9月4日に設立とサービス開始後は順調にいっているが、Googleが社会に認められたのは、2002年であり、これはシュミットの成果だと言えるので
中興の祖的な立ち位置か、サンにおけるビル・ジョイの位置をGoogleで確立したと考える Node.jsについては良いまとめがあるのでリンクを貼っておく
http://qiita.com/kyrieleison/items/f726061803a0e536c3e1
「デメリット
・並行処理を行わないため、マルチプロセッサ環境を活かすことができない」（内容は大半をカット） >>146
lisperが「本物のプログラマはPascalを使わない」いうてたじゃないの
Cなんて大体Pascalだから、本物のプログラマならCは使わないべき >>251
商用開発には使えないでしょ。ライセンス的に。
個人で開発や勉強やるには良いにしても。 >>321
WebとAndroidがJavaの主要ニーズだけどどうなんだろうね
前者はScala後者はKotlinに徐々に喰われていったりしないのかな 何をやっても
ライブラリをつなぐだけ
ライブラリの中身はC言語
だから日本のITは儲からない >>449
なるほどなあ。いろいろ要求が付くんだな >>518
それはデメリットになってないとおもうぞ。
それに非同期で動くから、マルチプロセッサではなくとも並列動作はする。
メリット面もある。
たとえばサーバーサイドで動作させる場合、一つのプロセスが資源食い尽くさないから。
フルパワー出しきると、バクなどあったとき困る。 VBAのかわりにPythonを使ってる人いる？
Pythonの方が人口知能も使えるし
VBAよりも速いだろ？ >>519
本物のプログラマが使う言語は、fortranやAda、lisp使いはキャッシュ
イーターだと書かれていたと記憶しているんだが？ 大学ではターボパスカルだった
翌年からCになったけど 自動運転関係のソフト開発に関わっているけど、組み込みなのでC言語が
メイン、Windows上で動かすシミュレータ関係はVC++、自動ビルドのスク
リプトに他人が書いたSconsやPythonスクリプトを使ってるけど、ロクに
ドキュメントが作成されていないので,プログラムの挙動がおかしなときは
ソースを追わなきゃならん。 >>525
Excelワークシートのセルを操作するようなVBAの処理をPythonでやらせると、
糞遅い。C++からOLE経由でやっても遅い。同一プロセス内で動くVBAにはかなわない。 >>516
新しいプロセスは起動しない。全て一つのプロセス、一つのスレッドで行っている。 瑕疵担保責任（かしたんぽせきにん）
納品されたシステム、プログラムに不具合があった場合、10年後でも無償で修理してもらうことが可能になった。
民法改正で事実上期限が「無制限」になった
不具合を指摘されたらすぐに行動をとるべし 納品物に不具合があれば損害賠償を請求される可能性もある
http://www.atmarkit.co.jp/ait/articles/1706/26/news014.html
http://itpro.nikkeibp.co.jp/atcl/news/17/052601508/?rt=nocnt
改正法では欠陥に気付いてから1年以内にITベンダーに通知すれば、通知後5年以内は修正や報酬の減額などを求められるとしている
全ベンダーが泣いた民法改正案を解説しよう その1
http://www.atmarkit.co.jp/ait/articles/1609/14/news009.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_2.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_3.html
ポイント1：修補や損害賠償、契約解除の期限がなくなる
従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。
条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、
その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、11年後まで請求可能なのだ。
もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。
重大な脆弱性が現バージョンから発見されました。こちらでアップデートしたところ、起動ができなくなりました。
至急弊社に来て修正作業をお願いします。なおお金は払わない。また営業に損失が出たので損害請求もする。 >>524
遊ばせておくためにマルチコアのサーバーを用意するわけじゃないからね。 >>532
民法は他の法と異なり基底クラスみたいなものなので
契約書というサブクラスを用意してオーバーライドすれば問題なし サーバーだったら普通マルチプロセスだろ。
同時アクセスでプロセスが多く発生するから
個々はシングルプロセッサ動作のほうがいい。 >>534
少し語弊あるので補足。
強行規定というオーバーライドできない規定もある。
瑕疵担保責任の改正部分は任意規定、つまりvirtualがついたメソッドみたいなもんだ。 >>534
コンペで確実に負ける
そんな御社とは契約しません！ 話の流れを見るとどうでも良い流れになっている
流れを整理する
>>469 が排他制御に言及
>>471 が排他制御の流れで唐突にNode.jsに言及
>>473 がNode.jsはC/C++等で実装され、Node.jsがその機能を使う側と指摘
>>502 がカーネル側では古くから非同期実装があり、新技術ではないと指摘
>>524 はサーバーコアをフルに使うべきでないと主張
>>533 はアイドルコアの問題を指摘
>>535 はWeb系の標準慣行であるマルチプロセスに言及
C++とChrome V8（C++）で書かれたNode.jsのシングルスレッド内の並行処理性能とマルチコア並列を厳密に定義するだけで解決する
-シングルスレッド並行化
-マルチコア並列化
Java/C++/C#では何れでも高速にできるが、Node.jsではマルチコア並列化はマルチプロセス限定という理解で良いのか？
現在バブル気味な画像処理や自然言語処理といった並列化演算をNode.jsマルチプロセスでの試みは聞いたことがないし、できても大変だろう
-レジスタ分割式並列化
-GPU/FPGA/ASIC並列化
並列化技術の中心はGPUやFPGAでありC/C++/VHDLが中心となる
そしてUIはPythonを使って呼び出すのが標準慣行だ
組み込みは >528 が指摘してる通りC言語だ >>538
Node.jsはwebの問題。非同期I/Oもwebならではのスケーリングしない問題を解決する方法の１つに過ぎない。
Node.js のマルチコアが生かせない問題 → ２コアのＣＰＵも売ってるから、それ使えば？
レンタルサーバーが Core i7なんだけど勿体ない → コア数分だけ複数のサービス走らせれば？
Nginx を Node.js のリバースプロキシとして使ってなんとかすれば？
どれも取るに足らない話。既に解決済みのこと。
結局、C/C++が最強だね！ → 大手がカリカリにチューニングするために雇ってる人材はかなり少ない。某ドワンなんとかでも数人。
チューニングした結果、サーバーの台数が節約できるなら、どこだってするだろうよ。アセンブラだって使うだろうよ。人件費に見合うならな。
C/C++の最大の問題は、生産性が悪いこと。
C/C++で生産性が高ければ、他の言語が流行るわけないだろう。
>-レジスタ分割式並列化
>-GPU/FPGA/ASIC並列化
>
>並列化技術の中心はGPUやFPGAでありC/C++/VHDLが中心となる
>そしてUIはPythonを使って呼び出すのが標準慣行だ
Pythonが活躍しそうなところ。機械学習系、大規模処理系。オフラインでのバッチ処理。
webとは全くの畑違いだね。
生産性のいい言語を使うのと、C/C++の高速なライブラリを早く、お手軽に使える、ことが求められているんだろう。
CUDA に対応した時期を考えると、Pythonは割と早め。Rも早め。
Ｒｕｂｙとか、他のweb系のはほぼやる気なし。
Ruby使ってると、絶望的な気分になるね。もう、言語構造からして古すぎるし、何かをちまちまとループ回して実行するしか出来ない。
それに、まともなライブラリや拡張が無い。Array Hash 手の入れようがあるのに、やる気なし。Vector そんなのもあったっけか。
matrix系の拡張ライブラリ、ほぼやる気なし。使う人もいない。なぜかメモリだけはガバガバ食うし、ガベージコレクションもいい加減。 あえて、Nodejsはシングルコアにしてるんだろ? サーバーでマルチプロセスが発生するから。
はじめてのNode.js：マルチプロセスアプリケーションを作成する | OSDN Magazine
Node.jsは原則としてシングルスレッドで動作する。そのため、多くのリソースを消費するプログラムでは、リクエストを受信してからレスポンスを返すまでの遅延が大きくなってしまう可能性がある。
このような場合、複数のプロセスでプログラムを実行し、リクエストを振り分けることでサーバーのCPUリソースをより効率良く利用できる可能性がある。
今回はNode.jsで複数プロセスを利用するための方法を紹介する。
https://mag.osdn.jp/13/04/23/090000
まえおき
Nodejsのclusterモジュールのドキュメントを読んでいて、
「ほぉ、並列化って簡単にできるんだなぁ」と感じつつ、関連記事をいろいろ調べてみると、
並列化すればスループットが上がる
マルチコアの場合は有用。CPUのコア数と同じにすると良い
ワーカーやアプリケーションサーバなどは横に並べとけ
的な記述が色々あり、違和感を感じました。
マルチスレッドができる言語でやる"並列化"と私が調べているものは別物なのでは？ と。
https://blog.leko.jp/post/learn-multi-thread-and-multiplexing/ 最近のWeb系ってその辺の基礎知識無くてプログラム書いてる人が多いのかなぁ >>542
その辺がどの辺か知らないけども、基礎知識無くて書いてる人は多いよ。
Ruby on Rails で富豪的プログラミング。
メモリーは何十ＧＢもある前提。
何かが不足しているなら、台数増やせばいいんじゃないの、という発想だね。
小さなテストケースで動かして、動いたから実戦投入して、何万人も来たら、あとは、クラウド代金との勝負みたいなのは、よくある。
AWSが儲かるわけだね。 わしアセンブラとCしか使ったことないけど20年ぶりにJAVA猛勉強中
JAVAて、構造化して簡単にプログラミングすることを目指したもんやと思うけど逆にややこしくなってると感じる
アンドロイドのプログラムとか手続きがうっとしいわややこしいわで苦戦中や 今のブラウザ系はサーバサイドにnode.js+Expressやpython+Flask、Ruby+Rails使って、
web側はossとテンプレートとjQueryで力技解決する、みたいな事は割とある。
jQueryの$('#なんとかかんとかのid')とか書くようになったらもうdocument.getElementByIdとか
面倒すぎて書かんしなあ。 >>454
Computer vision engineerいいな
しかしどうせやっすい給料なんだろなあ C++は結局高速化・省メモリという用途に限定した「ドメイン特化言語」ということだね。
器用貧乏の慣れの果てとしては皮肉だけど >>540
>C/C++の最大の問題は、生産性が悪いこと。
生産性はその個人のスキル・経験に依って異なる
C/C++で他の言語と同じぐらいの短期間に組めるハッカーは世界を見回せばいる
特にアメリカには多くいるが、それでも人材不足な状態ではある
日本にそれらの人材がいないという表現なら半分は正しい
実際は組み込みでは、C言語を使える人材は腐るほどいるはずだが
報酬の低さや多重下請け構造の土方が多くハッカーが生まれる土壌ではない
組み込みの延長線としてソニーの機械学習はC++、クライアントにPythonを使っている
【機械学習】ソニーがディープラーニング用“コアライブラリ”をオープンソース化。
http://egg.2ch.net/test/read.cgi/bizplus/1498529223/ エリック・シュミットの例で言うなら、字句解析器LexとSolaris/SunOS等のOS、それと間接的ではあるが
Java仮想マシーンの生みの親と同時期に肩を並べた技術力がGoogleに見事はまったわけだ（当時でさえ古臭い技術ではあったが）
Google初期の言語による問題もC/C++によって解決したことからも、その手の人材は国際競争力に直結する
シュミットレベルのハッカーは日本には今のところいない
ハッカーを褒められるどころか損をするお国柄であり、封建主義的・前近代的な企業文化と経済・雇用構造でハッカーが生まれるわけがない
日本企業は属人的な技術力を嫌うため誰でも使えるツールに拘り、誰もが使いやすい平均的な言語を好む（極端に言えばノンプログラマーでもコードができる言語が理想的となる）
そのため個人の能力差が露骨に生まれる言語を嫌う傾向が如実だ
反面、日本のオタク発生率は他国に比べて高い、確実にシリコンバレーよりも高いだろう
ハッカーが生まれるベースだけは無駄に広いということだ
日本のソフトウェア開発者がアメリカにいくのであれば、C/C++にこだわる必要は全くないが
最低でもC/C++/Java（この3つはCS学科で使う主要言語のため）の一つで見苦しくないコード設計
でアルゴリズムを組めないと大半の面接で落とされるだろう。選択肢を低く設定するのは挑戦してからでも遅くはない
同時にOOPが出来なくても良いというソフトウェア開発職種の方が少ないということも頭に入れておいた方が良い 初心者なんだけど
ともかく なんでもいいから１つの言語で
どんなものでも作れるようになるのが上達の近道なんじゃないかなと思うんだけど
ちがう？ >>554
「どんなものでも作れる」を満たす言語となるとCとかC++とかだけになる。 >>554
頭の回転が早いタイプだと早ければ数日～数週間で簡単と感じるようになり
それで飽きてきた倦怠期で潰れる人間が多いな
この資料のページ6にあるのはスタンフォードのカリキュラム
http://www.kantei.go.jp/jp/singi/keizaisaisei/miraitoshikaigi/dai8/siryou2.pdf
これによると学習は2つに分けている
-入門（Unix/オブジェクト指向/言語の基礎）、シェルとC/C++/Javaのどれか
-自主学習（ウェブアプリケーションやゲーム等）、好きな言語で好きなものを完成させること
つまり好きな言語で学ぶと同時に基礎をつける事が大事
入門は半年以上かけないようにした方が良い（それ以上かけても教育的な効果はでないし必ず飽きてくる）
次の基礎は、アルゴリズム・ソフトウェア・ハードウェアを学ぶべきだが、C/C++/JavaのどれかをCS勉強用言語として一つだけ選択しておくと良い >>554
上達が言語への精通って意味ならそうだね
いずれ得手不得手を知ることになる
ハッカーになるってならどのように作るのか、が重要
幅広いデザパタを学ぶために人のコードを
読んでパクって実装するのが良いかと やりたいこと次第だね。C/C++だと目的地に到達する前に力尽きる確率が高いｗ
例えばWEBブラウザならJaveScript一択だけど、最初に選ぶ言語ではない。これは不幸なことだと割と真剣に思う。 >>542
基礎知識って、CGIでのデータ処理がどう通っていくか？ってこと？ ゲームだったら C#+Unity...と言いたいとこだけど、言語を学ぶには向かないな。
コーディングしないでも結構なことができてしまう。
純粋に言語を学ぶならCが良いんだけどね。目的があるなら、そこでメジャーな言語を覚えるのが良い。 >>280
テンプレートの仕組みは最強だよね。
なんでJavaでのぞいたのかわからん。 >>562
いや、最初はそれでいい
最小限の学習で作れるものが作れる、が最も良い
ただ、プログラマーで食っていく以上、自分のスキルと向き合う必要がどっかで出てくる
そこで初めてガチ勉強、でも全く遅くない 日本だとJava！PHP！C#！って感じになるのかな
ランキングから世界は業務系が縮小して分析や制御が拡大してるの分かるな
日本だと未だに業務系一辺倒だからなあ
IoTをバズワードと馬鹿にしてるうちにまた周回遅れか >>470
JavaなのはBackRustじゃないかな
前身研究のstanford.eduの奴 >>552
何をどう言いつくろおうが、C/C++は生産性が悪い。
C/C++ の需要。
組み込み系 C/C++しか動かないから選択肢がない。
高速化系 他の言語で十分に検証したものを移植するだけ。
どちらも面白い仕事ではない。前者は給料安いし、後者はよほどいい職場じゃない限りやりがいが無い。
第一、学校で教えてるでしょ。ある程度。
大学で教える言語でC/C++が一応出来るって人は大量生産されたけども、他の言語が流行ってるってことは、
新規で新しい言語覚えるコストを払ってでも、新しい言語に利があるということ。
スーパハカーとかの話はしてない。そういう連中はどんな言語だって出来るんだから。 言語の生産性はあんまり変わらない。
C++より面倒なJavaプログラマーが大量に募集されているってことはそういうこと。 Java は実需。
特定業務用に大量に人が必要。
最近は供給が増えすぎてるけどもね。
Java のみでやってきた人に言わせると、一生これで食っていけるから、他の言語覚える必要がないんだと。 言語の生産性を第一に考えるのはエンジニアとしては二流だと思うわ
まあ俺みたいな若輩者の言うことは無視してくれて構わんで >>567
ちなみに、大学ではどんな言語でも講義に最低限必要なことしか教えないのが普通なので
大学で◯◯言語使ってましたというのは参考程度にしかならない。 いや、生産性は大事だぞ。何ならアセンブラしかなかった時代を想像してみると良い。
歴史の視点を持つこと、思考を極端に飛ばしてみること。エンジニアでも十分役に立つ。 >>565
そうとも言えんな。
上位５言語で７０％くらいある。
つまり、業務系なんやろw
後は制御とゲームやろうね。
機械学習とか分析系は研究職から出ないからな。
エンジニアが幾らRを覚えても、統計学は知らんからな。
統計分かってる奴らの手足になる安月給の助手止まりにもならず、
統計分かってる奴らが自らRを書くやろうし。 生産性においてアセンブラを出すのは極論だと思います。
それに無碍にして良いとは言ってないです。 ならCOBOLならいいのか？
エンジニアもサイエンティストの一端だから、その辺りの素養も大切だぞ？ COBOLは歓迎できないがエントロピー問題として許容すべきだと思っています。 >>567
ミドルウェアより下は最初からC/C++が圧倒的に多いだろ
ブラウザ本体とか >>577
ならアセンブラが極論でCOBOLが許容範囲な論拠を示さないとならないな。そこでは歴史が役に立つ。歴史を学べば我々が巨人の肩に乗った小人に過ぎないことも自ずと解るだろう。
哲学から自然現象を切り出したのが科学で、科学の実利的な分野にフォーカスしたのが科学技術。情報技術はその一分野であり、その実務者が上位の視点を持つ必要は必ずしもないが、役に立つこともある。 >>581
敢えて言われると難しいですね。
知れば自明と感じると思っていたので。
しばし考えているので、極論ではないと考えた理由を聞きたいです。 >>582
自分は生産性が大切とは言ったが、アセンブラが極論でないとは言ってない 。生産性より性能が重視される場面もあるからね。
逆に生産性を第一に考えなければならない場面もある。一刻も早く製品を出さないとならない時とかね。
今のご時世、競合に先を越されたら死活問題になることも少なくない。生産性が大事だと言った論拠の一つがそれ。 >>581
あー強いて言えばcで書けるから、
かなかなあ。 >>583
ならCで書けないか？
実はアセンブラ詳しくないから断言できんが。 >>585
Cの話はしてない。勿論念頭にはあったが、歴史的な観点から出さなかった。
モダンな機械学習フレームワークのフロントエンドがPythonなのも、生産性が重要な論拠の一つだね。
これがC/C++だったらここまで流行ってなかっただろうし、仮にそういうフレームワークがあっても淘汰されてただろうね。 >>578
> ミドルウェアより下は最初からC/C++が圧倒的に多いだろ
> ブラウザ本体とか
ブラウザ本体を作れる仕事とかレアすぎませんか？
速度重視・メモリ消費量重視・なにもかも重視、ただし開発期間を除く、の仕事だろうな。
ミドルウエアでもいいけども、ライブラリもだね。
何か、面白いことをしようと思った時に、C/C++は第一選択肢になりにくいと思うよ。
逆に堅実すぎる仕事は沢山あるね。しかし、製造業とか平均的に給与が低く納期も厳しいジャンルが多いと思うわ。
linux のカーネルいじりたいとか、元がC/C++で書かれているから、仕方がないジャンルはあるけども。 >>587
性能が必要な部分は今でもアセンブラだぞ。
Cコンパイラが生成するアセンブルコードを見れば分かることだが、熟練者のコードに比べると効率が悪い。だからインラインアセンブルなんて機能がある。
それに機械学習だとCは入り口だけで、中身はハードウェアと言うことも多い。そうなるとVerilogとかの話になる。 >>589
大半はCで部分的にアセンブラでって程度では？
アセンブラが極論と言ったのはアセンブラで全て実装と思ったからです。
アセンブラで全て実装するなんて言ってないと言うなら不毛なので寝ます。 >>589
小さいコードで済む問題なら
人間が書いたアセンブリが速いけど
コード量が増えると実行プロファイルを
最適化に使えるJIT実行環境が速い >>588
ライブラリはミドルウエアの典型
OpenSSLとかWebKitとか >>591
おやすみ。こちらも寝るわ。
ちなみに上でアセンブラを引き合いに出した時は、全てアセンブラで作るイメージで正しい。COBOLが作られた頃はまだC言語は生まれてなかったからね。
COBOLやFORTRANが作られた歴史を紐解けば、当時から生産性が重視されてたことが解ると思ったんだ。 >>592
上にも書いたが、機械学習だとコア部分はアセンブラを通り越してハードウェアで丸々実装することもある。そこはJITナニソレな世界だ。 今の機械学習はPythonからFPGAを生成するらしい。
C/C++もいらないんだと
機械学習／Deep Learningの仕事が増える2017年、ソフトウェアエンジニアがFPGAを学ぶべき理由
http://www.atmarkit.co.jp/ait/articles/1701/30/news007.html
> ──FPGAでディープラーニングを手掛けるのに、Pythonが書ければOKなんですか？
>
> 中原 OKです。C言語すら書けなくていい。 >>596
それはPythonからFPGAを叩くイメージ。Pythonで論理合成する訳じゃないよ。
仲介するのはC関数なので、C言語が不要になる訳じゃないけど、ユーザは意識しないで良い。 生産性＝アウトプット÷生産にかけた人数
① アウトプット＝量
性能関係なく数を増やすと生産性は上がる
② アウトプット＝利益
性能が競合を圧倒し、コストに関係なく安売りをす必要がないと生産性は上がる
前者が典型的な労働集約型、後者は知識集約型産業に多い >>598
△② アウトプット＝利益
◯② アウトプット＝収益-非人件費コスト
これであってるかね？ アウトプット＝収益でも良さそうではあるが >>596
> 今の機械学習はPythonからFPGAを生成するらしい。
> C/C++もいらないんだと
>
> 機械学習／Deep Learningの仕事が増える2017年、ソフトウェアエンジニアがFPGAを学ぶべき理由
> http://www.atmarkit.co.jp/ait/articles/1701/30/news007.html
この手の記事を読むと必ず出る質問。
Pythonで書いたプログラムをそのままハードウエアにできるの？ 答：できません
Cでx86のエミュレーター作ったんだけど、ＣＰＵになる？ 答：できません
ソフトウェアを書いたらハードになるって話は？ 答：嘘です
HDLを大真面目に勉強しないと、何が出来るかは理解できない。
ソフトウェアエンジニアがFPGAを学ぶと、その異次元さに付いてこれない。
なんなく用意されているライブラリをなんとなく使うという意味なら、多分使えるんだろう。
その中で何が起こっているかを全く知らなくても使えるんだろう。
これはどんな言語でも同じ。
CUDAのライブラリがあれば、GPUの構造を知らなくても、速く計算できることだけはわかる。
誰でもわかる。
ちなみに、XilinxはＦＰＧＡの石を作って売ってるメーカー。そこのＰＲ記事ですね。
FPGAは、Alteraという会社もあって、今はインテルと合併したんだっけか。
多分、Xilinx記事レベルで言ってるのは、こういうこと。
https://www.altera.co.jp/products/design-software/embedded-software-developers/opencl/overview.html
https://www.altera.co.jp/content/dam/altera-www/global/ja_JP/video/opencl_tutorial_p1.mp4
OpenCLライブラリを使ったら、速くなりますよ。と。
ものすごく高い石を買ってね、と。
２０１３年版のが最新なのか。その後新製品出てないんだな。 ■ このスレッドは過去ログ倉庫に格納されています
