タグ付けされた質問 「scala」

Scalaは、主にJava仮想マシンをターゲットとする汎用プログラミング言語です。一般的なプログラミングパターンを簡潔、エレガント、タイプセーフな方法で表現するように設計されており、命令型プログラミングと関数型プログラミングのスタイルを融合しています。

2
Javaの経験がなくてもScalaでAndroidアプリを構築するための理想的な学習パスは何ですか
残念ながら、現時点では理想的なソリューションとなる「ScalaでAndroid開発を学ぶ」というテーマの書籍はありません。ここでは、トピックごとに1冊以上、少なくとも3冊の本を取り上げる必要があると思います。ただし、それらをどの順序で読むか、同時に読むか、Javaブックのどの部分を安全にスキップできるかなどはわかりません。 Scalaを使用してAndroidアプリの構築を始めるための最良の方法は何ですか?
13 java  android  scala 

1
GrailsアプリケーションをScala Play / Sprayに移行する
PostgreSQL上でGORM / HibernateとHTMLを提供するGSPを使用した中規模のGrails Webアプリケーションと、いくつかのREST APIがあります。Scalaで標準化を進めており、このアプリケーションをPlayまたはSprayに移行し、Slickで既存のデータベースにアクセスしたいと考えています。 Nimbleは現在、認証/承認およびユーザー/ロール/などに使用されています。管理。 ビッグバン移行を回避し、段階的に移行を行うために私たちが取れるアプローチは何ですか? これらは両方ともJVM言語ですが、それらを独立したポートで実行する独立したWebアプリとして扱うことを避ける方法はありますか?

3
「リフト表現」とは何ですか?
ここでこの用語に出くわしました: http://www.codemesh.io/codemesh2014/viktor-klang 「リフトされた表現であるFlow APIと、リフトされた表現を実行表現に変換するプラグ可能な方法であるFlow Materializationのデモを行います。」 グーグルはあまり役に立ちませんでした。

1
ClojureとScalaのパターンマッチング
これら2つの言語のパターンマッチングの主な違いは何ですか?構文ではなく、機能、実装の詳細、ユースケースの範囲、必要性について言及しています。 Scalaアプリケーション(Lift and Playなど)は、言語のパターンマッチングの能力について誇らしげに語っています。一方、Clojureにはライブラリcore.matchがあり、破壊機能が組み込まれていますが、これも強力なようです。 *注:私がこの質問をすることに触発された理由は、実験としてプログラマがScalaとClojureの両方を使用してlispインタープリターを作成したブログ投稿でした。彼は、Clojureの試合が一定の長さの後に壊れたと言ったが、その理由を説明できなかったが、私は本当に知りたいと思っている。この投稿はここで見つけることができます:http : //www.janvsmachine.net/2013/09/writing-simple-lisp-interpreter-in-clojure.html

5
Scalaが他の言語よりもスケーラブルなのはなぜですか?
ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け付けていません。 Scalaは、その名前に含まれている機能であるスケーラブルな言語として請求されます。 Scalaという名前は「スケーラブル」と「言語」のポートマントーであり、ユーザーの要求に応じて成長するように設計されていることを意味します。 Scalaのコンテキストで「スケーラブル」とはどういう意味ですか?何がScalaをJavaよりもスケーラブルにするのですか?

2
Scalaインフィックス表記法
インフィックス表記法を使用してメソッドを呼び出すことは可能ですか? たとえば、Haskellでは、次の関数を作成できます。 x `isAFactorOf` y = x % y == 0 そして次のように使用します: if 2 `isAFactorOf` 10 ... 場合によっては非常に読みやすいコードが可能になります。Scalaでこれに似たものはありますか?「Scala infix notation」を検索しましたが、その用語はScalaでは異なるものを意味するようです。
12 scala 


