Web開発用の新しいプログラミング言語をお探しですか?[閉まっている]


14

プログラミング言語とその意図された目標の良い、具体的な概要を提供する、より偏りのないリソースがあるかどうか疑問に思っています。新しい言語を学びたいのですが、各言語のサイトにアクセスしてもうまくいきません。それぞれが、その弱点や具体的な目標についてはあまり言及せずに、どれだけ素晴らしいかについて語っています。

Rubyは、シンプルで生産性に重点を置いた動的なオープンソースプログラミング言語です。

Pythonは、より迅速に作業し、システムをより効果的に統合できるプログラミング言語です。

Vic Cherubiniは、長年PHP開発者でしたが、私の苦境をうまくまとめています。

私はPHPをよく知っていて、独自のフレームワークを持っていて、すぐに動作して何かを実行することができました。

MVC革命全体でこのようにプログラムしました。私はPHP開発者としてより良い仕事(より良い給料、より良いタイトル)を手に入れましたが、私自身の時間に書いたコードが素晴らしく、仕事で一緒に働いたコードが恐ろしいことを認識している間ずっとずっと。恐ろしいより悪い ひどい。OSコマースレベルが悪い。仕事で一緒に働いたコードが私を悲惨にさせたので、サイドプロジェクトがあると私は正気になりました。

これが、私の側のプロジェクトと新しいプログラミングベンチャーのためにPHPを退職する理由です。私はPHPで過ごしています。あなたがする場合、疲れ。私は言語としてトップにいると思うレベルに達しました。すぐに新しい言語に移行しなければ、プログラミングは完全に完了しますが、それは望ましくありません。

私が調べた言語には、JavaScript(node.js用)、Ruby、Python、およびErlangが含まれます。ScalaやC ++についても考えました。

問題は、どれが私のニーズに最適に対処するために構築されているかを判断することです。

だから、誇大広告をスキップして、プラットフォームの成熟度、コミュニティの規模、その言語の長所と短所についての本当の情報を得るためにどこに行くことができますか?これらを知っているなら、私のウェブ開発を続けるために言語を選ぶのは簡単でしょう。

更新

各スレッドに4MBのオーバーヘッドがあるか、最大同時接続数が999であるか、「X」機能を実行するパッケージがないか、またはサポートがあるため、何らかの言語で4か月先に行きたくないと思います新しい言語ブランチのために段階的に廃止されています。


14
これらのニーズを指定しなければ、どれがニーズを最もよく処理するかを判断するのは困難です。
バルテック

3
それが私のニーズを定義しなかった理由です- 私の個人的なニーズはポイントの横にあります。特定のプログラミング言語に自分のニーズを合わせるためにどこを調べればよいか知りたい。私のニーズが変わる可能性があるので、もう一度戻る必要があるからです。
Xeoncross

プログラムには、実行速度よりも多くのものがあることを指摘する価値があります。開発速度と方法であなたは(原因言語に)アプリケーションを構築する重要な役割をプレイしています。
Xeoncross

4
これは言語についてではなく、言語で利用可能なフレームワークの成熟度と機能の豊富さについてです。

1
Alex Martelliによるこの素晴らしい投稿をご覧になることをお勧めします。
phant0m

回答:


3

これを回答として投稿するつもりはありませんでしたが、Xeoncrossから依頼があったので、ここに行きます。

(補足:誰かが小さなコード例のマークダウンの問題を修正できたら、感謝します。)

Alex Martelliによるcomp.lang.pythonの投稿:RubyのほうがPythonより優れているのは何ですか?上の2003年8月18日、17:50

エリック・マックス・フランシスはこう書いている:

「ブランドン・J・ヴァン・エブリイ」はこう書いています:

PythonよりもRubyの方が優れているのは何ですか?私は何かがあると確信しています。それは何ですか?Pythonの人ではなく、Rubyの人にこれを尋ねる方がはるかに理にかなっていますか?

目的に応じて、またはそうでない場合があります-たとえば、目的がPythonコミュニティの「社会学的研究」を含む場合、そのコミュニティに質問をすることは、他の場所に置くよりも、それに関する情報を明らかにする可能性が高くなります:-)。個人的には、前回のOSCONでDave Thomasの1日のRubyチュートリアルを喜んでフォローしました。シンタックスの違いの薄いベニアの下で、RubyとPythonが驚くほど似ていることに気付きます-ほぼすべての言語セットの中で最小のスパニングツリーを計算していれば、PythonとRubyが合体する最初の2つの葉になると確信しています中間ノード:-)。

確かに、Rubyでは、各ブロックの最後に愚かな「終わり」を入力するのにうんざりします(単にインデントを解除するのではなく)-しかし、: Pythonの開始時に必要 な同等に愚かな入力を避けることができます各ブロック、それはほとんど洗浄です:-)。以下のような他の構文の違い@fooに対して self.foo、またはPythonの対Rubyで例が高い重要性は、ちょうど私には無関係としてについて実際にあります。

他の人は間違いなくそのような問題に基づいてプログラミング言語を選択し、最もホットな議論を生み出していますが、それは私にとってはパーキンソンの法則の1つの例にすぎません(問題に関する議論の量は問題の量に反比例します実際の重要性)。私が重要だと思っている構文の違いの1つは、Pythonに有利なことですが、他の人々は間違いなくその逆を考えるでしょう-「パラメーターをとらない関数をどのように呼び出すか」です。Python(Cなど)で関数を呼び出すには、常に「呼び出し演算子」を適用します-呼び出しているオブジェクトの直後に後かっこ(これらの後かっこ内に、呼び出しで渡した引数を入れます-if引数を渡していない場合、括弧は空です)。これにより、特別な場合、例外、アドホックルールなどを伴わずに、あらゆるコンテキストで、オブジェクトへの参照を意味するものとして、演算子を含まないオブジェクトの単なる言及が残されます。(Pascalのような)Rubyでは、関数WITH引数を呼び出すには、引数(通常は括弧で囲みますが、常にそうではありません)を渡します-ただし、関数が引数を取らない場合は、関数を暗黙的に呼び出すだけです。これは多くの人々(少なくとも間違いなく、以前のプログラミングの経験がPascal、またはVisual Basicなどの同様の「簡易呼び出し」を持つ他の言語であった人々)の期待に応えることができますが、私にとっては、オブジェクトの単なる言及は、オブジェクトへの参照、またはオブジェクトの呼び出しを意味する場合があります。オブジェクトのタイプによって異なります。そして、単に言及するだけではオブジェクトへの参照を取得できない場合、明示的に「これへの参照を与えてください、呼び出してはいけません!」を使用する必要があります。それ以外の場合は必要ない演算子。これは、関数(またはメソッド、または他の呼び出し可能なオブジェクト)の「ファーストクラス」に影響を与え、オブジェクトをスムーズに交換できる可能性に影響を与えます。したがって、私にとって、この特定の構文の違いはRubyに対する深刻なブラックマークです-しかし、私は他の人がそうでないことを理解していますか?構文の下で、基本的なセマンティクスのいくつかの重要な違いに入ります。たとえば、Rubyの文字列は可変オブジェクト(C ++など)です。Pythonでは(JavaやC#のように)可変ではありません。繰り返しますが、主にすでに慣れていることで判断する人は、これがRubyにとってプラスだと思うかもしれません(もちろん、JavaやC#に慣れていない限り:-)。私は、不変の文字列は素晴らしいアイデアだと思います(そして、Javaが独立して、すでにPythonにあったアイデアを再発明したことは驚くことではありません)。 (理想的には、Java独自の「文字列バッファー」よりも使いやすいもの)。そして、Javaを勉強する前に、関数型プログラミング言語を除き、親しみがあるためにこの判断をしません。主に既に慣れ親しんでいることで判断する人は、これがRubyにとってプラスだと思うかもしれません(もちろんJavaやC#に慣れていない限り:-)。私は、不変の文字列は素晴らしいアイデアだと思います(そして、Javaが独立して、すでにPythonにあったアイデアを再発明したことは驚くことではありません)。 (理想的には、Java独自の「文字列バッファー」よりも使いやすいもの)。そして、Javaを勉強する前に、関数型プログラミング言語を除き、親しみがあるためにこの判断をしません。主に既に慣れ親しんでいることで判断する人は、これがRubyにとってプラスだと思うかもしれません(もちろんJavaやC#に慣れていない限り:-)。私は、不変の文字列は素晴らしいアイデアだと思います(そして、Javaが独立して、すでにPythonにあったアイデアを再発明したことは驚くことではありません)。 (理想的には、Java独自の「文字列バッファー」よりも使いやすいもの)。そして、Javaを勉強する前に、関数型プログラミング言語を除き、親しみがあるためにこの判断をしません。不変の文字列は素晴らしいアイデアだと思います(そして、Javaが独立して、すでにPythonにあったそのアイデアを再発明したことは驚くことではありません)。理想的には、Java自身の「文字列バッファ」よりも使いやすいものです。そして、Javaを勉強する前に、関数型プログラミング言語を除き、親しみがあるためにこの判断をしません。不変の文字列は素晴らしいアイデアだと思います(そして、Javaが独立して、すでにPythonにあったそのアイデアを再発明したことは驚くことではありません)。理想的には、Java自身の「文字列バッファ」よりも使いやすいものです。そして、Javaを勉強する前に、関数型プログラミング言語を除き、親しみがあるためにこの判断をしません。すべてのデータは不変であり、私が知っているすべての言語には変更可能な文字列がありましたが、Javaで不変文字列のアイデアを初めて見たとき(Pythonを学ぶ前に十分に学んだ)、すぐに優れた、非常に適していると思いました高度なプログラミング言語の参照セマンティクス(マシンに近い言語やCなどのアプリケーションから遠い言語に最適な値セマンティクスとは対照的に)ファーストクラスの組み込み(およびかなり重要)データ型。

Rubyには基本的なセマンティクスにいくつかの利点があります。たとえば、Pythonの「リストとタプル」の非常に微妙な区別の削除です。しかし、ほとんどのスコア(私がそれを保持しているように、シンプルで大きなプラスと微妙な、巧妙な区別は顕著なマイナス)は、Rubyに対してです(例えば、a..bとa。の表記で、閉じた間隔と半分開いた間隔の両方を持っています) .b [誰がどちらが明らかであると主張したいのですか?-)]、愚かです-もちろん私見です!)。繰り返しになりますが、言語の中心に多くの類似しているが微妙に異なるものがあることを考えると、マイナスではなくプラスになります。もちろん、これらの「逆」を数える方法から数えます:-)。

二つの言語がある考えにこれらの比較に惑わされてはいけない 非常に違う、気に。そうではありません。しかし、「capelli d'angelo」と「spaghettini」を比較するように頼まれた場合、これらの2種類のパスタは誰とでも区別がつかず、あなたが準備するかもしれないどんな料理でも交換可能であることを指摘した後、私は必然的に長さと直径の違いが微妙にどのように変化するか、ある場合にはストランドの端がどのようにテーパー状になり、他の場合にはテーパー状にならないかなどの顕微鏡検査に移ります。アンジェロは、あらゆる種類のスープのパスタとして使用されますが、パスタシュータとしてスパゲッティーニは、このような細長いパスタの形に適したソース(オリーブオイル、ニンニクのミンチ、赤唐辛子のミンチ、細かく砕いたアンチョビなど)たとえば、ニンニクと唐辛子を刻むのではなくスライスした場合、スパゲッティニのより薄いエバネッセンスではなく、スパゲッティのより健全なボディを選択する必要があり、アチョビューを控えて代わりに新鮮な春のバジルを追加することをお勧めします[または、私は異端者です...!-ライトミント...]葉-料理を出す直前の最後の瞬間)。おっと、申し訳ありませんが、それは私が海外に旅行していて、パスタをしばらく食べていないことを示しています。しかし、アナロジーはまだかなり良いです!-)そして、achoviewを控えて、代わりにいくつかの新鮮な春のバジルを追加することをお勧めします[または-私は異端者です...!-ライトミント...]葉-料理を出す直前の最後の瞬間)。おっと、申し訳ありませんが、それは私が海外に旅行していて、パスタをしばらく食べていないことを示しています。しかし、アナロジーはまだかなり良いです!-)そして、achoviewを控えて、代わりにいくつかの新鮮な春のバジルを追加することをお勧めします[または-私は異端者です...!-ライトミント...]葉-料理を出す直前の最後の瞬間)。おっと、申し訳ありませんが、それは私が海外に旅行していて、パスタをしばらく食べていないことを示しています。しかし、アナロジーはまだかなり良いです!-)

そこで、PythonとRubyに戻って、2つの大きな問題に取り組みます(適切な言語の観点から、ライブラリや、ツールや環境などのその他の重要な付属品、各言語の埋め込み/拡張方法など)とりあえず、それらはいずれにせよ各言語のすべての実装に適用されるわけではありません。例えば、Jython対Classic PythonはPython言語の2つの実装です!):

  1. RubyのイテレーターとコードブロックとPythonのイテレーターとジェネレーター。

  2. Pythonの広大しかしVS -すべて内蔵のものを含む任意の既存のクラスを、「再度開く」、および実行時にその動作を変更する機能など、RubyのTOTAL、奔放な「ダイナミックさ」、     有界 既存の動作を変更することはありませんダイナミシティ、組み込みクラスとそのインスタンス。

個人的に、私は1をウォッシュと見なします(違いは非常に深いので、どちらか一方に近づき敬意を払う人々を簡単に見ることができますが、私の個人的なスケールではプラスとマイナスがほぼ均等に増えています)[2]重要な問題-Rubyを「いじくり回し」にはるかに適したものにする問題ですが、Pythonは大規模な実稼働アプリケーションでの使用にも同等に適しています。面白いことに、両方の言語は他のほとんどの言語よりもはるかに動的であるため、POVとの重要な違いは最終的にはこれに依存するはずです-この点でRubyは11になります(参照もちろん、ここは「Spinal Tap」です)。Rubyでは、私はそれができます!つまり、組み込みの文字列クラスを動的に変更して、

a = "Hello World" 
b = "hello world" 
a == bの場合 
    「等しい!\ n」を印刷 
そうしないと 
    「異なる!\ n」を印刷 
終わり
 

「等しい」を印刷します。Pythonでは、それを行う方法はありません。メタプログラミング、実験的フレームワークの実装などの目的のために、Rubyのこの驚くべき動的能力は非常に優れています 魅力的。しかし、多くの人々によって開発され、さまざまなソースからのすべての種類のライブラリを含むさらに多くによって維持される大規模なアプリケーションについて話している場合、クライアントサイトでの生産に行く必要があります...まあ、私はしたくないとても動的な言語です。ありがとうございました。私は、文字列が異なることに依存している他の無関係なライブラリを無意識に壊すライブラリのアイデアを嫌います-それは一種の深くて深く隠された「チャンネル」であり、LOOKが分離し、SHOULD BEが分離し、死を綴る大規模プログラミング。モジュールを他の「ひそかに」の動作に影響させることにより、

そのような大規模なアプリケーションにRubyを使用しなければならなかった場合、コーディングスタイルの制限、多くのテスト(何かが変更されるたびに再実行されます-まったく関係のないものでも...)などに依存しようとします。この言語機能の使用を禁止します。しかし、私の意見では、最初に機能を持たないことはさらに良いです-特定の数のビルトインを「固定」できる場合、Python自体がアプリケーションプログラミングのためのさらに良い言語であるように、私はそれを知っていました、たとえば、 len("ciao")4です(誰かlen__builtins__ モジュール内の名前のバインディングを変更したかどうかについて潜在的に心配する必要はありません...)。最終的には、Pythonがその組み込み関数を「特定」することを願っています。

ただし、ビルトインの再バインドは非推奨であり、Pythonのまれなプラクティスであるため、問題は軽微です。Rubyでは、 他の言語の非常に強力なマクロ機能(たとえば、ディラン)が私自身の意見で同様のリスクを提示するのと同じように、私はメジャーとして印象づけられます(Pythonがそのような強力なマクロシステムを取得しないことを願っています「人々に言語自体に埋め込まれた独自のドメイン固有の小さな言語を定義させる」という魅力は重要です-私見では、Pythonのアプリケーションプログラミングに対するすばらしい有用性を損ないます。すべてのプログラマーの心に潜んでいます...)。

アレックス


それがRubyとPython全体の素晴らしい、比較的偏りのない概要であるため、私はこれを答えとして授与しました。言語が動作し、どのように説明する作業をしないでください
-Xeoncross

27

幸運を

記載されている例の説明はどれも客観的またはテスト可能ではありません。それらはすべて誇大広告と意見です。

...シンプルさと生産性...より迅速に...より効果的に。

それを試してみてください

あなたがしそうな種類の小さなサンプルプロジェクトを取り、興味のあるすべての言語で試してください。その後、客観的なレビューを投稿してください。


2
悪い考えではありませんが、現実の世界では機能しません。各言語を完全に理解する時間を費やすことなく-私は、完全な設計パターンの問題と各システムが提供できる利点を予測することはできませんでした。言語自体の高度な理解を実現するには、各言語で何ヶ月もかかると確信しています。タイヤの専門家から、各ホイールの設計を数か月かけて、なぜそのように作ったのかを理解するよりも、聞きたいと思います。それでも、私はいくつかの良い候補ができた後、私は確かにこれを行います。
Xeoncross

1
@Xeoncross:各言語を試してみると、経験が増え、他の言語でそれを活用できるようになります。言語に飛び込むための4か月は決して失われません。そして、その言語が本当にくだらないものであるなら、見つけるのに2週間もかかりません。
tdammers

それは本当です、何かを構築するのに数週間しかかからないはずです、そして、言語は一般に他の言語に従うので、私は経験から利益を得るでしょう。
Xeoncross

3
はい、おそらくこれらすべての言語を試して適切なものを見つける必要があります。しかし、問題は、新しい言語を使用するとき、最初に想定した方法で使用しないことです。最終的には、異なる構文でのみ使用する方法を既に知っている言語で行っていたのと同じことをすることになります。各言語のより細かい点と利点が何であるかを理解するには、かなりの時間がかかります。
radix07

3
一般的な目的で現代の言語との間に大きな違いがあった場合、私は驚くでしょう。そこで、大声で言った。そしてイタリック体で。炎を始めましょう!
スティーブンA.ロウ

8

問題の一部は、1つ以上の言語について有意義にコメントするのに十分な知識がある人はだれでも偏見を持つことだと思います。ほぼ40年間のプログラミングで、私は数えきれないほど多くの言語で働いてきました。これらの言語のかなりの数について意見を述べることができます(その一部は時代遅れです)。

私は仕事に適切な言語を使用するアプローチを取ります。あなたは特にウェブ開発について尋ねますが、それはまだかなり広いカテゴリーです-写真に興味があるというようなものです。マイクロ?アストロ?PHPは感情的に満足のいく言語ではないことに同意しますが、多くのお客様にとっては、多くの要因に基づいて適切な言語であり、特に、離れた後にサイトを修正するプログラマーを見つける長期的な能力です。および/またはバスにヒットします。

ですから、何か違うことに役立つプロジェクトに興味を持っているタイプの顧客を見て、自分自身を彼らに興味を持てるようにするべきでしょう。


ええと、私はPHPがとても上手なので、まだ良い生活を送ることができるので、PHPで働き続けます。私は主に自分プロジェクトの新しい言語について考えてました。人生にフレーバーを追加するのに役立つ何か。ちょうどあらゆる程度で私の仕事はまた、多くの言語での経験を持つ誰かが持っているあなたが考えることができるWeb開発、NLP、テキストの構文解析、CMS、APIの、ストレージ、などであるずっと少ない人よりもバイアスの唯一の設計プロセスと。
Xeoncross

あ。次に、「最高の言語」タイプの質問に対する標準的な回答、Pythonを提供します。「重要な空白」(これは可能です)を無視すると、私にとって完璧な言語に近くなります。さらに、Python APIを使用した非常に多くの非常に高品質のライブラリがあります。例えば、NLTK、Natural Language Toolkit(nltk.org)。
ピーターローウェル

ああ、しかしPythonの方が優れているのは何ですか?ほとんどの言語すべての共有と同じツールキット-それは言語設計だことなどスレッド、同時実行、VMの要件、コンパイル/解釈し、持続性、のような発表のもの
Xeoncross

Pythonはプログラミングするのがとても楽しいです。それが私にとって「より良い」ことです。単純なため、コーディングするだけで大​​きなIDEを鳴らす必要はありません。しかし、オブジェクト、関数型プログラミング機能、多くの既存のライブラリ/フレームワーク/ツール、多くのオープン/無料のドキュメントを備えた活発で熱狂的なコミュニティなど、多くの興味深い機能も備えています。
ジョンゲインズジュニア

2
本当です。最も簡単な説明は、Pythonが私の脳と同じように機能し、それが単に生産性を高めるということです。「今、Pythonでこれをどうやってやるの?」と思うことはほとんどありません。GIL(Global Interpreter Lock)は少し問題ですが、multitaskよりもマルチプロセスの状況(特にマルチステージNL処理パイプライン)を処理する頻度が高いため、それほど大きな影響はありません。私も新しい外部ライブラリにアクセスするためのオプションのインターフェースの様々なように:などのctypes、ブースト、
ピーター・ローウェル

7

Python

それらのすべての最も普遍的かつ一般的な目的だけでなく、Webプログラミングの場合には、製品の幅広い選択肢を提供しています。WSGIインターフェースを標準化することにより、フレームワークとサーバー間の優れた相互運用性が保証されます。注目すべきPython Web製品の一部:

  • Django —高度なORM、テンプレートシステム、フォーム処理などを備えた本格的で成熟した高レベルフレームワーク
  • Twisted —イベント駆動型(非同期)ネットワークプログラミングのフレームワーク。チャット、ソケットサーバー、Webサービスなどに使用できます。
  • Tornado —イベント駆動型フレームワークでもありますが、これは非同期Webサービス用に設計されています。

ルビー

Rubyも非常に普遍的な言語です。しかし、最も注目すべき製品はRuby on Railsです。その設計は多くの人にインスピレーションを与えています(上記のDjangoを含む)。

JavaScript

現在、JSの唯一のサーバー側の選択肢はnode.jsです。それはトルネードとツイストに非常に似ています(それによってインスピレーションを受けました)。ただし、その上に構築されたDjangoまたはRoRに似た本格的なフレームワークはまだありません。

スカラ

関数型言語であるため、超並列コンピューティングに最適です。汎用Webプログラミングに関する限り、Liftは、FourSquareなどで使用されるRoRに触発されたWebフレームワークです。


非ブロッキング応答、メモリ使用量、同時実行性、およびその他の要因のようなものが、Webアプリケーションを強化する新しい言語の市場で巨大であることを指摘する価値があります。
Xeoncross

Djangoの場合は+1。私がそれを学んだとき、それは私の心を吹き飛ばしました...それ、または私はそれとPythonを同時に学んだので、私は呆然としたst迷にありました。いずれにせよ、素晴らしい技術であり、これまでにない「自由な時間」を再考したいと思います。
zourtney

1
「...まだ本格的なフレームワークが欠けている」Express for Nodeをご覧ください-expressjs.com
T. Stone

@T:ええ、私はExpressを見ました。DjangoとRoRの長所の1つはORMです。Expressにはないようです。
バルテック

3

私の最新のWebプロジェクトでは、PHPでWebプロジェクトに使用したことがあるため(クイックスタート)PHPを使い始めましたが、言語に多くの問題(UTF-8の不適切なサポートや動的型付けなど)がありました。Javaのバックグラウンドもあり、静的型付けと優れたリファクタリングツールを本当に楽しんでいます。Javaは、PHPに比べてパフォーマンスも優れています。しかし、関数型プログラミングの表現力も気に入っています。

Scala and Playフレームワーク

上記の経験で、私は本当にScalaプログラミング言語を楽しんでいます。静的に型付けされており、オブジェクト指向プログラミングと関数型プログラミングの両方をサポートし、Web開発に使用される他の言語と比べて優れたパフォーマンスを発揮します。しかし、Javaとサーブレット用のWebフレームワークが気に入らなかったため、ScalaとJavaの両方をサポートし、開発サイクルが非常に速いPlayフレームワークを見つけました。ファイルを保存してWebページを更新します。先月、Scala&Play Frameworkに非常に満足しています。しかし、Play FrameworkでのScalaのサポートはまだそれほど成熟しておらず、ツールのサポートもまだ成熟していません。

つまり、プログラミング言語としてScalaを、WebフレームワークとしてPlay Frameworkをお勧めします。


プレイはクールに見えますが、実際に(実際に)テストドライブする機会はありませんでした。同様のphpのバックグラウンドから来た私は、Liftを把握するのが非常に簡単であることがわかりました。また、Playよりも少し成熟しているように見えますが、私はScalaに慣れすぎて決定的ではありません。
ヤニス

3

実際、おそらく次の3つのタイプのリソースを見ています。

  • 言語の基本と、なぜそれを使用したいのかを説明するもの、
  • 複数の言語を比較するもの。
  • 言語のある側面を批判するもの。

これらのリソースは両方とも偏っています。

  • 言語について何かを説明するとき、ほとんどの場合、読者にその言語を使用するように説得します。だから、あなたはめったにその言語が悪いとは言わないでしょう。
  • 複数の言語を比較する場合、常に1つの言語を個人的に好みます。
  • 何かを批判するとき、まあ、中立になることはほとんど不可能です。

中立的な比較を見つける機会があるかもしれませんが、比較することは非常に困難です。個人的には、PHPを常に批判せずに、実際の言語とPHPの比較を書くことはできません。そして、中立になれないのは私だけではないと確信しています。


