【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/ >>457
jqueryは使えて当たり前って扱いのところが多いけどね。 >>463
いや、マルチプロセスだろうが機器間の通信だろうが表現してるけど。 >>463
シーケンス図は代表的なものを書くんだよ
場合分けして何枚も書くけどな
包括的には状態遷移図で抑える
状態遷移図さえちゃんとしてれば、シーケンス図はオマケみたいなものだけど
動作を把握しやすいから書くけどな >>468
ミューテックスで排他制御前提なんだが、何が難しいんだ？ Googleはスタートアップ時点でJava
GoogleがC/C++に移行したのはエリック・シュミット（前会長）が構文解析プログラムをC++で書き換えたのが原因らしい
AmazonのスタートアップでのメインはC言語で、一部Perlだった（今はJava/C/C++）と聞いている
（Perlはベゾスがプリンストン卒業後に出来た言語）
Amazonは在庫管理システムが初めから巨大だったためC言語とUnixが適していた
聞くところによるとPerlはAmazon内で今でも使われてるらしいが、本当かは知らない
フロントエンドはGoogleもAmazonもJavascriptなので、JS系の技術者の需要は常にある
Pythonはこのスレで誰かが言っていたが、全てを繋ぎ合わせるツール的な使われ方で、知っていて当然の言語であり
プログラマーなら数週間〜数ヶ月を使って使いこなせるようにしておいたほうが良い >>469
アセンブラかよw
今はnode.jsのコールバックだよ >>471
node.jsは非同期機構を利用する側
node.jsそのものを実装する話
非同期機構の基盤を実装する話
非同期機構を利用させる側の話 >>473
コールバックが簡単だと思ってるのかよ
だめだこりゃw
プログラミング言語なんて、全部使えるのがプログラマーだしｗｗｗ 非同期が大変だからリアクティブとかプロミスとか
言ってみんな苦労してるのに AIみたいにわけがわからない世界にならないならプログラムなんてほぼ一緒 言語を覚えるというよりライブラリの使い方を覚えるのが今のプログラムだからなぁ >>12
某大企業が第一線でいまだに使ってるけど
しかも77レベルで >>482
C#はリアクティブを売りにしているんだがw >>484
面倒見たくないんならCで組めばいいなんて言わなきゃいいのに。 シュミット参加前からC/C++がメイン
ソースはThe Anatomy of a Large-Scale Hyoertextual Web Serch Engine
むしろシュミットが以前SunでJavaやってた人 >>487
いやお前にとっては難しくないって言ったからそう言ったんだがw >>470
PhytonもPerlもUnicodeで混乱するのはやめてほしい >>489
> シュミット参加前からC/C++がメイン
なるほどな。
Most of Google is implemented in C or C++ for efficiency and can run in
either Solaris or Linux.
しかし1997年の時点ではJavaになっている。
この論文は1998年と書いてあるが、出版された時期は違うようだ
1.1 Web Search Engines -- Scaling Up: 1994 - 2000
> むしろシュミットが以前SunでJavaやってた人
「Javaやってた」という表現には語弊がある
シュミットはLexの開発者でもある 非同期処理ってカーネル層だと大体解決してるイメージ何だけどjsとかだと苦労してるの？ >>489
Deposited On: 25 Feb 2000 16:00
Last Modified: 29 Dec 2008 09:52
ソースは1998, Aprilにも関わらず未来の2000年の話を過去として記述している
そして2008年に改変している
オリジナルのソースが欲しいところだな >>497
Javaサーブレットでは同期処理がほとんどだったが、
最近出てきたサーバーサイドJavaScript(Node.js)で
非同期処理がメインになってきたから >>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でのぞいたのかわからん。 ■ このスレッドは過去ログ倉庫に格納されています
