Scalaライブラリの組み込みは遅いですか？

StackOverflowでこの質問を見つけ、回答を受け入れました。これは、標準のScalaライブラリの遅いJSONパーサーに関連しています。

現状のコンセンサスは、組み込みのJSONライブラリーが遅いことであり、DMCの言葉では「それはそのようなものであり、それが現状です」ということです。

たぶん、私はここで単純に働いているだけかもしれませんが、言語を成長させるための悪いアプローチのように思えます。べきではありませんビルトインライブラリは、完璧なもの？それらはすべての人にとってすべてである必要はありません。私はScalaが拡張可能であることを受け入れます。しかし、組み込みライブラリがあれば、確かにそれは確実で、言語が提供するのと同じくらい高速でなければなりません。

私はスターコマンドに苦情を申し立てています;-)

私のような普通の人がどこでどのようにしてこれについて私の意見を表明できるか、つまりScala言語を形作るためにどこに行くことができるかを誰かが知っていますか？

更新：

この質問は、否定的な意味ではありませんでした。Scala、それはクリエーターであり、Scalaコミュニティーは非常に優れています。組み込みのJSONパーサーのようなものが最適とはほど遠いことに驚いた（提供されたリンクの質問によると）

組み込みライブラリは完璧でなければなりません。

理想的な世界では、はい。しかし、完璧は善の敵です。本当の創造物は常にある種のトレードオフです。たとえば、パフォーマンスと柔軟性の間のトレードオフになる可能性があります。または、パフォーマンスとライブラリを作成するための労力。それが「今のところ十分」であり、取り組むべきより重大な問題がある場合は、それらのより重大な問題に集中することをお勧めします。速度のみを最適化することは、通常、誤った経済です。

言語/ライブラリ/ APIトレードオフの重要なポイントの1つは、後でインターフェイスを変更するのは難しいことです。これは、通常、インターフェイスの上に構築された古いコードを破壊するためです。しかし、実装（つまり速度）は後で改善することができるので、インターフェースを正しくすることに努力を集中するのに役立つ場合は、最初はそれを省くことができます。重要度は次のとおりです。

1. インターフェース。構文。ファイル形式。リリース後の変更は困難です。最初は正しくなるように努力する必要があります。
2. 安定性、正確性。もちろん物事は想定どおりに機能するはずです。しかし、そうでない場合は修正できます。
3. パフォーマンス、スピード。時々重要ですが、ほとんどの場合そうではありません。間違いなく後で改善することができます。

私のような普通の人がどこでどのようにしてこれについて私の意見を表明できるか、つまりScala言語を形作るためにどこに行くことができるかを誰かが知っていますか？

ここのキーワードは「ボトルネック」だと思います。あなたはJSONライブラリの性能は、実際のユースケースがある場合は、ボトルネックを、あなたはScalaのメーリングリストに問題をもたらす可能性があります。あなたがそれを自分で改善できるなら、いいですが、誰か他の人がそれを改善することになっているなら、少なくともそれに対する真の必要性がなければなりません。

標準ライブラリに付属するJSONパーサーは、パーサーコンビネーターに基づいています。パーサーコンビネーターを使用すると、理解と変更が簡単なパーサーを非常に迅速に作成できます。JSONの文法全体は、ここで 134行目から140行目で定義されています。Lift JSONを見てみると、文法を表す行のグループを選択することさえできません。

ただし、パーサーのコンビネーター（少なくともScalaライブラリー（Haskellにもあります））は低速です。Scala 2.8で導入されたpackratパーサーの方がパフォーマンスが良いかもしれませんが、そのJSONパーサーははるかに古く、事実を正直に言えば、それは主に例として作成されました。

さて、Scalaは完全なライブラリのみを利用可能にする必要がありますか？まあ、利用可能なリソースが限られていることを考えると、代替手段はJSONライブラリではありません。今日、それは大丈夫です-結局のところ、たくさんの選択肢があります。しかし、JSONがライブラリに追加された時点で、JSONが広く採用されてパフォーマンスが重要になる前は、JSONはすばらしいものでした。

Scalaの作成者が最高のパフォーマンスに完全に最適化されるまでコードをリリースしない場合、Scalaはおそらく2.9ではなくバージョン0.1になります。

事実上、すべての新しい言語には最初はパフォーマンスの問題があります。Java 1を思い出してください（Java 1の経験がある場合）。これは、最初は作成者が実装の詳細よりも言語機能とインターフェースに重点を置いているためであり、この方法は合理的です。言語とそのクラスライブラリが将来どのように使用されるか（そして使用されるかどうか）を予測することはできません（文字列ライブラリなどのような些細なケースは別として）。したがって、実際に開発者の生活に目に見える変化をもたらさないコードの最適化に時間を費やすよりも、差し迫ったニーズがある場合にのみ最適化する方が良いです。

さらに、ScalaはJVMの上に構築されているという点で特別であり、既存のすべてのJavaライブラリはそこから直接利用できます。言語の純粋さよりもパフォーマンスを優先する場合は、いつでも適切なJavaクラス/ライブラリを選択して使用できます。

そのオープンソースソフトウェア。したがって、プロプライエタリなソフトウェアと比較して、作者はどんな失敗についてもより率直になる傾向があります。また、ポライトリクエスト以外に開発に影響を与える方法や、自分で改良点​​を記述し、一般的なリリースに含めるために改良されたコードを丁重に提出するというふりはありません。

Scalaの性質とそれが占めるニッチ（大規模な並列処理）を考えると、開発者はおそらく、単一のリクエストで数千回実行される可能性のあるコードの内部パフォーマンスを、実行されるJSONパーサーよりも優先するのが適切です。リクエストごとに1回。

JVMの豊富な高速オープンソースJSONパーサーを考えると、これはここで発明されていない完璧な例のように見えます。既存の実装よりも速度が遅い組み込み機能は、言語の作成者が少なくともこの機能に関する限り、実際の使用法にあまり関心がないことを示しています。

修正してください。これが私のオープンソースの仕組みです。かゆみがあり、引っ掻きます。ScalaでJava JSONパーサーを実行できることをご存知ですか？