Jonathan Crossland's Talkware

The Next Generation of software needs a better, cross platform software abstraction layer.

The Software Abstraction Layer needs to be a small, yet effective and efficient set of utilities and types, that make the base activities in software seamless and effortless.

I cannot dictate what exactly should be catered for in the layer, but there are some problems in our software world that never seems to go away. Some bugs that always need to be dealt with, and complexities that are pointlessly time consuming.

Some of these like features should be perfectly dealt with, bug free, within our platforms, like culture, regional formats and time zones which are still not implemented as well as it could be in the most widely used platforms. .NET took years to get to a usable level. There are several libraries for Dates, all working differently, different benefits, different bugs. But there are other features, infrastructure features that are universal problems, yet universally different on each library and platform you use.

 

But more than that, the "levels of abstraction" are entirely different, all the libraries and platforms are being created with profit and business in mind. They are not designed appropriately enough to be a bedrock for all software. They (like .NET and Java), improve with each year, but they are too different, yet too similar beasts. They all have flaws and goodness, but they are not the same, nor compatible, nor solid.
If you take berkley sockets, or other open source projects where the aim is 'software improvement', not money, things begin to change, but not entirely, as there is no standard to work from either.

 

The Next Generation of software needs a HAL or a Software Abstraction Layer. Except this layer should be a collaboration from many parties, and it should sit above all operating systems, for all platforms. This layer should have programmatic certainties, like guaranteed Dates, across platforms, internet, databases (insert your abilities here). Think of it as a merging of the core data types and functions of .NET and java and the like, into a definite agreed interface that sits on all platforms.

We need a common infrastructure to achieve the next ge neration of software, else we are just widening the gap between platform and system, making users more confused, developers more diverse and many irrelevant to other technologies. 

I want to see Microsoft, IBM, Apple and other important players join up and create "the software layer", that will exist, just below java, just below .NET, and is the same across the platforms. A layer that will disappear like tcp/ip into the layers of inner workings, away from most developers. The benefits of this are enormous.

let's face it, .NET, nor Java are perfect, and how far can each go? How large can the libraries get? until you need another layer on top? I think we need to get the lessons learnt from java and .net into a universal software abstraction layer, that raises java and .net higher up the food chain.

Tags:

&

On the concept of contracts and contracts, I think we need "interface phasing". Having a phased relationship between two parties.
It is imperative that objects and at a higher level, an Application, can change the way they interact by who or what is accessing them.

 

An object should present itself differently to different audiences. Imagine a developer seeing a specific interface, but not a user, or IDE vs developer. Its not role based, because it could be different per application to application communication, although a similar effect can be achieved.

The concept is simple.

I think that coding today suffers from

• Repetitive nature of structural elements: for example: creation of large Object Models, classes, properties, collections and so on.

• Creating Object models with no separation of Context or concerns. I want an object to 'share' code, but for different reasons. Cross-Cutting. Yes, I can create a new object and share code, but that's not always the answer. Imagine two object models, where one is a Facade of the first. I want to simply map the one to the other, not create the entire structure for it again.

• Different ways of extending components. Different ways of creating add-ins, Custom B2B, Adaptors, Bridge patterns etc. It can all be made easier, if we used a "Global extension object system"

• The 'under the hood' 'abstractions, keep changing - not for the better or necessarily for the worse, but for no distinct benefit.

• Contractinitis - Nothing works unless its all explicit. In .NET, can't call the web service with your Person Object, cause its not the same namespace etc.

 

Create automatic and dynamic proxy layers based on metadata and intention of communication. The code is then 'assembled' and made ready for the communication. The code is assembled from existing non contextual code that can fit into a common proxy container and interact.

On a simple level, imagine, you create SOA like methods, stateless and they are formulated by the runtime into a new object that looks like the one required.

This is not the complete answer, but we really need to get to 'smarter relationships' rather than contracts.

See Lack of MetaData on code and .NET Framework libraries

Read Evolution, Architecture, and Metamorphosis - A great piece of work.

 

Tags:

Our software contract world is the accepted norm, and of course we have come a long way with the philosophy as its been the corner stone of our development languages and platforms for how long.
However, other concepts have also existed. In the seemingly archaic world of top down programming, there were no interface or object-oriented contracts. Instead a form of duck-typing and vtable calls ruled the day or even worse pointers and addresses.
Today the concepts of interface and implementation etc are sometimes lost on the new generation of developers, as its so seamless today.
However, I think that if you look at the real world, communication is lossy, and not defined by the same kind of rules.

In the real world we kind of just make sure there is someone around, or get the person focused on us, then we talk. The receiver understands or does not understand, or does not listen, or hears and acts on all that is said. In the real world, not every communication has "roger", "over and out". There are obvious benefits to having it sometimes, but a real pain in other situations.

The interaction of software frameworks is a real candidate for a more lossy communication, or a Communication Agent, put in software terms. The ability to translate messages from "intention to result" is imperative.

When a call is made to string GetUserName() or string getNameOfUser, the intention is the same, but in our current forms of software architecture, a human would have to use a design pattern, Adaptor, Bridge or whichever suited to accomplish it, when clearly, to our human eyes, the function could well be identical but for name.

A new kind of Interface Definition language is needed to declare intentions of interfaces, and allow a mapping agent to successfully arbitrate a result.

Tags:

When one reads of Frameworks, you cant help from getting the impression that its a large beast of a reusable thing, that then gets reused again and again in the domain the framework 'solves'. You can't be criticized for believing that frameworks are hard to build and harder to grow and maintain. And you would be absolutely correct in thinking that vast amounts of developers cringe at yet another framework to learn. All frameworks are different. They have patterns, but are ultimately different and sometimes extremely hard to learn. All well written frameworks would be beneficial, if it was used.

But look at what we have to work with. We build frameworks using objects. We specify frameworks in classes and modules, with interfaces and contracts. All of this is far too low a level for the future of the Software Framework.

A Framework must be built with a higher level language. A framework must have the ability to see itself as a structure for components and a communications platform for other frameworks. This is hard to do, thus not done yet. I like the Business Component Factory. A great book, written a decade or more ago.

I think that a Framework must have connections:

• to other frameworks
• to components

In our object-oriented world we have interfaces that are implemented by an object, but usually only one object (or by composition), at the surface implements that interface. A framework needs more than that. A framework needs an interface that can be declared and implemented across objects and traditional boundaries as well.

One possible form of connection specification is XML, or a DSL that defines and builds the Framework's connections.

Tags: