現在開発中の場所ではなく、Delphiを開発する価値がある場所





開発者に本当に必要なものは何ですか? 私は今日考えていました- 最初にコメントをいくつかの手紙に入れてから、それが投稿を引いていると決めました:



第一に、Windowsのすべての開発が鉄のレベルから離れて移植しようと繰り返し試みられたことにひどく腹を立てます。 アプリケーションソフトウェアとプロセッサの間、スムーズなソフトウェアとOSの間に、より厚いガスケットを詰め込みます。 私見、ネイティブコードに近いあなたがハードウェア、OSに近い努力する必要があります! 任意のハードウェア、任意のOS。 開発したOOPツール、Pascalが愛する構文シュガー、強力なIDE、およびネイティブの高速ワンパスコンパイラを特徴とするC ++の代替としてObject Pascalを開発する必要があります。



さらに、サードパーティのライブラリとの高度な統合機能が必要です。 Cと比較して、これは非常に不足しています。 周りには多くのライブラリがありますが、すべての種類のインタープリターはありえませんが、Delphiライブラリの場合は、いちじくが見つかります。そのため、ある程度の作業を行う必要があります。 そして、APIの更新時にやり直します。 このためには、シンラップジェネレーターが必要です。 Lazarusにはh2pasと呼ばれる記事がありますが、開発するか、統合する必要があります! 彼らはそれをしますか?..さらに良いこと-1つのプロジェクト、特にライブラリh-ファイルの直接接続で、異なる言語のモジュールを理解し、透過的に使用するようにしてください。 これに対処できるように、リンカを作成できると確信しています。



組み込みのアセンブラがあり、それを突っ込んでいた...アセンブラの挿入はもはや可能ではなく、全体の手順のみが可能です。 なぜ?.. xs。 それを返して開発し、文書化する必要があります(組み込みアセンブラーに関する文書はまったくありません!)、プロセッサーおよびコプロセッサー用のすべての最新の命令セットをサポートしてください!



独自のコンパイラではなく外部コンパイラを統合する手段。 交換可能なコンパイラ-さまざまなメーカーのさまざまなプラットフォーム向け。 たとえば、Intelがそのプロセッサ用の最適化コンパイラを作成しているのを見ました-Delphiのプログラムに使用できるのは素晴らしいことです。



キットには、dll(これは昔からあり、良いです)だけでなく、ActiveX(これも昔ですが、美しく設計されていません)へのアクセスだけでなく、.net、Unixライブラリへの組み込みの構文手段が必要です、MacOS、iOS、Androidなど。 -一般に、プラットフォーム形成ライブラリのサポート。 FireMonkey向けにどのように設計されているかはまだ見ていませんが、すでに存在しているかもしれません。しかし、FireMonkey自体よりも、あらゆる角度で大声で話題にならないのは奇妙です。 しかし、ネイティブDelphiで.netライブラリのパワーを使用する機能については、まったく聞いていません。



したがって、これらのツールでは、ベースライブラリ.net、Cocoa、iOS、Android SDK、X Window SystemなどのAPIのラッパーがあるのは事実です。 おそらく、上記で説明したシンラッパーのジェネレーターによってオンザフライで生成されたものです。また、ローカルおよびオンラインの任意のソースからリンクできるようにするためのドキュメントもあります。



それらの上に、VCLのような抽象化レベルとして-Qtへの薄いラッパー、またはDelphiの下のQtポートです。 VCLの代替として、コンポーネントパッケージをIDE自体が使用するパッケージに結び付けることにより、遺伝性疾患の患者が複雑になります。 フォームデザイナーとこれらのフォームのストレージ形式の変更をサポートする必要があります。デザイナーコードは開発環境のコードおよびベースライブラリから独立している必要があります。これにより、デザイナーで修正VCLを使用したり、VCLを使用したりできません。



ModelMakerダイアグラムに組み込まれたものだけでなく、オープンなAPIのプラグインである、コードとフォームのあらゆるものへの両面オンライン変換が必要です。 特に、コードをC ++コードに変換するだけでなく(hファイルをインポートするための素晴らしいオプションの1つである)、アセンブリ言語に変換することも可能です(どちらもサードパーティのコンパイラを使用するのに便利です) GNUおよびIntel)だけでなく、実行可能バイナリコードに直接、つまりオンザフライでコンパイルするため、リンカーのみが起動して、未使用のファイルを破棄して実行可能ファイルを形成できるようになります。



ちなみに、さまざまなプラットフォーム用のパッケージとディストリビューションのアセンブリ-プラグインも、コミュニティが影響力のある領域に参加できるようにします。



唯一の質問は、ここにあるものと販売方法です。 このようなプロジェクトで成功する収益化戦略は何でしょうか? FreePascalを備えたLazarusが追いつき、理論的にもすべてを行うことができます...



UPD:「 The Future of WinRT or Going Native 2.0 」という投稿で、あるAlexandre Mutelが「コードを何かに変換する」こととネイティブの有用性について私にエコーします



All Articles