Rustの実用性が理解できる図を作成してみた 〜C/C++/Java/JS/Python/Go/TS/Elixirとの比較〜
エディタ支援 言語の公式がエディタ支援(LSP等)を提供しているかを示しています。 自動テスト 言語の公式が自動テスト(ユニットテスト等)を備えているかを示しています。 リンタ 言語の公式がリンタを提供しているかを示しています。 ビルドシステム 言語の公式がビルドシステムを提供しているかを示しています。 パッケージマネージャ 言語の公式がパッケージマネージャを提供しているかを示しています。 フォーマッタ 言語の公式がフォーマッタを提供しているかを示しています。 手続き型 言語のプログラミングパラダイムが手続き型プログラミングを強くサポートしているかどうかを示しています。 オブジェクト指向 言語のプログラミングパラダイムがオブジェクト指向プログラミングを強くサポートしているかどうかを示しています。 関数型 言語のプログラミングパラダイムが関数型プログラミングを強くサポートしているかどうかを示
RustのGATsでモナドを作れるか？
はじめに Rust 1.65で GATs (Generic associated types)[1] が追加された。これは次のようにassociated type（型メンバー）が型パラメーターを取ることできるものとなっている。 このように型を取る型を記述できるようになったときに思いつくものとして「モナド」がある。モナドの具体的な定義や性質はいったん放置するとして、任意の型Aについて、たとえばList<A>やOption<A>がモナドとなる。したがって次のようにトレイトMonadを定義すればOptionなどを次のようにモナドへ適合させることができるのではないかと思うだろう。 この記事では実際に上記のMonadのようなトレイトを実際のOptionなどに適用してどの程度うまくいくのかを伸べる。なお、この記事を読むにあたってモナドや関数型言語などの知識はほぼ必要なく、HaskellやScalaなど
Rustを通して見るオブジェクト指向｜TechRacho by BPS株式会社
こんにちは。yoshiです。夏のTechrachoフェア2022ということで、夏とは何の関係もない記事を書いていこうと思います。 業務ではC++をやっていながら前回、前々回にTechrachoで書いた記事に引き続きRustをやっていく訳ですが、定期的に炎上しがち（？）なオブジェクト指向の話です。みなさん、オブジェクト指向は好きですか？ オブジェクト指向って何だろう？ A. なんもわからん なんて言ってしまったら話が終わってしまうのですが。 歴史的な話をするとオブジェクトという用語はSimulaが初出で、オブジェクト指向はアラン・ケイがSmalltalkで導入したもの、という話になりますが、一方でビャーネ・ストロヴストルップがC++に導入した「カプセル化・継承・ポリモーフィズム」の組み合わせのことを指すことが多く、SmalltalkのそれとC++のそれにも違いがあるので定義が定まらない概念で
オブジェクト指向は継承で多態するプログラミング - きしだのHatena
オブジェクト指向って継承による多態があるからこそなんだけど、継承が非推奨になって以降に雰囲気でオブジェクト指向を知った人には、継承はオプションでカプセル化だけでオブジェクト指向って言ってしまいがちに思います。 実際はカプセル化はオブジェクト指向固有じゃなくて、クラスでカプセル化を実現してるだけです。 さまざまな人のオブジェクト指向の定義 本来ならどのように継承こそがオブジェクト指向なのかという説明をするんですが、かなり長くなりそうなので、とりあえずはいろいろな人たちのオブジェクト指向の定義を抜き出してみます。 「ここに挙がってるのはオブジェクト指向の一派にすぎない」というような意見もありますが他の派閥についてまとまって定義され共通認識になっているようなものは見当たらないので、プログラミングの指針には なりづらいと思います。 ストラウストラップ C++を産んだストラウストラップは「C++の設
自社サービスはOOP、業務システムはDOAで作ろう - 設計者の発言
前回記事で、一般的な業務システムの開発において、DDD（ドメイン駆動設計）が提唱する「ユビキタス言語」の実践は難しいと説明した。そもそもDDDを含むオブジェクト指向プログラミング(OOP)は、一般的な業務システムの開発には向いていない。とはいえ、企業がOOPで内製することが合理的なものは存在する。企業に売上をもたらす製品（プロダクト）系のソフトウエアだ。典型的な例が「自社サービス」の運用を支える「サービス支援システム」である。これと業務システムとの関係を見よう。 自社サービスと業務システムの関係 自社サービス、つまり、WEB上で提供される有償サービスで稼いでいる企業があるとして、そのシステム構成はどのような形になるだろう。まずは、企業システム全体の一般形について確認しておこう（図１上 参考記事）。 図１．企業システムの一般形とサービス支援システムの位置づけ この中のａがいわゆる業務システム
なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
オブジェクト指向プログラミングは終わった カプセル化が悪い(感想戦) - Qiita
が(良くも悪くも)注目頂き、その観測で思ったことのメモです。1年後の自分用です！ もっかい言いたいこと再考のポエムです。 概要 関数型には意図的に触れたくなかった 継承や再利用性への懐疑の共通認識 抽象化戦略開発戦略で補う話 タイトルは釣り 抽象化という言葉のふわっと感 カプセル化が問題 関数型言語には意図的に触れたくなかった ポリモーフィズムのくだりで、関数型のご指摘が多かったのですが、あえて直接は触れたくありませんでした。これは、オブジェクト指向 vs 関数型にしたくなかったからです。(結果、Rust/Goに被弾させました) なぜかと言えば、オブジェクト指向を(結果として)衰退させたのは、あくまでも 開発手法の変化 や設計論の精錬が主軸だと認識しています。 不確実性に適応する上で、継承やカプセル化による状態隠匿という戦略が、良い筋に動かず、オブジェクト指向なりに変化を遂げた結果だと考え
オブジェクト指向プログラミングは終わった - Qiita
追記: 振り返りを書いてみました～ -- ここから元記事 別題: 抽象化って言葉もう。。 社内の記事にて、オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) | アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章 |本 | 通販 | Amazonを紹介してもらいました。 取り上げられた、共通性／可変性分析の解説を見て、はっと思うことがありポエムを仕立てました。 共通性／可変性分析 共通性／可変性分析については、書籍を読むかググって頂けると良いですが、社内記事が良かったので引用させて頂きます。 問題領域にある概念を見つける（共通性の分析） その流動的要素を洗い出す（可変性の分析） 流動的要素を見ながら、その概念が持つ責務を果たすための抽象的側面（≒インタフェース）を導く 各流動的要素の実装上の観点から、インタフェースが適切かどうかを見極め、補正する オ
新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし
Rustでの 抽象化 3パターンについて
※この記事は全然入門記事ではないです。Javaなどのオブジェクト指向言語とRustをある程度理解している前提での記事です。あと、メモ程度に雑に書いています。 今回は抽象化がテーマです。オブジェクト指向の多態相当のことをRustでどうのように解決すればいいのでしょうか。個々の実装型の都合によらず、呼び出し側は統一的なインターフェイスで操作するケースはRustでもあるはずです。 オブジェクト指向言語の設計に慣れていると、Rustで設計するときにどうしたらいいかわからないことがあります。なぜならRustには継承がないからです…。まぁJavaと比べるとだいぶ違うので頭を切り替える必要があります。今回はそういう感じの記事です。 では、早速デザインパターンを題材にして考えてみましょう。 抽象化について 簡単なコマンドパターンから考えます。 ここでは単純に渡した文字列を標準出力するコマンドを考えます。以
2021年の「オブジェクト指向」を考える
きしださんが先日もたのしいお題を投下されていました。 出遅れましたがこのネタについて少し掘り下げてみます。 念のため個人的なスタンスをあらかじめ表明しておくと、オブジェクト指向に対してはそれなりに好意的ですが、別に時代の最先端だとかソフトウェア開発に必須の知識というほどではない（でも知っておくと便利というか、知らないと不便なこともあるかもしれないのでわざわざ避けるのはおすすめしない）というくらい温度感です。 オブジェクト指向 is 何 そもそも「オブジェクト指向」という言葉自体、座りの悪い言葉です。 意味が明確なのは「オブジェクト指向プログラミング(OOP)」、「オブジェクト指向プログラミング言語(OOPL)」、「オブジェクト指向設計(OOD)」「オブジェクト指向分析(OOA)」といった「オブジェクト指向なんとか」の方で、それらをふわっとまとめた（ような気がする）単語が「オブジェクト指向」
関数型プログラミングはまずは純粋関数型言語を用いて、考え方から理解しよう
この記事は、関数型プログラミングはまず考え方から理解しよう の記事を純粋関数型言語Elmで書き換え、一部の文章について批判的に言及させていただいた記事になります。この記事を書こうと思ったきっかけとしては、今回参考にさせていただきた記事が過去に書かれたものにも関わらず、今に渡っても見られていそうなこと。未だにパラダイムの理解に関する誤解が多く散見されること。改めて純粋関数型言語の実用性・有用性について、見直されるべきだと思い、この記事を執筆させていただきました。 次のステップアップ記事は、[超入門] FizzBuzzで考える関数型プログラミング学習を純粋関数型言語でやる理由です。 はじめに、この記事の主張を結論としてまとめておきます。 対比すべきは、関数型プログラミングとオブジェクト指向プログラミングではなく、関数型プログラミングと手続き型プログラミングである 関数型プログラミングの考えを学
２つのオブジェクト指向ーメッセージ・パッシングと抽象データ型 - Hot Heart, Cool Mind.
オブジェクト指向には、もともとアラン・ケイが創案したメッセージ・パッシングのオブジェクト指向と、その後、抽象データ型から発展したオブジェクト指向の２つがあって、その２つは、プログラム言語の機構の面からは共通する要素も多いのだけどプログラミングに対するビジョンという点では相当に異なっている、という見方があります。 これに関しては、id:sumim さんが「二つのオブジェクト指向とそれぞれのメリット」という行き届いた論考を公開しておられて、僕などはそれを読んで頭を整理した口です。 その後、それを踏まえて自分なりに両者の違いを考えてツイートしましたが、言葉足らずな点もあったので、内容を整理するとともに加筆しました。 言語機構に惑わされるな この２つのオブジェクト指向は、実現する機構の面では似ています。オブジェクト指向の３要素として「カプセル化、継承、ポリモフィズム」があると言われますが、そうした
プログラミング言語の未来はどうなるか | κeenのHappy Hacκing Blog
κeenです。最近JEITAのソフトウェアエンジニアリング技術ワークショップ2020に参加したんですが、そこで五十嵐先生、柴田さん、Matzとパネルティスカッションをしました。その議論が面白かったので個人的に話を広げようと思います。 年末年始休暇に書き始めたんですが体調を崩したりと色々あって執筆に時間がかかってしまいました。 時間を置いて文章を書き足していったので継ぎ接ぎ感のある文体になってるかもしれませんがご容赦下さい。 というのを踏まえて以下をお読み下さい。 いくつか議題があったのですが、ここで拾うのは一番最後の「プログラミング言語の未来はどうなるか」という話題です。 アーカイブが1月末まで残るようです。もうあと数日しかありませんが間に合うかたはご覧下さい。 そのとき各人の回答を要約すると以下でした。 五十嵐先生：DSLを簡単に作れる言語というのが重要。それとプログラム検証、プログラム
現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだのHatena
某所でオブジェクト指向についていろいろ書いたのでまとめておく。 問題意識としては初学者がなにかというと「オブジェクト指向できるようになりたい」のようなことを言うけどそこまでの優先順位でがんばるものではないんでは、というところです。 まず前提として、オブジェクト指向は1980-2000年くらいに流行って発達したものの、それ以降は時代にあわせた進歩はしていない20年以上前の技術ってのがあります。 そのころは今だとCPUのキャッシュにも満たないようなメモリをやりくりしてプログラムを書く必要があったので、オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています。 そしてオブジェクト指向にはそこから目だった更新はなく、タイトルに書いたように、カメラがやっとついたくらいのガラケーのような古い技術という感じがします。 オブジェクト指向について、アプリケー
プログラミング言語論入門 - riswu’s blog
第0章. なぜ Scala を使うのか？ はじめに 本稿は、John C. Mitchell 氏らによる Concepts in Programming Languages を基に自身の見解を交え、私がなぜ Scala を好んで使うのかを論じた記事になります。 プログラミング言語の歴史 本題に入る前に、プログラミング言語の歴史について紹介します。 年代 言語・イノベーション 1950 Fortran and Cobol 1960 Lisp and Algol 1970 Abstract data types (Simula, C, SQL) 1980 Objects (Smalltalk, C++) 1990 Java, JavaScript, Python, Ruby これは、年代ごとに開発された言語およびイノベーションを表にまとめたものになります。ただし、この表には欠けている事柄があり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
