Byzant est une série qui donne accès à des perspectives d’initiés de personnes bien informées dans l’écosystème Neo et l’industrie plus large blockchain. Pour la semaine suivante, après qu’un invité a partagé leur point de vue, ils seront encouragés à participer à la discussion sur le neo subreddit en répondant aux questions pertinentes de la communauté.

Cette semaine, nous avons parlé avec Harry Pierson du modèle de programmation unifié Neo, visant à unir différents sous-systèmes et modèles de programmation à Neo pour fournir une expérience unique et productive développeur.

Harry est un vétéran de Microsoft avec plus de 20 ans d’expérience avec le géant du logiciel, répartis dans une variété de rôles, y compris la consultation, l’évangélisation, et en tant qu’architecte informatique. Il a été gestionnaire de programme pour le projet IronPython, puis plus tard a rejoint l’équipe Windows, où il a passé son temps en tant que gestionnaire de programme dans l’équipe qui a construit Windows Runtime. Plus tard, il est retourné à ses racines de développement de base, travaillant sur le projet de recherche Midori OS, développé la plomberie multi-plateforme qui alimente SmartGlass (Projet Rome), et a été un membre fondateur de l’équipe xlang.

Depuis qu’il s’est joint à Neo Global Development Seattle en tant qu’architecte en chef, Harry a défendu l’importance de fournir une expérience de développeur de premier plan, et a consacré son expérience à la création d’outils puissants et adaptés aux développeurs tels que la boîte à outils Neo Blockchain.

Les lecteurs intéressés à poser plus de questions sur le modèle de programmation unifié peuvent se joindre à la conversation et parler avec Harry dans le fil suivant:

JOIGNEZ-VOUS À LA CONVERSATION

NNT: Pourquoi Neo a-t-il besoin d’un modèle de programmation unifié, et comment peut-il influencer le développement de l’écosystème ?

Harry Pierson:

Tous les types de systèmes distribués – décentralisés ou non – couvrent par définition plusieurs modèles de programmation. Dans une application Web à trois niveaux, par exemple, il est courant d’avoir du code en cours d’exécution sur le client dans un navigateur Web, sur le serveur Web et à l’intérieur du référentiel de données. Chacun de ces systèmes utilise des API, des modèles de programmation et des langues traditionnellement différentes. Comme le nombre de ces différents « oncept » de programmation augmente, plus il est difficile pour un développeur individuel d’envelopper leur tête autour de tous. Cette complexité inhérente rend plus difficile pour les nouveaux développeurs embarqués et limite la productivité des développeurs existants.

Peu de temps après avoir rejoint le bureau de Neo à Seattle, j’ai créé une taxonomie dans le cadre de mes réflexions initiales sur

l’expérience développeur

Neo .

Les boîtes en haut représentent différents modèles de programmation dans le développement décentralisé d’applications de La Blockchain Neo. Les cases ci-dessous décrivent le modèle et les abstractions d’action – les noms et les verbes du système si vous voulez – qui devraient être aussi cohérentes que possible à travers l’écosystème de développement. Différents modèles ont des capacités différentes – une transaction est scriptible pendant la création, mais en lecture uniquement à l’intérieur d’un contrat intelligent ou lorsqu’il est traité par un plugin de nœud. Cependant, dans la mesure du possible, les choses qui sont les mêmes devraient se comporter de la même façon et avoir la même structure.

Dans Neo3, nous apportons deux changements importants aux développeurs C# pour aider ces modèles de programmation.

Tout d’abord, il ya une nouvelle

bibliothèque RpcClient

. L’API RPC

a évolué en Neo3, mais ce sera la première fois que le projet Neo a expédié un SDK C# pour accéder à l’API RPC qui utilise les mêmes types fondamentaux et les mêmes modèles de domaine que le reste de Neo (y compris l’API Plugin).

Deuxièmement, nous avons un nouvel effort de suivi des éléments de travail items

pour mieux aligner le système de type dans le cadre de contrat intelligent avec ce que les développeurs sont habitués à dans les deux autres API. J’ai ouvert le

premier PR pour ce travail

 la semaine dernière, en ajoutant des types fondamentaux comme ECPoint et UInt256 à l’infrastructure de contrat intelligent et la mise à jour des modèles de domaine, le cas échéant pour les utiliser. Ce changement, avec d’autres à venir dans le tuyau, fournira la compatibilité source pour le code C # en cours d’exécution à l’intérieur et à l’extérieur d’un contrat intelligent.

L’autonomisation des développeurs a toujours été un mantra de base pour Neo. Un modèle de programmation unifié est un autre élément de cet effort le long de la «

intégration transparente

» avec les écosystèmes linguistiques existants et la boîte

à outils intégrée aux développeurs VSCode

.

JOIGNEZ-VOUS À LA CONVERSATION

Étiquettes :