Language Oriented Programming
I’ve been reading this article on Language Oriented Programming: the next programming paradigm.
Current problems
The article first describes current problems. One of the biggest problems I think is, as said in the article, that developers can clearly explain to eachother in a matter of minutes, what needs to be build. But building the actual program requires much, much more time. This is the translation from our thoughts into the ‘words’ or commands of the computer. Once the program has been build, and you (or another developer) tries to understand what is going on after a couple of months, you have to make the translation again, and reverse engineer the program from those computer ‘words’ into your own head. For this we have comments, documentation, uml models and much more, but you’d have to study a fair amount of time to understand what is going on.
What the article doesn’t describe (because it’s out of scope) but what frustrates me most of the time, is that there still is no way that from client to developer there is a good way of communication. You’ve probably all seen the pictures of the swing, where client, developer, management, sales, everyone describes the problem differently. The two final pictures are of what the client finally gets and what the client actually wanted. Every picture is totally different.
I think the biggest problem is communication. Probably everyone agrees, but why don’t people do something about it? We’ve got RUP, which creates many, many documents and a lot of overhead, and it might work some better, but most of the time I still see this fail miserably. Clients can’t specifiy their problem or need, the analist can’t get that information from the client either, and most of the time they can’t describe it either. For example, write a Windows forms based functional document, when we’re building a web application.
DSL
Anyway, back to the article. Sergey Dmitriev describes his Domain Specific Languages (DSL) which, in best, should be a graphical representation of a language, completely build for a specific domain. This can be database or gui related, but can also be a language build for finance related stuff, or a more specific part of finanance. It’s very interesting to read what they’ve done with PMS already.
Years ago, people talked about the future, where we’d have some sort of building blocks. We could tie them all together and have a complete application, completely (or at least almost) without any customization by the ‘developer’. I think this is never really possible. But with DSL, it’s a bit different, but probably doable.
But there might be other problems as well. For example, integration is a hot topic currently and lots of (old) systems must be integrated and connected with eachother. A visitor asks the question on how all these languages will integrate, as multiple languages will be needed to build one program. And as not all languages will be build by the same vendor or company, this might be a big issue which must be tackled before we can start building DSLs.
Anyway, the future will bring us a lot of new goodies. I just hope there’s enough work for developers. The final result might be that only a few real developers build languages, where those developers must have a deep knowledge of the domain they built the language for. In result, a small department can built programs on those languages and don’t need to have a deep understanding of development, like you currently need to build applications.
A topic however I’m going to be reading some more about.
Dennis is an independent consultant and software architect who loves building distributed systems and the challenges they bring. What he learns he tries to share via numerous articles, blogposts, presentations and workshops.
Sounds good, gonna read this one….
Indeed interesting this is (afterall we will have to get in the mood again…)
Yes RUP has a LOT of overhead. Luckily, not everything is needed on all projects. Personally I like the way they explain iterated development. Very understandable for *most* educated people.
The difficulties you are writing about in communication are problems that will never go away. That is why iterated development is such a winner! Specs will never be complete. I don’t really believe in much more efficient methodoligies. It would be much better if documentation will be more integrated in the the design and developent life-cycle. Like the tools that Rational provides but with more (automated) flow control and review cycles. When I update or add code in a source tree the item should be marked for documentation update or vice versa together with ‘must update’ deadlines that will automatically be reported to team/projectmanagers.
Indeed current and future project are much about integration just as the webservice hype was and still is.
I don’t believe in BIG architectures for HUGE integration projects. Never seen one being very efficient or flexible. Just compare it to an airport. Much planes (data) from different companies (vendors) and different sources (applications) that all have to work together in the same airport (company). This will never be one big system.. it wouldn’t work.. and if it could work the costs would be too high.
Small systems, which are up-to-date and that only have lifecycles for max. 4 years and have very good documentated and interoperable interfaces are key elements in software developement that I believe in. Just as software developers in europe.. will our fate be the same as the dinosours because of offshore development? No.. because we aren’t dinosaurs:) we are intelligent and this MUST result in high quality (with a software development environment like above) and efficiënt systems that can be build quick (with copyrighted, licensed highly extendable buildingblocks that need high educated employees) and comply with current interoperable standards.
Strange how I manage to write about RUP and end with comparing dinosaurs with our job….
It’s interesting that you mention off-shoring. I think that some technology like LOP will help to reduce off-shoring because it will reduce the amount of simple ‘implementation’ (i.e. drudgery) that must be done. The design will much more naturally be expressed in code in DSLs, so work will remain creative, and we will ‘off-shore’ a lot of the drudgery to the computer rather than some other country. Many programmers who now do more-or-less boring implementation tasks will be freed up to do much more valuable and creative high-level design tasks (which will still be programming; the source code is the design).
In your second sentence I believe you say that the ‘simple implementation’ is done off-shore. Later you say the this will be gone and we’ll do much more design, which will be our new code.
But I don’t believe off-shoring is based on us not wanting to do that boring implementation work! 😉
I think, in the end, the designing you mention, can also be done off-shore, meaning there will only be work left for a small percentage of developers. Like building the DSLs.
The point I think I can agree on with Ramon is the BIG frameworks he’s referring to. I once (or twice) heard another developer say that currently a lot of people are developing the framework for the framework, not for any application. Once the application is supposed to be developed, we’ve got a LOT of overhead. Optimizations can also be a little tricky, because of the overhead in the framework. Maybe rewrite some, maybe take out some.
Also the iterative about RUP should be great, as it is a great solution to all miss-communication. But still, the projects I work on, do all iterations without any communication between people, teams and client(s). 🙂
@Rob:
Yes generating code based on designs is crucial for future software development. These that we create better maintainable software. The power of the architect usually results in multiple layers of abstraction within code. A lot of these pieces can be generated. In the past we didn’t have these abstraction layers thus only typing a piece of code once. These days you do it once in some kind of generator or modelling tool to generate all that code. I think it takes about the same time to do either one. Biggest mistakes our sector made was to do all that abstraction stuff by hand.
But code generation and frameworks have one very big disadvantage and that is that you must follow the rules of the creators. The biggest advantage here? Very maintainable code and high quality code. Which just graduated developers can even read and alter. The biggest disadvantage is that userinterfaces aren’t made with the (real) end-users in mind. That is why real-time prototyping with end-users is still one of my favorite parts of my job. This just cannot be generated because it will lose flexibility. And IF it can be generated with the framework it has that many parameters and options to create as Dennis stated a framework for the framework.
That is why I don’t like BIG software designs. I like code generation though. Don’t get me wrong! But my vision is small very well designed optimized solutions wih VERY good standardized interfaces. This solutions could contain generated code or even ‘spaghetti’ to just get the job done fast but with high quality interfacing in mind. Which could be communicating to other systems of with the user in some sort of graphical of textual form.
I believe in stitching too with automated ways of communicating between systems. But not in the big picture as in one big software design that contains ALL corparate data, dataflows, storage, interfacing, transactions, etcetera..
Again.. just like a normal company hierarchy would be. The CEO really doesn’t know all what is going on below in the hierarchy… If managers report that their division is doing ok that they will probably be ok (the interface). Small divisions are much more flexible and better suited for their kind of work within the company or with corperate relations. This is the way I see software development succeed in the future.
@Dennis:
Yes communication must be done properly, often and without too much hassle. I once had a project where EVERYONE attended one meeting a week. Developers, architects, end-users, projectmanagers. Really.. everyone. It was great for the team spirit. Everyone had the feeling that they were important and that they would be heard if they had a good suggestion. Biggert hurdle was that this was becoming reality!! I still compare it with a big group of women that are deciding which dry-cleaner is best 🙂
I want to remind you that this is strictly MY vision and not that of my employer 🙂
RUP is Cap-only and as other mentioned, not everything is needed. It creates overhead but keeps the project on the right track (if done the right way).
Communication and time-boxing are the most important parts of a succesful project.