Boaz Rosenan's HomepageMy name is Boaz Rosenan, a Computer Science graduate student at the Open University of Israel, and a software professional for over twelve years.
I've been working in the software industry for over ten years, out of which the last five have been in GE-Healthcare. Before that I worked in some other industries, including the cellular content industry and the semiconductor equipment industry. Regardless of my place of employment and the nature of the software we developed, the problem was always the same: Software tends to be too complex for what it does, and with time becomes harder and harder to control. This was my motivation to look solutions to this problem, both short-term solutions within my places of employment, and long term solutions on my spare time.
As I went on with this hunt, it became more and more clear to me that the problem lies with the programming languages we use. Regardless of whether we're writing software for a web-application, a medical device or a mission-critical on-board computer for an airliner, the vast majority of the code is probably written in an object-oriented, imperative, general-purpose programming language (such as C++ or Java). This means that the maintainability of the software depends on how well the problem domain can be mapped into the terms of the language, being classes, objects and algorithms. Most effort in the field of software engineering is spent in this direction with artifacts such as object-oriented design. However, it doesn't matter how hard we try, some problems just don't map well into OOP. This is where we use patterns and recipes, but this only makes the problem worse. We have duplicated logic all over the code, requiring that the reader will recognize the pattern in order to understand the intention behind it.
At first I was an OOP/D enthusiast. A colleague once described me as a machine to which you feed a problem description on one end and get a class diagram off the other. However, as time passed I started looking at this problem differently. Instead of trying to map the problem into the terms of the programming language (which is assumed to be given), why don't we use a programming language that speaks the terms of the problem? The common answer for that was availability. It is unlikely to find a language for our problem domain waiting somewhere. So what? If the language does not exist, we'll create it. How hard can that be... Without knowing that, with this understanding I stepped into the realm of Domain Specific Languages (DSLs) and a newer concept: Language Oriented Programming (LOP).
I spent several years (in my spare time) searching for the "silver bullet", a platform that will make it easy enough to define and use DSLs and thus make LOP a practical choice. Along the years I came across the work of others who had the same motivation and created their own platforms (such as MetaEdit+ and JetBrains' MPS. This work inspired me with refreshing ideas I combined with my own.
In the last few years I've been working around a single concept, which I have implemented under the name Cedalion. I have a prototype for Cedalion which I'm developing as part of my thesis.
I spend as much time as I can developing the Cedalion open-source project. Currently, this project is considred at "pre alpha" status, that is, it can be treated as a proof of concept, but not for actual work. I hope to change this, one step at a time, addressing Cedalion's limitations and providing a language that can benefit others.
Research InterestsProgramming languages, especially Domain Specific Languages, Language Workbenches, type systems and logic programming.
Academic AdvisorDavid H. Lorenz