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:

By the next turn, our industry will be largely focused on functional requirements, modelling and specific languages for specific tasks. However, having 5 different code files for 5 different languages, and having the spec# /*! !*/ syntax is fair enough, but we are setting ourselves up for a much messy, file managing, experience. Take web projects, where we have CSS, HTML, Javascript, ASP-like tags, code behinds, inline code and more. A typical site could have 4 or 5 different languages and technologies, sometimes different environments to edit and so on.

Towards this, I wrote a post on abstracting the code file from the language
which is the idea that you don't need to have a physical file that you edit, which contains code, but rather a file that contains xml metadata, modelling, code and everything together which is the input into a "View". The view could be textual code editing, a model or I believe more importantly "any". We should be able to code CSS in a VB like syntax if that is our understanding, and it should not matter to the developer, or the developers of CSS, because the SAL (see below) would help the interpretation.

The language is not important, because I should be able to write vb syntax and have it spit out c# into my file, but I always see it as vb. This can be achieved with this abstraction, I mentioned. If like me, you prefer C#, you can open the file and see it as c#, by simply clicking a language menu option.
Likewise, if I only want to see properties, I should be able to toggle this on/off, or if I want to see base class methods of the superclass 'merged' into my current class (grey-code),it should all possible through this abstraction layer, together with other filtering and language oriented viewing features.

More...

Tags: language, ast, editor

A software development tool, capturing project data you can use, no matter the methodology.
However, the word "metric" must now cease. I don't like the word at all. I don't want the useless "10 0009 lines of code of which 5 000" is comments rubbish. I want a tool that actually provides me with valuable info.


Here is my idea for a new development tool extensions, plug-in or add-in. Whatever your lingo, a tool that provides real understanding of the project code. A tool helpful to both developer and manager.

Objective

To provide the Developer, Lead and Manager tools they need to evaluate performance of their current project and previous projects. Towards this purpose, the background tasks of the visual studio environment shall be monitored, for the purpose of presenting value to the team.

Graphs

- The following data captured and presented over a time period graph.
- Classes Created/Removed (methods, properties, fields, events and all the rest)
- Project Assets Created/Removed (Projects, Configuration files)
- Refactoring (when code is moved around, refactoring menus clicked etc)
- How fine grained is the project? A formula using the code stats



Events as MetaData (The attachment icon above represents it)

Two kinds of Events, manual and automatic. Both configurable.

Manual Events
A developer has a small toolbar, with a Create Event button. The developer can press the button, and write a comment at any time, creating a piece of attaching MetaData. So when a server goes down, or when the team system server goes down for some reason leaving people stranded for 2 hours. It is a marker of that event occurring.

Automatic Events
When a certain amount of code lines are reached, without refactoring, raise event.
When a certain amount of classes, functions, methods are created, raise event.


One important aspect, is to be able to compare project to project. So the data should be exportable or comparable to another set of data.

Tags: visual studio, eclipse, add-in, plug-in methods, agile

Case tools, Modelling, UML, you name it, we have had the dream. We have built the tools. We have designed and bashed heads on semantics and special interests. Now the compromise is still not good enough. When a team of people begin to compromise design and philosophies you get a ViewPointMixture. A ViewPointMixture: a mixture of good ideas from various people for various reasons = Bad design (most of the time).

Not all good ideas work well together, albeit a good idea in itself. Most tools then become technical. UML is a technical specification, therefore the tool reflects a 1 to 1 mapping. I don't necessarily want that to always be the case. More...

Tags: uml, modelling, codegen

Something to think about

I would really like to see Design Patterns merge and disappear into our frameworks and runtimes.

For example, A Singleton could easily become a keyword and managed by the runtime.

But specifically here are two scenarios for merging a wrapper, or form of adaptor pattern.

Mapping Types
If you reference an Assembly (A) from your application that contains a Type that you want to use. Then you discover another Assembly (B), which references (A) you can. However, if the Assembly (B) and the Assembly (A) both reference the same Type from let's say a webservice, the code generated, thinks of these as two different Types. Although they come from the same WCF, or web service, they are treated as different. So creating an AssemblyA.Type and passing it to AssemblyB.Method wont work, as the Types are different. (no they are not). What if I could reference both Assemblies and interchange the two Types as if they were the same. Mark it as the same, and the CLR creates an adaptor/proxy for you.

Now if you have a system, and I have a system, both with a Person object, and happily coincidence it looks exactly the same. Albeit different assemblies, differently signed, it effectively could be the same thing, if only our tools allowed it. So what about being able to explicitly mark the two types so that it can be treated the same. A Wrapper within the CLR

yes we can code this manually
But it is not magically done, and that would save a lots of time. Take how .NET generates COM wrappers. Would you want to write it yourself?

In fact, add Duck Typing to this, method mapping, as explicit choices, a developer can make.
Mark the fact, declare that "treat these two classes as the same". Is this not in effect dynamic partial classes vs the traditional static partial class syntax we have now?

Tags: duck typing, c#, types, metadata

Here is mine

FontsAndColours.vssettings (9.49 kb)

In gaming we usually share our configs. Wanna start a VS.NET config share?

I would like to export my code formatting and have it applied when I open a source file. BUT, it must not actually change the layout in file. Distinctly different. Just like fonts and colours are not stored in the code.

Just go to Visual Studio 2008, Tools | Import and Export Settings

Tags: visual studio, export

When we create objects and use config settings to ascertain context and things of that nature, it makes it harder to know what settings there are later on.

This is a significant fact across all things within software. Don't be scared to create small utilities and tools to aid your development. (As long as it does not affect your timelines).
Have you never got to a point in a project when you are wondering why something is not working and it ends up being a config setting?

Here is a simple solution for simple key/value settings More...

Tags:

and the editor provides you with visualizations of the code file, which contains a base language, metadata and more contextual information.

The Web 2.0 of Code Editing?

Currently, and even our new tools, like OSLO, when its released, is and will be file based.
Now that in itself is fine, to keep in line with source control and other file based tools. But our Integrated Development Environments require a better, a whole new kind of Code Editor.

I believe that we need to create what I tentatively call ActiveEditors. An ActiveEditor is one which as described above surround code snippets, understands a lot more about Context and the code we write. In order to do that, it should build a Code Tree, Abstract Syntax tree -LIKE, Object Model, separating the FILE from the Editor.

This means that we open a FILE, but view an ActiveEditor, showing a generated “view” of the file.

The actual file and the contents could be XML, or MSIL, but what we see (via built in CodeGen), is c# or vb. So the actual code file needs not be in a particular language.

What does this do? It provides an abstraction that creates a dynamic representation of the code file, in your language. Have a look at the picture. The file could store c#, but it never directly puts the textual content of that file in the editor. Instead, it generates the code, from the model, built from the file, and pushes that into your editor. Based on a setting, the file could be MSIL, and your view could be C#, or any combination.



Now you could write an entire project in c#, but at anytime, switch to VB.NET, and it would never affect anything, because the compiler is compiling the actual file, not your Visual Display within your ActiveEditor that was created.

How would it help?

We could potentially store MetaData within the Code Tree, that would be excluded from viewing, although kept in the file. Your language choice and the code could still be generated as you are used to it. (think code-behind, where the sub document is the base language, which you can show/hide).
This new MetaData, would then actively describe the code so that Code Generation tools and the Editor can manipulate it for context, refactoring and other.


The next big thing? Coming to Visual Studio 10? is it too late ?

Imagine your Visual View of the code had toggle switches, to show/hide comments, show/hide regions, show/hide methods, show/hide classes - it would still be in the actual file, but not in your Visual Display. In the same way, I could switch my Visual Display to VB.NET to edit something, and then switch it to c# to edit something else.
Each developer on the team can view and edit in the language of their choice, it would not matter.
If a team of two was using vb.net, and then 3 more developer were brought on the team, they could continue in the same project in their own language, and it would not change anything.

Tags: vs.net, codegen, editors

"A revolution for editing code in .NET"

One of the most common Code Generation tools involve databases and are called O/R Mappers. This is going to change with the likes of OSLO and DSL's. But historically, Object-Relational Mappers have been the predominant force in CodeGen and they are usually CRUD based. (create, read, update delete) They come in various flavors and I have not used one before now that I still use today. That is, I could never find one that gives me enough freedom to design and implement my project the way I need to, and very quickly I leave them behind. Most have limitations, and don't actually do what it says on the tin.

For example, more than most try to sell you the idea, that it removes the database from you, you can talk to it via the objects, however, I have never found one, that I have not had to go “under-the-hood” to modify a Stored procedure or some aspect of the generated code. So if you do choose to use an O/R mapper, you must be sure, that you can make changes deeper down in the generated code. CodeGen is not good enough yet, to be a black-box tool

But thats one flavor of CodeGen. Other flavors involve Wrappers, Code Snippets, Designer Tools, and general utilities that can generate entire projects and/or layers and everything in between. This post, I would like to concentrate on Visual Studio .NET Code snippets.
Visual Studio.NET Code Snippets currently have a few problems. No editing tool, no built-in way of designing snippets easily. It is one way. It injects the snippet into the Editor and when done, forgets everything about the Expressions. The Refactoring Engine and the Snippet are not friends. They do not communicate.

Code Snippets

Lisa Feigenbaum - Code Snippets in Visual Studio
Ken Levy takes his camcorder over to interview Lisa Feigenbaum and get a look at the new Code Snippets feature in Visual Studio.

Code Snippets Solution applied to all code files, LIVE

A Code Snippet should not “lose” knowledge of the parameters/expressions. Anytime, I click on an Expression (example: PropertyName) that was inserted with a Code Snippet or NOT, it should still understand it. Refactoring would be automatic. Why should it be two separate tasks? Have you ever changed a Property Name, without wanting to change where its referenced?

Consider adding the “prop” Code Snippet. It asks you for Field and PropertyName. Now I believe that this is “kind-of” there for Visual Studio 2010.

But the key missing ingredient, is having our code “always aware”, especially of “expressions”. If you click on a Field it should highlight and as you make the rename change, it should alter your references automatically.

But a Code Snippet is only a small utility, but I wanted to use it as a small example of how code snippets need to keep context and knowledge of its injection, and in the same way Code generation in general has to be able to do this too.

If you generate a class for my person table in a database, and I change the class name, it should, by means of Code Snippet Expressions, Refactoring Engine, understand and align the change across to the database and the the code that references it.

Tags: code snippets, vs.net