問題タブ [interpreted-language]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
performance - 速度の比較 - インタープリター言語での手続き型とオブジェクト指向
PHP や JavaScript などのインタープリター型プログラミング言語では、手続き型アプローチよりもオブジェクト指向アプローチを採用すると、どのような影響がありますか?
特に私が探しているのは、Web アプリケーションを作成し、速度だけでなく保守性も最適化するために、手続き型アプローチとオブジェクト指向アプローチのどちらかを選択する際に考慮すべき事項のチェックリストです。これをさらに調査する記事を知っている場合は、引用された研究とテストケースも役立ちます。
結論: インタプリタ言語で OO と手続き型を使用した場合、実際にパフォーマンスへの影響が (あるとすれば) どのくらい大きいのでしょうか?
performance - 解釈された言語 - インタプリタの背後でコンパイルされた言語を活用
言語設計者 (または単に知識のある人) がいる場合は、インタープリター言語用の標準ライブラリを作成する方法論に興味があります。具体的には、最善のアプローチと思われるものは何ですか? インタープリター言語で標準関数/メソッドを定義するか、インタープリターが記述されているコンパイル済み言語でそれらの呼び出しの処理を実行しますか?
これについて考えさせられたのは、Python の stripslashes() のような関数に関する SO の質問でした。私が最初に考えたのは、「独自の関数を定義して、必要なときに呼び出すだけでよいのでは」ということでした。拡張機能を作成し、コンパイルされた言語をインタープリターの背後で活用しますか?
python - GPL プログラム専用のプラグイン: インタープリター言語はどうですか?
GPL ライセンスのアプリケーションを Python で開発していますが、GPL が私のプログラムでプロプライエタリ プラグインの使用を許可しているかどうかを知る必要があります。この問題についてFSF は次のように述べています。
GPL の下でリリースされたプログラムがプラグインを使用している場合、プラグインのライセンス要件は何ですか?
プログラムがプラグインを呼び出す方法によって異なります。プログラムが fork と exec を使用してプラグインを呼び出す場合、プラグインは別個のプログラムであるため、メイン プログラムのライセンスではそれらの要件はありません。
プログラムがプラグインを動的にリンクし、それらが相互に関数呼び出しを行い、データ構造を共有する場合、それらは単一のプログラムを形成すると考えられます。これは、メイン プログラムとプラグインの両方の拡張として扱われる必要があります。つまり、プラグインは GPL または GPL と互換性のあるフリー ソフトウェア ライセンスの下でリリースする必要があり、それらのプラグインを配布するときは GPL の条項に従う必要があります。
プログラムがプラグインを動的にリンクしているが、それらの間の通信がプラグインの「メイン」関数をいくつかのオプションで呼び出し、それが戻るのを待つことに限定されている場合、それは境界的なケースです。
fork/exec と動的リンクの違いは、人為的であることに加えて、インタープリター型言語には引き継がれません。import
またはを介してロードされる Python/Perl/Ruby プラグインはexecfile
どうですか?
(編集: fork/exec と動的リンクの違いの理由は理解できますが、GPL に準拠したいが「精神」に反する人のように思えます。ほとんど何でもするためのプロセス間通信)。
最善の解決策は、ライセンスに例外を追加して、独自のプラグインの使用を明示的に許可することですが、 GPL であるQt / PyQtを使用しているため、そうすることができません。
compiled - モジュール性とプラットフォームの独立性の両方に対する最善のアプローチは何ですか?
この質問が、最初に思われるほど広範に出てこないことを願っています。<sarcasm>
膨大な</sarcasm>
空き時間にソフトウェア アプリケーションを設計しています。クロスプラットフォームとモジュラーの両方を実現したいと考えています。現時点では、まだ計画段階にあるため、実質的に任意の言語とツールセットを選択できます。
両方の目標 (モジュール性、プラットフォームにとらわれない) を達成する方法が非常に多いように見えるため、これは物事を容易にするのではなく、困難にします。
私の基本的な前提は、セキュリティ、データ ストレージ、オペレーティング システムとの対話、および構成はすべて「コンテナー」アプリケーションによって処理される必要があるということですが、その他の機能のほとんどはプラグイン モジュールを通じて提供されます。大まかに説明する必要がある場合 (私のアイデアを完全に放棄することなく)、それは多くの異なるジョブを実行できる単一のアプリケーションであり、すべてが同じ目標に専念しています (実行すべきさまざまなことがたくさんありますが、すべてのデータは相互に作用し、可用性が高くなければなりません)。
これは新しいアイデアではなく、特に風変わりなものでもありません。それでも、どのようにそれを行うかということではなく (多くの方法を考えることができます)、どの方法が最適かということで苦労していることに気づきます。
たとえば、私が説明していることを Eclipse が実際に体現していることはわかっていますが、一般的に Java アプリケーション (Eclipse も例外ではありません) は、私が必要とするものに対して大きすぎて遅すぎると感じています。同様に、Python と Ruby で記述されたデスクトップ アプリ (これらは優れた言語です!)
さまざまなプラットフォーム用にコード ベースをネイティブ実行可能ファイルとして再コンパイルすることは気にしません。しかし、C と C++ にはそれぞれ独自の問題があります。
C# 開発者として、私はマネージ コードを好みます。しかし、私はまだ、Mono をまったく気に入っていません (確信できました)。
共有するアイデア/経験/特定のお気に入りのフレームワークを持っている人はいますか?
build-process - PHP スクリプトまたはインタープリター言語で「ビルド」できますか?
間違っている場合は訂正してください。ただし、「ビルド」は「コンパイル」であり、すべての言語がコンパイルされるわけではありません。継続的インテグレーションには、コンポーネントを構築して、単体テストを超えて機能し続けるかどうかを確認することが含まれますが、単純化しすぎている可能性があります。しかし、プロジェクトにコンパイルできない言語が含まれている場合、どのようにナイトリー ビルドを実行したり、継続的インテグレーション手法を使用したりするのでしょうか?
interpreted-language - 多くの Web 言語がコンパイルされずに解釈されるのはなぜですか?
C などの言語が最終的に Web 開発に使用されなかったのはなぜですか? 確かに、コンパイルによる速度の向上は、負荷の高いサイトに役立つでしょうか?
interpreted-language - 通訳言語で書かれたコードを販売するにはどうすればよいですか?
通訳で書いていると、ソフトウェアを買う人は誰でも簡単に編集・変更・転売できるので、販売は難しいと思います。
これをどのように回避しますか?私が作成したものを変更/読み取り/編集/販売するのは簡単すぎるように思われるため、人々に販売するのを嫌がるPHPアプリがいくつかあります。
c# - C# 解釈言語
C# でインタープリター言語を作成しようとしていますが、どこから始めればよいですか? 楽しい文字列解析を使用してそれを行う方法は知っていますが、正しい方法は何ですか?
vm-implementation - シンプルな解釈言語の設計と実装
シンプルな仮想マシンとインタープリター言語を実装するためのリソースが必要です。実用的なものが最も役に立ちます。Virtual Machine Implementation の本を読みましたが、かなり古く、現在目にする VM を表していないことがわかりました。また、誰かがかなり単純化された言語を知っていれば、それも素晴らしいでしょう.
compiler-construction - コンパイルされた言語は強力な型付けを持っているのに、解釈された言語はほとんどダックタイプ化されているのはなぜですか?
私はそれを知りません、それには技術的な理由がありますか?型付けが弱い言語のコンパイラを実装するのは難しいですか? それは何ですか?