言叶の限界は一人の世界の限界
4076 ワード
言叶の限界は一人の世界の限界
言語の限界は一人の世界の限界であるヴィトゲンシュタイン
Ruby on Railsの世界
多くの人はあなたに教えて、異なるプログラミング言語を学ぶことはあなたに新しい世界を見ることができて、あなたの思考の方式を変えて、プログラマーの修練の道の中で甚だしきに至っては“毎年少なくとも1つの新しい言語を学ぶ”ことを提案して、Peter Norvigが10年の学会のプログラミングの中で提出したように、少なくとも半分の言語を学ぶことができます.私はこの観点に賛成だ.
私はC++からプログラミングを学び始めました.ほとんどの仕事時間もC++を使っていますが、よく「惑わされる」ことがあります.ある言語の良い文章を吹聴すると、我慢できずにこの言語を勉強して、なぜいいのか理解します.それに仕事そのものの必要もあって、もうたくさんの言叶を勉强しました.しかし、今回のようにルビーon Railsを学んだことは一度もなかった.一般的に新しい言語を学ぶといえば、今の知識から遠いほどいいと言いますが、本質的には全く異なる環境に触れ、全く異なる分野に入る必要があります.しかし、私は以前あまり理解していなかったので、言語はたくさん勉強しましたが、実はずっとゲームをしていて、新しい言語を勉強しています.また、この言語で書かれたゲームエンジン(あるいはこのスクリプト言語で駆動されたゲームエンジン)を探しています.もちろん、以前はこのような状況が発生しました.一部の原因は私がわざとゲームに専念するためです.今回は落ち着いて、ルビーon Railsをしっかり学んで、まだ純粋なホームページではありませんが、クライアントのバックエンドをしていますが、もうゲームを書くのとは全然違う感じがします.その中で最大の感じは、ウェブ開発分野の自動化の程度が高く、ゲーム開発がまるで前世紀にとどまっているかのように、本当の牛のゲーム開発に触れたことがないのではないかと疑っています.
特にGemとBundle.GemというRubyのパッケージ管理システムは本当に便利で、新しいライブラリを発見しましたか?単純な
ルビーon Railsの世界以外
私の反応は、他の環境にGemのようなパッケージ管理システムがないのではないでしょうか.耻ずかしいことに、もとは本当にあって、ただ私はこれまですべて知らなかっただけで、Pythonのpip、Objective-Cのcocoapods、最も惊いたのは、Bundle思想のVimのプラグイン管理Vim Bundleのようなものがあって、この名前からこの兄たちがどこから学んだこのような自动化管理思想を知っています.考える価値があるのは、なぜ私はずっとそれらの存在を知らないのか、私が寡聞だからなのかということです.私はほとんどRubyを学ぶと同時にGemを知っています.ほとんどのサードパーティのライブラリがGemでインストールすることを教えてくれますが、他の言語は...これが生態系の違いではありません.BTW:GemはRuby 1から.9から、すでにルビーに内蔵されています.
C++の世界?
ObjCにはcocoapodsがありますが、C++は?C++自体がプラットフォームにまたがる負担のため、各クラスのライブラリのコンパイル方式は様々で、歴史的伝承の原因を加えて、古いものが共存して、原始的なmakefileからautoconfまで、少し新しいCMakeまで、antも使っていて、コンパイラもVS、g+、llvmなどいくつかあります.サードパーティのライブラリが通用するパッケージ管理をするには、私の考えではほとんど不可能です.しかし、Windowsに対するVS、Linux/UnixのG++など、特定の環境に対しては可能である.面白いことに、本当にあって、すべて成熟していないようですが.いわゆるwindows-package-managerを见つけて、Npackdはいくつかのライブラリをダウンロードすることができるようで、不思议なことに、これらの友达は意外にもわざわざUIを开発しました...本当に思惟の违いですね...まさかみんなはUIのものがなくてWindowsの上で谁も役に立たないと思っていますか?Windowsの腐った使えないshellのためですか?VSをサポートするNuGetですが、管理に特化しているようです.Net、悲しい.この過程で、私はまたApache Mavenを発見して、Apacheが発起したJAVA用のパッケージ管理ツールです.
疑う必要はありません.結果は明らかです.C++はまだ少し成熟していません.使えるレベルのパッケージ管理ツールは、VSの中でもg++の上でも、そのためです.Pythonを勉強している間に、似たようなツールを探すことさえ考えていませんでした.実はeasy_Installとpipの成熟度はまだ高いですが、C++からの考え方は、私を制限しています.これは私の今の実感です.開発の過程を思い出して、VSの中で1つの工事を配置するのは本当に1つの苦痛な過程で、そのため少しの経験がなくて本当にできないで、しかも間違いやすくて、フォーマット、カタログなどが乱れてまた後の開発に影響して、この原因のため、私が仕事をしたばかりの時、たとえ1つの私自身が最初から開発した新しいサービス端のプログラムであっても、(私はサービス側から開発を始めました)すべて私たちのメインプログラムが工事を配置して、いくつかの自分のライブラリと第三者のライブラリの依存問題を解決した後、私は再び符号化を始めました.このサービス側のプログラム構成は、全手動で、簡略化するために、私たちが自分で作ったテンプレートからcloneを出て、それから調整します.私がチームを連れて行く時、初期も自分で工事を配置して、比較の後期になってやっと他の人にこの仕事をさせることができて、私はとっくに彼らのコードに対してかなり安心していますが.この過程を思い出すと、この過程がどんなに苦しいかがわかる.C++そのものがどれだけ負担するかにかかわらず、実際の開発過程はRORにとって確かに太原から始まった.以上の体験から言えば、C++は非常に難しい言語だと公認されていますが、サードパーティライブラリとC++を正しく配置する工事は、C++自体を書くよりも難しい...--!そのため、C++ライブラリの开発コミュニティには逆の流れがあるかもしれません.それは、自分のライブラリができるだけ第三者ライブラリに依存しないことを利点としています.简単に言えば、第三者ライブラリに依存しすぎて、配置が面倒で、ライブラリを使う人はいません.これは、良いパッケージ管理があれば、问题ではありません.これはある程度コミュニティの良性の発展を制限して、すべてのライブラリが山積みの基礎ライブラリを持っているのはどういうことですか.この問題はC言語でもっと深刻なようです.STLもないからです.
最後の感嘆
以前の経典のC++プログラマーとPythonプログラマーの間の論争を思い出して、その時また中国人のけんかの知恵に感嘆して、ここを見て、C++の使用者たち(私を含む)は多くの時自分がC++を使って開発する効率が低いことをC++言語自身が効率のためにした犠牲、つまりその自身の複雑さに帰結します.BSが言うように「絶対的に複雑な問題は比較的複雑なツールで解決する必要がある」.実際には、上記の典型的なプロジェクト構成プロセスを含む開発環境の一部がありますが、私たちは意識していません.
リスト#リスト#
ここは私が整理したパッケージ管理ソフトウェアのリストです.
Ruby:GemとBundle Python: pip
Objective-C: cocoapods
Vimプラグイン:Vim Bundle Lua:LuaDistとLuaRocks JAvascript:cpmとjam nodejs: npm
JAVA: Maven
.Net: NuGet
PHP: PEAR, composer, Maven for PHP
Windows: Npackd
言語の限界は一人の世界の限界であるヴィトゲンシュタイン
Ruby on Railsの世界
多くの人はあなたに教えて、異なるプログラミング言語を学ぶことはあなたに新しい世界を見ることができて、あなたの思考の方式を変えて、プログラマーの修練の道の中で甚だしきに至っては“毎年少なくとも1つの新しい言語を学ぶ”ことを提案して、Peter Norvigが10年の学会のプログラミングの中で提出したように、少なくとも半分の言語を学ぶことができます.私はこの観点に賛成だ.
私はC++からプログラミングを学び始めました.ほとんどの仕事時間もC++を使っていますが、よく「惑わされる」ことがあります.ある言語の良い文章を吹聴すると、我慢できずにこの言語を勉強して、なぜいいのか理解します.それに仕事そのものの必要もあって、もうたくさんの言叶を勉强しました.しかし、今回のようにルビーon Railsを学んだことは一度もなかった.一般的に新しい言語を学ぶといえば、今の知識から遠いほどいいと言いますが、本質的には全く異なる環境に触れ、全く異なる分野に入る必要があります.しかし、私は以前あまり理解していなかったので、言語はたくさん勉強しましたが、実はずっとゲームをしていて、新しい言語を勉強しています.また、この言語で書かれたゲームエンジン(あるいはこのスクリプト言語で駆動されたゲームエンジン)を探しています.もちろん、以前はこのような状況が発生しました.一部の原因は私がわざとゲームに専念するためです.今回は落ち着いて、ルビーon Railsをしっかり学んで、まだ純粋なホームページではありませんが、クライアントのバックエンドをしていますが、もうゲームを書くのとは全然違う感じがします.その中で最大の感じは、ウェブ開発分野の自動化の程度が高く、ゲーム開発がまるで前世紀にとどまっているかのように、本当の牛のゲーム開発に触れたことがないのではないかと疑っています.
特にGemとBundle.GemというRubyのパッケージ管理システムは本当に便利で、新しいライブラリを発見しましたか?単純な
gem install xxxでよいとともに、依存する他のすべてのライブラリを自動的にダウンロードする.工事に加えるには、GemfileにGem 'xxx'、Bundle installを1行追加すればいいです.C++の中でどのようにVSの中で1つの新しいライブラリをプラスして1つのライブラリを削除してあるいはライブラリの更新を連想して、私はすべて泣きます.C++の中で、配置とロードの1つの大きいライブラリはすべて単独でブログを书くことができて、例えばBoost、Qtなど、私はまた本当に书いたことがあります...同时に、本当にRubyを1つのプラットフォームとして管理して、またセットのGemのウェブサイトとruby-toolboxがあって、いくつかの类似するGemがどれを使うか分からない时、このウェブサイトのダウンロード量を见て、あなたは基本的に选択しなければなりません.特別な要求がない時、オープンソースの世界の中で、最も人気のあるものを選んで、きっと十分な選択です.一番悪いとは限らないが、必ずしも一番いいとは限らない.yum、apt、brewなどのパッケージ管理を使ったことがありますが、実際にある開発言語で見たことはありません.(恥ずかしい)ルビーon Railsの世界以外
私の反応は、他の環境にGemのようなパッケージ管理システムがないのではないでしょうか.耻ずかしいことに、もとは本当にあって、ただ私はこれまですべて知らなかっただけで、Pythonのpip、Objective-Cのcocoapods、最も惊いたのは、Bundle思想のVimのプラグイン管理Vim Bundleのようなものがあって、この名前からこの兄たちがどこから学んだこのような自动化管理思想を知っています.考える価値があるのは、なぜ私はずっとそれらの存在を知らないのか、私が寡聞だからなのかということです.私はほとんどRubyを学ぶと同時にGemを知っています.ほとんどのサードパーティのライブラリがGemでインストールすることを教えてくれますが、他の言語は...これが生態系の違いではありません.BTW:GemはRuby 1から.9から、すでにルビーに内蔵されています.
C++の世界?
ObjCにはcocoapodsがありますが、C++は?C++自体がプラットフォームにまたがる負担のため、各クラスのライブラリのコンパイル方式は様々で、歴史的伝承の原因を加えて、古いものが共存して、原始的なmakefileからautoconfまで、少し新しいCMakeまで、antも使っていて、コンパイラもVS、g+、llvmなどいくつかあります.サードパーティのライブラリが通用するパッケージ管理をするには、私の考えではほとんど不可能です.しかし、Windowsに対するVS、Linux/UnixのG++など、特定の環境に対しては可能である.面白いことに、本当にあって、すべて成熟していないようですが.いわゆるwindows-package-managerを见つけて、Npackdはいくつかのライブラリをダウンロードすることができるようで、不思议なことに、これらの友达は意外にもわざわざUIを开発しました...本当に思惟の违いですね...まさかみんなはUIのものがなくてWindowsの上で谁も役に立たないと思っていますか?Windowsの腐った使えないshellのためですか?VSをサポートするNuGetですが、管理に特化しているようです.Net、悲しい.この過程で、私はまたApache Mavenを発見して、Apacheが発起したJAVA用のパッケージ管理ツールです.
疑う必要はありません.結果は明らかです.C++はまだ少し成熟していません.使えるレベルのパッケージ管理ツールは、VSの中でもg++の上でも、そのためです.Pythonを勉強している間に、似たようなツールを探すことさえ考えていませんでした.実はeasy_Installとpipの成熟度はまだ高いですが、C++からの考え方は、私を制限しています.これは私の今の実感です.開発の過程を思い出して、VSの中で1つの工事を配置するのは本当に1つの苦痛な過程で、そのため少しの経験がなくて本当にできないで、しかも間違いやすくて、フォーマット、カタログなどが乱れてまた後の開発に影響して、この原因のため、私が仕事をしたばかりの時、たとえ1つの私自身が最初から開発した新しいサービス端のプログラムであっても、(私はサービス側から開発を始めました)すべて私たちのメインプログラムが工事を配置して、いくつかの自分のライブラリと第三者のライブラリの依存問題を解決した後、私は再び符号化を始めました.このサービス側のプログラム構成は、全手動で、簡略化するために、私たちが自分で作ったテンプレートからcloneを出て、それから調整します.私がチームを連れて行く時、初期も自分で工事を配置して、比較の後期になってやっと他の人にこの仕事をさせることができて、私はとっくに彼らのコードに対してかなり安心していますが.この過程を思い出すと、この過程がどんなに苦しいかがわかる.C++そのものがどれだけ負担するかにかかわらず、実際の開発過程はRORにとって確かに太原から始まった.以上の体験から言えば、C++は非常に難しい言語だと公認されていますが、サードパーティライブラリとC++を正しく配置する工事は、C++自体を書くよりも難しい...--!そのため、C++ライブラリの开発コミュニティには逆の流れがあるかもしれません.それは、自分のライブラリができるだけ第三者ライブラリに依存しないことを利点としています.简単に言えば、第三者ライブラリに依存しすぎて、配置が面倒で、ライブラリを使う人はいません.これは、良いパッケージ管理があれば、问题ではありません.これはある程度コミュニティの良性の発展を制限して、すべてのライブラリが山積みの基礎ライブラリを持っているのはどういうことですか.この問題はC言語でもっと深刻なようです.STLもないからです.
最後の感嘆
以前の経典のC++プログラマーとPythonプログラマーの間の論争を思い出して、その時また中国人のけんかの知恵に感嘆して、ここを見て、C++の使用者たち(私を含む)は多くの時自分がC++を使って開発する効率が低いことをC++言語自身が効率のためにした犠牲、つまりその自身の複雑さに帰結します.BSが言うように「絶対的に複雑な問題は比較的複雑なツールで解決する必要がある」.実際には、上記の典型的なプロジェクト構成プロセスを含む開発環境の一部がありますが、私たちは意識していません.
リスト#リスト#
ここは私が整理したパッケージ管理ソフトウェアのリストです.
Ruby:GemとBundle Python: pip
Objective-C: cocoapods
Vimプラグイン:Vim Bundle Lua:LuaDistとLuaRocks JAvascript:cpmとjam nodejs: npm
JAVA: Maven
.Net: NuGet
PHP: PEAR, composer, Maven for PHP
Windows: Npackd