1/19/2011 8:07:08 AM #

This is an easy one, because it's already been happening for the past ten years: what was once called DHTML by Microsoft, and nowadays encapsulated in the term HTML 5.

Barry Kelly |

1/19/2011 8:28:53 AM #

I imagine the next layer is going to be pulling some layers off. After layers like .NET you get into all kinds of other layers which give you great functionality but the layers use specific frameworks and technologies that can actually be limiting. For example, take ASP.NET web forms vs ASP.NET MVC. Web developers wanted more control and a cleaner/testable way to write web applications. ASP.NET web forms was set in its awkward state-dependent ways, so the .NET community has essentially torn that layer off and is now using a framework that is lighter and essentially stateless because it has adapted to the problems discovered on previous, more complex layers.

Another example is the IIS layer of .NET. An essential yet complex layer of .NET designed to serve up web applications. I look for this to go away very soon. You can see the signs already. It's developer nature to pinpoint headaches in the process and look for ways to improve it. Developers have pinpointed IIS as being cumbersome. Microsoft has even recently build IIS Express which is a lightweight full featured replacement that can be dropped onto a server. My prediction is to look further and see that IIS will go away. Look for projects like the .NET HTTP Abstractions (groups.google.com/group/net-http-abstractions) to take over and provide us a way to deploy application without the complexity we know today.

The point is, all those layers were there to solve a problem. Problems that developers were tired of dealing with. To find the "next big thing" you simply need to fix what bothers you about your process.

STEVEN HOOK |

1/19/2011 9:02:29 AM #

I agree with Steve. It seems like the people making waves in their respective communities are looking to simplify and remove the layers. In some ways, I'd like to think it's because people are becoming less afraid of the lower level coding.

Node.js is a great example (http://nodejs.org/). The web server snippet on the main page demonstrates the simplicity. Under the covers it's just handling that network event, and responding with a callback.

It also looks like environments will be shifting to a composition model, as in the Rack world. Rack is an interface between the web servers and applications, providing means for middleware. The OWIN spec (which came out of the .NET Http Abstractions group Steve linked to) is the .NET effort in that area.

We might also attribute this kind of progress to more modern programming language features. Things like anonymous callbacks and closures make that model of programming much easier to understand and be productive with.

John Nelson |

1/19/2011 11:09:51 AM #

And, of course, the OS is running on a hypervisor, not on the metal. Your app may shift from one physical machine to another without even knowing it.

Craig Stuntz |

1/19/2011 12:08:55 PM #

As I see it, been layers a way to encapsulate complexity, over the VCL or .Net layer there is a business layer that takes several forms, some of them add several new layers to the model while others are used side by side (aka Frameworks like ORM among others).

This business layer is domain-specific and is something that i would love to see in Delphi: a way to define a domain-specific logic/language. I'm aware that we could use something like:
  MyBusinessObject.
    AddParam(x).
    AddParam(y).
    Save;

(I still not used it but looks great)
But something like user-defined LINQ also would be nice

Daniel Luyo |

1/19/2011 12:10:14 PM #

BTW new RTL attributes, can also help this way

Daniel Luyo |

1/19/2011 12:28:49 PM #

The (not immediate) next layer will be intentional software and domain specific languages.

We often use similar patterns, optimizations, relations, etc. and still have no real way to express them generically. There is always some kind of specialization and tailoring to the specific problem at hand. (yes there are generics in programming languages, but I am speaking of higher levels).

That requires you to deal with low level details (low level compared to the actual problem to solve) instead of letting you focus on the domain problem.
I.e. it is hard to express the real intent and not merely implementation artifacts.
As soon as requirements change the implementation details make it hard to adapt the code, i.e. you have to undo the specialization to make it generic, then tailor it again to the new requirements.

As code grows based on specific requirements you cannot completely forsee the future and even if, it's too laborious too plan for every possible extension and make it totally flexible, pluggable and extendable.

That means you also would need tools that help you to turn a specific implementation into a more generic one. Ideally it would just put the different pieces together and make sure they consort well with each other.

In future you will tag code portions with attributes (similar to [attribute] syntax in .NET) to further specify intent. Like what properties the code has to allow the compiler to better optimize it (more knowledge, more constraints => more safe choices => more potential for optimizations). Other tagging could help to verify the software and point out contradictory requirements or false assertions statically.

That is in the long run, writing code will be like having a conversation between experts, where one of them is the computer. The computer will point out issues, suggest possible solutions, use AI to learn patterns and recognize them, and provide tools to make it easier to reorganize models and thoughts. I.e. more assistive technology on the domain specific level.

The challenge is finding a language that is intuitive to use and express intent, allows you to use higher level concepts to describe it, like you do in normal conversations, too. We need to get away from pure logic-description of problems but rather be more fuzzy about it, and let the computer help us clear up the details, contradiction, point out assumption, incomplete modeling, etc.

Programming will be very interactive, with AI guiding supporting us.

Before that, I think DSLs and less ambitious forms of intent based programming will catch on. (see "domain workbench" for example or JML the Java modeling language that allows to specify constraints and invariants, think of it as stronger type checking, to assert all is playing together as expected).

Very promising (but too laborious currently, especially JML)!

Maël Hörz |

1/19/2011 2:56:38 PM #

Some of your "additional layers" aren't actually additional.

You mention Java and .NET as additional layers after introducing VCL and MFC, but .NET and Java are alternatives to those layers not additional too (additional in the sense that they simultaneously exist in this reality, but not in the sense that they form part of the stack of layers).

Similarly you include assembler in the stack of layers, but there is no assembler "layer".  There may be an assembler "step" in the generation of the binary code from the final layer that sits atop the hardware, but even that isn't always the case is it (do all compilers generate assembler code to hand off to an assembler for the final stage of code gen) ?


As for your final question... I would put it stlightly different... rather than wondering what layers might we see appearing on top, I'd ask what layers would be *useful* to have appearing.

VCL/MFC etc are essentially just the latest refinements of older layers:  OWL begat the VCL (and indeed arguably the VCL begat .NET Framework)

Even Java/.NET were not really this great revolution.

Years before Java and .NET you could develop cross platform applications using tools such as Omnis for Windows, and any other number of 4GL's.

Those products failed to take the software development industry over.  I wonder what we think has changed in the industry or the market place that means that any new attempt will be any more successful ?

Jolyon Smith |

1/19/2011 3:43:12 PM #

I'm sorry, but your core premise is wrong, so the question is meaningless. The operating system isn't layered on an assembler. There's nothing "layered" on physical switches. The Windows API isn't a "layer on top of Windows" - it IS Windows, as far as the programmer is concerned. The rest of Windows is a bunch of utility programs for managing files and applications.

What is true is that the VCL is a layer on top of the Windows API, and a compiler is a layer on top of the raw machine language (like an assembler is). But dot net, while mostly implemented as a layer on top of the Win API, doesn't actually NEED to be a "layer". As originally envisioned, I believe it was supposed to be a PARALLEL API, in pure managed code, eventually replacing the aging (and frankly, badly designed) WIN32 API.  

Dot net is also a layer between the processor and compiler, but that's a completely separate thing than the dot net framework's layering over the API.

Bottom line - the real question isn't how many more layers of stuff we're going to wedge between programmers and the hardware - it's the question of how future operating systems and programming languages are going to improve their ability to hide complexity and simplify development. Looking at this as another "layer" forces you to think in terms of "translation" between what we want and what we have, rather than looking at completely new approaches.

Steve Summers |

1/19/2011 5:11:33 PM #

As the previous topic pointed out, I think that Java/.Net etc. did not bring that of an overhead, anyway the services that make life easier are here for some time that will give some overhead:
- dynamic languages (but they start to get traction as they do get "enough" speed). JS is around 10x slower than optimized C++, it will get just 3-4x I think in two extra years (because Mozilla already proposed "annotated types" and may become a standard, as is there in ActionScript). Ruby have also a JIT, Lua too. So at large I just think that a dynamic language with a decent JIT in it will get over for medium desktop applications.
- not using bit optimized formats: we tend today to use XML, sometimes over SOAP, and so on, that I think those are the biggest speed losers: disk accesses are 100x slower than memory that is slower 30-40 times than what enters in cache. So a small Java code may perform reasonably well if enters in CPU cache. So applications I think will try to reduce disk accesses but will store "fatter files". As is memory for free, disk space also becomes for free (I've bought some time ago 2 TB with a bit more than 100 euros)
- indirect drawing of controls, etc. NeXT/OS X (with PostScript/PDF drawing model), remade in Vista and Linux. Probably control abstractions will become the norm, so most applications will be just hooks using JS (Gnome Shell, Qt Quick/QML)
- OpenCL/LLVM: to get the very last drop of performance. Those are the replacement of assembly as far as I see
- Cloud: the new disk, I think will become the slowest from chain

Ciprian Mustiata |

1/19/2011 6:13:55 PM #

I think you're focusing on the wrong idea. It's not the layers that make programming easier. It's the abstractions they provide. The reason there are so many layers is that a single abstraction is never adequate.

Take the stream abstraction as an example. There is a lot of merit in treating data as a stream but for some cases it hides too many details so you bypass it and manipulate data by copying it into and out of a buffer. In other cases a stream doesn't hide enough so you move up and use a data set or something at an even higher level.

We build layer upon layer of abstractions so we have the choice of how deep down the rabbit hole we want to go. This allows us to focus on driving to our destination rather than building the engine.

So the real question is how close are we getting to problem domain? I think we still have room for more levels. When we get to the point where someone says "I want my computer to do *this*" and a programmer does a single action to make it happen, then I think we'll have exhausted the need for any further layers.

codeelegance |

1/20/2011 10:02:53 PM #

For software development, Domain Specific Modeling will be the next layer on top of all current layers we see today.

Domain experts create a domain model and the resultant code either machine code or other (say javascript etc) gets generated directly from that domain model.

ie from domain model we go directly to the final application in one step.

Kashif |

1/19/2011 8:26:15 AM #

Pingback from topsy.com

Twitter Trackbacks for
        
        Nick Hodges | What is the Next Layer?
        [nickhodges.com]
        on Topsy.com

topsy.com |