問題タブ [paradigms]

エージェント同士が相互作用するさまざまな種類のプロセスを作成したいと考えています。特別な言語を使用して、エージェント間の相互作用のプロセスを記述 (定義、形式化) したいと考えています。つまり、エージェント同士が何らかの形で対話できる環境を提供し、それに適したプログラミング言語を使って対話の仕方を記述したいのです。そのような言語はありますか？

抽象的ではなく、より具体的にするために、エージェントを Web サイトのユーザーと考えることができます。Web サイトはユーザーの行動に応じて進化します (ユーザーには行動の自由があります)。ユーザーができることと、そのアクションの結果として何が起こるかは、言語で説明する必要があります。

FP と OO が直交しているという考えを理解し、検証しようとしています。

まず、2 つの概念が直交するとはどういう意味ですか?

FP は可能な限り不変性と純粋性を奨励しますが、OO は状態と突然変異のために構築されているように見えます – 命令型プログラミングのわずかに組織化されたバージョンですか? オブジェクトが不変である可能性があることは理解していますが、オブジェクト指向は状態/変化を暗示しているようです。

それらは正反対のようです。それはそれらの直交性にどのように影響しますか?

Scala のような言語では、OO と FP の両方を簡単に実行できますが、これは 2 つのメソッドの直交性に影響しますか?

必要なタイプに応じて、呼び出す別のプログラムに対して異なる出力文字列を生成する必要がある関数があります。

基本的に、呼び出されたプログラムには、呼び出されたタイプを示すコマンドライン引数が必要です。

幸いなことに、変数のタイプをチェックする方法について、SOでこの回答を見つけました。しかし、タイプのチェックが「オブジェクト指向ではない」設計を裏切るという、人々がどのように異議を唱えているかに気づきました。それで、タイプを明示的にチェックせずにこれを処理する他の方法、おそらくより「オブジェクト指向」の方法はありますか？

私が今持っているコードは次のようになります：

これは問題なく動作しますが、私が知らないテクニックがあるかどうかを知りたかっただけです。

私は言語の専門家ではありませんが、最近言語に興味があり、主要な概念と「それらの」言語の概要を理解しようとしています。これは、本に関する別の質問に似ています。それで、最初に、主要なプログラミング言語の概念は何ですか、例えば

• 構造化
• 手続き型
• オブジェクト指向
• オブジェクト指向-プロトタイプベース（例：Javaスクリプト）
• 機能的（例：Haskell）
• ロジック指向（例：Prolog）
• メタ（それ自体の純粋な概念の場合？）
• スタックベース（例：Forth）
• 数学ベース/配列指向（例：APL）
• 宣言型
• 連結（例：PostScript）
• （間違いなく不完全なリスト...）

そして次に、これらの概念をうまく理解するために、そのコア概念に基づいて/最も自然で純粋なプログラミング言語は何でしょうか？

• たとえば、JavaはOOですが、アトムのために純粋なOOではないため、良い例ではありません。
• Lispは関数型言語として知られていますが、マルチパラダイムであるため、純粋ではありません。しかし、Lispは「リストベース」の純粋な実装かもしれません（それが概念として数えられる場合）。
• 構造化されている（GOTOはない）が手続き型ではない言語はありますか？（多分XSLT v1.x）

誰でも私に説明できますか

1. データ指向プログラミングとは？
2. データ指向プログラミングと関数型プログラミングは同じですか?
3. データ指向プログラミングはオブジェクト指向プログラミングとどう違うのですか?
4. オブジェクト指向プログラミング言語ではなく、データ指向プログラミング言語を選択するのはどのような状況ですか?

アクティブな接続を追跡したい場合、それらをリンク リストに保存するか、インデックスが接続の ID を表す配列に直接保存する方がよいでしょうか? たとえば、次のような競合状態の問題を回避したいと考えています。

• リスト内の接続数が多い
• 誰かがリストの最後にある接続を探し始めます
• その間、検索中に接続が切断されます

私は最近Programming Scalaを購入し、それを読んでいます。言語は間違いなく私が期待したものではありません! 具体的には、Lisp マクロと Haskell の型レベルの副作用の分離を除いて、私が知っているほぼすべてのプログラミング言語のアイデアを実装しているようです。

率直に言って、それは私をやや圧倒しています。非常に多くのツールを自由に使用できるのは良いことだとは思いますが、実際には JVM で厳密に型指定された関数型言語を探していました。おそらくそのようにScalaを使用できると思いますが、ライブラリとやり取りしたり、他の誰かのコードを調べたりすると、この高度な（私にとって）OOPの多くに遭遇することになると思います--特性と「オブジェクト階層」線形化」、このすべての抽象的でオーバーライドするビジネス、シングルトン、パッケージ、およびコンパニオン オブジェクト、暗黙の変換...さまざまな構文のショートカットやシュガーは言うまでもありません。

多くの正当な理由から、ある言語のスタイルを別の言語に押し込もうとするプログラマーを嘆く人がよくいます。しかし、すべての言語が Scala のようにマルチパラダイムであるとは限らないため、おそらく Scala のコミュニティは異なる見解を持っているのではないでしょうか? 例えばF#では、プログラミングスタイルやOOPの使用量に多少の余裕があるようです。しかし、読んだだけでは、これが Scala にとっても良い哲学であるかどうかはわかりません。

経験豊富な Scala プログラマーがここで私を助けてくれますか? わかりやすくするために編集:基本的に、高度な OOP 側について心配することなく、Scala の FP 機能のみ (またはほとんど) を安全に使用できますか?

とりとめのない質問でごめんなさい！

これはより理論的な質問であり、特定のシナリオではありません。

次のような単純化されたテーブルスキームがあると仮定します。

itemsいくつかの基本データ、item_data各アイテムの追加プロパティが含まれrel_items、異なるアイテム間のツリー関係を設定します。さまざまな種類のアイテム（フィールドで表されるitems.item_type）があり、さまざまなフィールドが格納されていitem_dataます。たとえば、犬、猫、マウスなどです。

いくつかの結合と接続詞を含むより大きなクエリがある場合（親アイテムが他のアイテムといくつかの条件を持つアイテムを取得するなど）、これは、すべての異なるタイプのアイテムを別々のテーブルに分割する場合と比較して、パフォーマンスの問題になる可能性があります（dog、cat、mouse）そしてそれらを単一のものにマージしませんか？

すべてを1つの基本的なアイテムテーブルにまとめると、ビュー（犬、猫、マウス）の作成はパフォーマンスに何らかの影響を与えますか？

編集（以下にコメント）：「種」、「ハウスペット」などをitem_typesと考えました。タイプごとに異なるプロパティがあります。基本的なアイテムテーブルとitem_dataテーブルを使用する目的は、基本的な「オブジェクト」を持ち、データベーススキームを変更することなく、必要な数のプロパティをそれらにアタッチすることです。たとえば、アプリケーションに含まれる動物の数とそのプロパティがわからないため、ユーザーが新しい動物を作成するたびに変更する必要のないデータベーススキームを考えました。

Web開発における「設定より規約」パラダイムの利点は何ですか？そして、それに固執することが意味をなさない場合がありますか？

ありがとう

HTMLページと対応するCSSファイルがあると仮定します。いくつかの要素に丸みを帯びた角を追加したいと思います。1つおきのセクションで背景色を変えたい。セクション見出しごとにホバー状態を追加したいと思います。などなど-私はスタイリングとスタイリングとスタイリングを続けています。

クラス別、ID別、階層別のマークアップでCSSルールを配布する「誰が、何を、いつ、どこで、なぜ、どのように」という3つの極端なことが思い浮かびます。

極端な＃1：すべてのスタイルルールはIDに基づいています。

極端な＃2：すべてのスタイルルールはクラスに基づいています。

極端な＃3：すべてのスタイルルールはDOM階層に基づいています。

明らかに、フロントエンドWeb開発の禅には、クラスの再利用、一意のルール、階層の健全なバランスが含まれます。これは、3つの極端な例のいずれかが、ブラウザーのパフォーマンス、保守性、およびコードサイズに大きな打撃を与えるためです。おもう。それとも私は間違っていますか？新しい.classものがいつ必要かを判断する方法、または適用したいスタイルルールを既存の定義に安全に組み込むことができますか？二人はいつ#id共通のコードをクラスに引き出す必要があるほど類似したルール？クラスを「フォーク」するとき（元の状態を維持し、すべての逸脱した状況の派生を追加するとき（OOP用語で「パーコレーション」）するとき、およびいくつかの互いに素な逸脱のそれぞれに共通のルールをプッシュするとき-明らかにこれは偏差自体の性質（つまり、関係するルールの数））。純粋に階層的なルールを使用する状況はありますか？

質問：この種の議論を支配する経験則はありますか？あなたの経験やアドバイスは何ですか？優れた記事、リソース、本、講義（「テックトーク」スタイルのビデオのボーナスポイント）、またはこのトピックに関するその他のコンテンツはありますか？いくつかの重要なポイントに基づいて議論を続けたいと思います（ただし、コメントは歓迎します）。順不同です。

• 保守性（コードの読み取り、変更、追加のしやすさ）
• DRY（繰り返さないでください）
• 時間効率（オンロードまでの時間、プログレッシブレンダリング）
• スペース効率（マークアップと関連するスタイルの合計サイズ）