異なる言語の概要を知りたい場合は、自分それらを学習し、たくさん読む必要があります。学習するということは、言語の基本を知っているが、自分の意見を持つことができるということです。Rubyのマニュアルを読んだからではなく、この言語で何が良いのか、何が悪いのかを説明できます。

これは、時間(月、または年)を費やす必要があることを意味します。または、たくさん読むことができます。しかし、矛盾したことを読んでみてください。PHPが嫌いで、特にRuby、C#、Javaなどの実際の言語と比較してPHPが最悪の言語の1つであると書いている人は、PHPが素晴らしいと言う人を見つけてみてください。 C#、Javaよりもはるかに高速、そして...(Rubyよりも(私は本当に知りません)。

一つのことを覚えておいてください:すでに言語をよく知っているなら、最初に別の言語を学ぶときに非常に批判的です。Windowsが嫌いなLinuxユーザーやLinuxが嫌いなWindowsユーザーのようです。実際、どちらのOSも優れていません。LinuxユーザーがWindowsの使い方を知らないだけで、その逆も同様です。どちらの方が良いかを正しく判断できるようになるには、両方で十分な経験を積んだ後になってからです。


忘れられがちな最後のこと:言語の「周囲」を評価できることも非常に重要です。

  • フレームワーク(または最も使用されているフレームワーク)はどれくらい良いですか?
  • ホスティングサービスを見つけるのは簡単ですか?IDEに感謝しますか?
  • よく書かれたサードパーティのライブラリはたくさんありますか?
  • コミュニティは高度なプロの開発者で構成されていますか、それともプログラミング全般や言語自体について何も知らない初心者がほとんどですか?
  • ドキュメントは十分に冗長で、検索と理解が容易ですか?
  • 言語とフレームワークは頻繁に更新されていますか?

全くもって同じ意見です。それは私が答えを探しているこれらの質問です。あなたはたくさんの読書に言及します-それが私がやろうとしていることです-私は調べたい言語について読むために多くのリソースが必要です。偏りのないレビューを行うことはできませんが、一部はよりバランスのとれたものであり、それが私が望んだすべてです。
Xeoncross

2

さて、あなたの基準の1つは「一緒に仕事をするのが楽しい」と思われるので、偏った情報を見つけたいと思います。何かの作者が選択した言語に情熱を持っている場合、偏った評価を与える可能性がかなりあります。

たぶん、他の方向からアプローチする必要があります。あなたは趣味ではなくキャリアから転職することについて話しているように聞こえるので、おそらくいくつかの求人広告を調査し、いくつかの興味深い技術/言語を見つけ、それらを調べる必要があります。

特定の目標を持つ言語に関しては、多くの言語にはそれらがありません。あなたがリストした言語のほとんどはかなり一般的な目的です。たとえば、Ruby言語は、多くのタスクに適した非常に汎用的な言語です。Railsのようなフレームワークを追加すると、かなり具体的な目標があります。


1

これはまさにあなたが求めていたものではありませんが、ウェブ開発の専門的わだちから抜け出すために何かを探していて、その経験と連絡先を活用しながら、AndroidアプリとiPhoneアプリを書くことになります。クライアントのWebサイトを補完するアプリを販売できると、モバイルデバイスを介してますますアクセスされるインターネットの開発を目立たせることができます。


それは本当に悪い考えではありません。また、イラストレーターやPhotoshopで自分のデザインに取り組む時間を増やすことも考えていました。それでも、私はそこにウェブアプリケーションのオプションについてもっと知りたいです。
Xeoncross

0

あなたは本当にPHPの限界に達しましたか、それともあなたが知っている PHPの限界に達しましたか?

Drupalを調べましたか?これはPHPベースのCMSおよびプログラミングフレームワークであり、優れたコーディング標準と実践を強く推奨します。(以前の仕事でOSCommerceで作業しなければならなかったので、苦痛を感じます。)PHPベースですが、純粋なPHPで何かを行う「正しい」方法がDrupalでそれを行う正しい方法ではないことがよくあります。そして、あなたはそれを本当に習得するために登る良い学習曲線を持っているつもりです。ただし、言語としてのPHPの機能およびWeb開発全体に対する見方が変わる可能性があります。


Drupal(4&5)を最後に見たとき、それはかなり悪かった。おそらくそれらの新しいバージョンは現在、適切な標準を使用しています。それでも、それと同じくらい遅いので、私はむしろそこにある素晴らしいフレームワークに固執します。
Xeoncross
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.