2
Javaの新しい開発は、ScalaやClojureなどの言語との相互運用性にどのように影響しますか?
私の知る限り、ScalaとClojureはどちらも新しい言語として設計されています。 JVMに依存する ScalaおよびClojureコード内でJavaクラスを使用できるという意味で、Javaコードと簡単に統合できます。 Java 8(以降のバージョンのJavaではさらに強力になる可能性があります)から、Java言語のセマンティクスに変更が加えられます。 これらの変更がJavaとScala / Clojureの間の相互運用性にどのように影響し、どのような結果になるかを尋ねたかったのです。たとえば、Java 8のラムダはオブジェクトではないため(ここを参照)、ScalaとClojureはオブジェクトではないJava値を処理する必要がある場合があります。これは問題になりますか? 次のシナリオを考えることができます。 ScalaまたはClojure言語は、新しいJavaセマンティクス(新しい非オブジェクト値を処理する)に適応するように拡張され、Javaとの相互運用性をサポートします。 ScalaまたはClojure言語は拡張されません。これは、関数値などの新しいJava機能を既存の概念にマッピングできる場合にのみ可能です。たとえば、Scalaでは関数もオブジェクトであるため、Java関数はScalaから見えるようになったときに再び何らかのオブジェクトにラップされると思います。 ScalaまたはClojure言語は、最新のJavaの開発に従うことなく、引き続きJava 6または7までの相互運用性をサポートします。これには、Javaのより保守的で安定したブランチに基づいてこれらの言語を使用できるように、Javaの古いバージョンが(少なくともOpenJDKまたは別のプロジェクトで)サポートされている必要があります。 要約:Javaの将来の開発がScalaやClojureなどの言語に影響を与え、Javaとの相互運用性を維持できると期待できますか?このトピックに関する進行中の議論は既にありますか? 注意 Scala、Clojure、およびその他のJVMベースの言語では、実装をJVMの新しいバージョンに更新するのに大きな問題はないことを想像できます(新しいJVM機能により、この実装がさらに簡単になります)。私の質問は、言語としてのJavaの機能と、JVMベースの言語が最新のJVMで実行されるかどうかではなく、他のJVM言語がこれらの新機能を「見る」/使用する方法に焦点を当てています。
11 java  scala  clojure 

1
Scalaで関数が明示的な戻り値の型を持つ必要があるのはなぜですか?
私は最近Scalaでプログラムすることを学び始めましたが、これまでのところ楽しかったです。私は、別の関数内で関数を宣言する機能が本当に好きです。 私がScalaについて抱えている問題の1つは、Scalaがその関数に明示的な戻り値の型を必要とするという事実です。そして、これは言語の表現力を妨げると感じています。また、その要件でプログラミングするのは難しいだけです。たぶん、私はJavascriptとRubyのコンフォートゾーンから来たからでしょう。しかし、Scalaのようにアプリケーションに大量の関数が接続されている言語の場合、自分が書いている特定の関数が再帰後に再帰で返されるタイプを正確に頭の中にブレーンストーミングする方法を考えることはできません。 関数の明示的な戻り値型宣言のこの要件は、JavaやC ++などの言語では気になりません。JavaとC ++の再帰は、実際に発生したときに、多くの場合2〜3個の関数で処理されていました。Scalaのように、いくつかの機能が連鎖することはありません。 だから私は、Scalaが明示的な戻り値の型を持つ関数の要件を持たなければならない正当な理由があるのだろうかと思いますか?

3
ScalaまたはClojure関数型プログラミングのベストプラクティス
私は多くの自習用コーディングを行い、アクター、ソフトウェアトランザクションメモリ、データフローなどの並列プログラミングモデルでいくつかの経験を得ました。 これらのアーキテクチャを実際の生活-高負荷Webアプリケーションに適用しようとすると、どのモデルもデータの耐久性と永続性をサポートしません。実際のタスクでは、最後にデータを保存する必要があります。これは、DBを使用し、DB同期をトラップしなければならないこと、スケーラビリティのボトルネックなどの可能性があることを意味します。 Akkaアクターまたはソフトウェアトランザクションメモリを使用し、最後に永続性を実装するアーキテクチャ(srcまたはtextまたはdiagramまたはblueprints)の良い例を知っている人はいますか? 実際のアプリケーションでのトランザクションメモリ、アクター、データフロー、タプルスペースの良い例/アイデアは大歓迎です。

