T
Tom
Posted in comp.lang.misc but I've put it here too on the basis that Inq
is written in Java, so might be of interest....
There are a large number of applications whose purpose is to accept data,
transform it, move it somewhere else and show it to users. For systems
of this type I came to the conclusion that OO implementations are more
of a hindrance than a help. Data processing applications do not need
the complexity they introduce. At the outset there are entities and
relationships, yes those old things. But we attempt to graft on class
designs and then invent all sorts of ways to match the impedance. Why?
Still, those early stages just seduce us - the real fun comes in the
maintenance phase. Then you realise that those inheritance hierarchies
you came up with no longer really hold so you spend time "refactoring",
a nice word to keep your users at bay while you rewrite stuff.
The less well you can understand a problem, the less control you have
over it and the more volatile it turns out to be, the worse OO is at
addressing it. While class designs and OO languages have many useful
features I found that they only really work at an API level (things
like GUI libraries, message handling or what you will). However these
are artefacts, not "real world" problems. One size does not fit all.
Then comes integrating all those "vertical" APIs. There are XML generating
and processing libraries, database and messaging transactions, GUI
building technologies, client/server, notifications, caching, concurrency,
data and application distribution, report generation - please add any
I have missed - and did you ever ask yourself - when does a configuration
file become a bad programming language? Ok, so you have survived all
that, then there is building and deployment to consider - dependency
tools to manage all those libraries.
As someone who has spent a long time developing bespoke applications I
got very bored repeating essentially the the same task. There are only
so many row mappers and MVC dispatchers one can write. The goal is - all
those common services but without the need to bridge them to your
application time over; to streamline or eliminate the build and
deployment process; a simple and maintainable programming paradigm.
So what to do?
If you have ever thought "this interface is getting messy - I'm just
going to pass a map and let the other end work it out" then you have
taken the first step in the computer industry's definition
of "reification" (see Wikipedia page). Reification is actually
common - it happens every time you call your application server container,
for example - but how far can you go with this idea? Unhappy with the
status quo, that is what we asked ourselves when embarking on producing
our own commercial applications. Having worked on a lot of projects that
were unnecessarily bloated and compromised because of their history,
we didn't want our own to go the same way.
What we came up with was the Inq platform. Inq operates at a number of
levels. It is a procedural language, has a type system that incorporates the
entity life-cycle, retains metadata for its own use in GUI and report
building and offers client and server environments. By reifying types,
references and executable elements Inq is able to take over all the tasks
that otherwise require coding effort but which do not contribute to the
application itself. In this way, the code that is developed almost
exclusively only addresses the application problem. Any that does not
sees a high degree of reuse. Implementing the application in a different
language to that of the infrastructure APIs prevents one from polluting
the other.
Having developed Inq for our own use, we hope it might be of interest to
the wider community. Inq is open-source - downloads and more information
are available at http://www.inqwell.com and of course your comments are
welcome here.
Thanks
is written in Java, so might be of interest....
There are a large number of applications whose purpose is to accept data,
transform it, move it somewhere else and show it to users. For systems
of this type I came to the conclusion that OO implementations are more
of a hindrance than a help. Data processing applications do not need
the complexity they introduce. At the outset there are entities and
relationships, yes those old things. But we attempt to graft on class
designs and then invent all sorts of ways to match the impedance. Why?
Still, those early stages just seduce us - the real fun comes in the
maintenance phase. Then you realise that those inheritance hierarchies
you came up with no longer really hold so you spend time "refactoring",
a nice word to keep your users at bay while you rewrite stuff.
The less well you can understand a problem, the less control you have
over it and the more volatile it turns out to be, the worse OO is at
addressing it. While class designs and OO languages have many useful
features I found that they only really work at an API level (things
like GUI libraries, message handling or what you will). However these
are artefacts, not "real world" problems. One size does not fit all.
Then comes integrating all those "vertical" APIs. There are XML generating
and processing libraries, database and messaging transactions, GUI
building technologies, client/server, notifications, caching, concurrency,
data and application distribution, report generation - please add any
I have missed - and did you ever ask yourself - when does a configuration
file become a bad programming language? Ok, so you have survived all
that, then there is building and deployment to consider - dependency
tools to manage all those libraries.
As someone who has spent a long time developing bespoke applications I
got very bored repeating essentially the the same task. There are only
so many row mappers and MVC dispatchers one can write. The goal is - all
those common services but without the need to bridge them to your
application time over; to streamline or eliminate the build and
deployment process; a simple and maintainable programming paradigm.
So what to do?
If you have ever thought "this interface is getting messy - I'm just
going to pass a map and let the other end work it out" then you have
taken the first step in the computer industry's definition
of "reification" (see Wikipedia page). Reification is actually
common - it happens every time you call your application server container,
for example - but how far can you go with this idea? Unhappy with the
status quo, that is what we asked ourselves when embarking on producing
our own commercial applications. Having worked on a lot of projects that
were unnecessarily bloated and compromised because of their history,
we didn't want our own to go the same way.
What we came up with was the Inq platform. Inq operates at a number of
levels. It is a procedural language, has a type system that incorporates the
entity life-cycle, retains metadata for its own use in GUI and report
building and offers client and server environments. By reifying types,
references and executable elements Inq is able to take over all the tasks
that otherwise require coding effort but which do not contribute to the
application itself. In this way, the code that is developed almost
exclusively only addresses the application problem. Any that does not
sees a high degree of reuse. Implementing the application in a different
language to that of the infrastructure APIs prevents one from polluting
the other.
Having developed Inq for our own use, we hope it might be of interest to
the wider community. Inq is open-source - downloads and more information
are available at http://www.inqwell.com and of course your comments are
welcome here.
Thanks