Share on Twitter
Share on Facebook
Share on Reddit
Share via Email
Share on LinkedIn
Share via RSS

Byzant is a series that provides access to insider perspectives from knowledgeable individuals in the Neo ecosystem and broader blockchain industry. For the following week after a guest has shared their insight, they will be encouraged to participate in discussion on the Neo subreddit by answering relevant questions from the community.

This week, we spoke with Harry Pierson about the Neo unified programming model, aiming to unite different subsystems and programming models in Neo to provide a single, productive developer experience.

Harry is a Microsoft veteran with over 20 years experience with the software giant, spread across a diverse variety of roles including consulting, evangelism, and as an IT architect. He was program manager for the IronPython project, then later joined the Windows team, where he spent his time as program manager on the team that built Windows Runtime. Later he returned to his core development roots, working on the Midori OS research project, developed cross-platform plumbing that powers SmartGlass (Project Rome), and was a founding member of the xlang team.

Since joining Neo Global Development Seattle as chief architect, Harry has championed the importance of providing a best-in-class developer experience, and has poured his experience into creating powerful and developer-friendly tools such as the Neo Blockchain Toolkit.

Readers interested in asking more questions about the unified programming model can join the conversation and speak with Harry in the following thread:

JOIN THE CONVERSATION


NNT: Why does Neo require a unified programming model, and how can it influence the development of the ecosystem?

Harry Pierson:

All types of distributed systems – decentralized or otherwise – by definition span multiple programming models. In a three tier web application for example, it is common to have code running on the client in a web browser, on the web server and inside the data repository. Each of these systems use different APIs, programming models and traditionally different languages. As the number of these different programming “concepts” grows, the harder it is for an individual developer to wrap their head around them all. This inherent complexity makes it harder for onboard new developers and limits the productivity of existing developers.

Shortly after joining Neo’s office in Seattle, I created a taxonomy as part of my initial thoughts on the Neo developer experience.

The boxes at the top represent different programming models in Neo blockchain decentralized app development. The boxes below them describe the model and action abstractions – the nouns and verbs of the system if you will – that should be as consistent as possible across the development ecosystem. Different models do have different capabilities – a transaction is writable during creation but read only inside a smart contract or when processed by a node plugin. However, where possible, things that are the same should behave the same and have the same structure.

In Neo3, we are making two significant changes for C# developers to help these programming models.

First, there is a new RpcClient library. The RPC API has evolved in Neo3, but this will be the first time the Neo Project has shipped an C# SDK for accessing the RPC API that uses the same fundamental types and domain models as the rest of Neo (including the Plugin API).

Second, we have a some new work items tracking effort to better align the type system in the Smart Contract Framework with what developers are used to in the other two APIs. I opened the first PR for this work last week, adding fundamental types like ECPoint and UInt256 to the Smart Contract Framework and updating the domain models where appropriate to use them. This change, along with others coming down the pipe, will provide source compatibility for C# code running inside and outside of a smart contract.

Empowering developers has always been a core mantra for Neo. A unified programming models is another piece of that effort along side “seamless integration” with existing language ecosystems and the VSCode-integrated developer toolkit.

JOIN THE CONVERSATION