4
「混合」言語での設計:オブジェクト指向設計または関数型プログラミング?
過去数年間で、私が使用したい言語はますます「機能的」になりつつあります。現在、C#、F#、Scalaなどの「ハイブリッド」言語を使用しています。ドメインオブジェクトに対応するクラスを使用してアプリケーションを設計し、これによりコーディングがより簡単に、より正確に、より安全になる機能機能を使用します(特にコレクションの操作時または関数の受け渡し時)。 ただし、パターンを設計する場合、2つの世界は「衝突」します。私が最近直面した具体的な例は、Observerパターンです。アイテムが作成または変更されたときに、プロデューサーに他のコード(「消費者/オブザーバー」、たとえばDBストレージ、ロガーなど)に通知してほしい。 私は最初に次のように「機能的に」それをしました: producer.foo(item => { updateItemInDb(item); insertLog(item) }) // calls the function passed as argument as an item is processed しかし、私は今、もっと「OO」アプローチを使用すべきかどうか疑問に思っています。 interface IItemObserver { onNotify(Item) } class DBObserver : IItemObserver ... class LogObserver: IItemObserver ... producer.addObserver(new DBObserver) producer.addObserver(new LogObserver) producer.foo() //calls observer in a loop 2つのアプローチの長所と短所はどれですか?かつてFPの第一人者が、デザインパターンは言語の制限のためだけにあると言ったことを聞いたことがあり、それが関数型言語にはほとんどない理由です。たぶん、これはその例でしょうか? 編集:私の特定のシナリオでは、私はそれを必要としませんが、..機能的な方法で「観測者」の削除と追加をどのように実装しますか?(つまり、パターンのすべての機能をどのように実装しますか?)たとえば、新しい関数を渡すだけですか?

3
ScalaとLWJGLを使用した簡易ゲームの関数型プログラミングアプローチ
Javaの命令型プログラマであるIは、関数型プログラミングの設計原則(特に参照の透明性)に基づいて、スペースインベーダーの単純なバージョンを生成する方法を理解したいと考えています。しかし、デザインを考えようとするたびに、極端な可変性の泥沼で迷子になります。これは、関数型プログラミングの純粋主義者によって回避される同じ可変性です。 関数型プログラミングを学習する試みとして、LWJGLを使用してScalaで非常にシンプルな2DインタラクティブゲームであるSpace Invader(複数形の欠如に注意)を作成することにしました。基本的なゲームの要件は次のとおりです。 「A」キーと「D」キーでそれぞれ画面の下部にあるユーザーシップを左右に移動しました 発射間隔が0.5秒になるようにスペースバーで起動したユーザー船の弾丸を真っ直ぐ発射 射撃の間に0.5秒から1.5秒のランダムな時間で起動するエイリアン船の弾丸が真下に発射されました 元のゲームから意図的に除外されたものは、画面の上部にあるWxHエイリアン、分解可能な防御バリアx3、高速ソーサー船です。 さて、実際の問題領域に移りましょう。私にとって、決定論的な部分はすべて明らかです。アプローチ方法を検討する私の能力を妨げているのは、非決定的な部分です。決定論的な部分は、弾丸が存在する場合の弾道、エイリアンの連続的な動き、およびプレイヤーの船またはエイリアンのいずれか(または両方)の衝突による爆発です。(私にとって)非決定的な部分は、ユーザー入力のストリームを処理し、エイリアンの弾丸の発射を決定するためのランダムな値のフェッチを処理し、出力(グラフィックとサウンドの両方)を処理します。 私はこの種のゲーム開発を長年にわたって行うことができます(そして、これまでしてきました)。しかし、それはすべて命令型パラダイムからでした。さらに、LWJGLは、スペース侵略者の非常にシンプルなJavaバージョンを提供します(これは、セミコロンなしのJavaとしてScalaを使用してScalaに移行し始めました)。 Java / Imperativeプログラミングから来た人が理解する方法でアイデアを直接扱ったものはいないように思われる、この領域に関するいくつかのリンクを以下に示します。 純粋に機能的なレトロゲーム、パート1ジェームズハーグ 同様のスタックオーバーフローポスト Clojure / Lispゲーム スタックオーバーフローに関するHaskellゲーム Yampaの(Haskellでの)関数型リアクティブプログラミング Clojure / LispとHaskellのゲーム(ソース付き)にはいくつかのアイデアがあるようです。残念ながら、私は単純なJava命令型脳にとって意味のあるメンタルモデルにコードを読み取ったり解釈したりすることはできません。 FPが提供する可能性に非常に興奮しており、マルチスレッドのスケーラビリティ機能を味わうことができます。Space Invaderの時間+イベント+ランダム性モデルのような単純なものをどのように実装し、高度な数学的理論のように感じることなく、適切に設計されたシステムで決定論的部分と非決定論的部分を分離する方法を理解できたと思います; すなわちヤンパ、私は設定されるでしょう。単純なゲームの生成にYampaの理論レベルの学習が必要と思われる場合、必要なすべてのトレーニングと概念フレームワークを取得するためのオーバーヘッドが、FPの利点の理解を大きく上回ります(少なくともこの単純化された学習実験の場合) )。 フィードバック、提案されたモデル、問題領域へのアプローチ方法(ジェームズハーグがカバーしている一般性よりも具体的)をお勧めします。

4
Javaの代わりにscalaが良い選択でしょうか?
Java(frameworks / ECOシステムなど)のすべての.net開発者をトレーニングする新しいプロジェクトを開始します。C#で記述された多くのコードがあり、すべてJavaで書き直す必要があるため、これらはすべて無駄になるようです。私が見る問題は、最初の1年かそこら(おそらく2年)は以前のものが今はJavaであったものを再現するためにほとんどの時間を費やすため、何も提供できないことです。 私たちのチームは世界中のさまざまなオフィスに分散しており、多数のJava開発者(20から30)と10人の開発者が.netを使用しているため、すべての開発者が同じ言語/プラットフォームを使用して、コンポーネント/モジュールを再利用します。だから私は経営者の視点を理解できます。 昨日、Scalaに出会い、現在の製品(C#で記述されている)でこれを使用する方が良いかどうか疑問に思っていました。少なくとも1年で機能する製品ができます。また、製品の他の部分を移行しながら、1年でJavaの世界で使用できるモジュールがあります。 私たちが達成しようとしていることを考えると、ScalaはJavaよりも良い選択でしょうか?
11 java  c#  scala 

2
Scalaのパラメーターなし&空の括弧メソッド
現在、OderskyのプログラミングScala(2番目)を介してScalaを学習しています。私は第10章まで、パラメーターなしの空の括弧付きメソッドの導入を開始します。頭がおかしいだけです。 これまでのところ、私が理解しているのは、メソッドに副作用がある場合は空の括弧を使用し、それ以外の場合はパラメーターのないメソッドを使用する必要があることです。 この慣習の利点は何なのかわかりません。私はStack Exchangeで投稿を読みましたが、正直なところ、投稿がこのトピックについてある程度深く議論し始めたとき、私は迷いました。 この言語機能の典型的な使用例と、それをよりよく理解するのに役立つ利点について簡単な説明を探しています。
10 scala 

2
Scalaコンパイラーがシールされていないクラス/トレイトに対してパターンマッチング警告を出せないのはなぜですか?
非シールtraitまたはabstract classScalaを使用してからパターンマッチングを使用する場合、コンパイラーはこの特定のパターンマッチのコンパイル時に、このトレイト/クラスの可能な実装が何であるかを知りませんか?だから、もしそうなら、可能性のあるすべての依存関係/インポートをチェックすることによって、使用できるタイプを知っているのでtrait/ abstract classがシールされていなくても、パターンマッチの警告を出せないでしょうか? たとえば、私がに対してOption[A]パターンマッチングを行っているSome[A]が、に対してNoneは行わない場合、Optionはシールされているため、コンパイラは文句を言うでしょう。 コンパイラがそれを認識/解決できない場合、なぜ彼はそれができないのですか?そして、コンパイラーが(理論的に)それを実行できる場合、それがScalaで使用されない理由は何ですか?そのような動作をサポートする他の言語はありますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.