Inq: Language and Reified Execution Environment
Tom
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
John B. Matthews
<47c0c73d-898f-492c...@glegroupsg2000goo.googlegroups.com
>,
Tom <tom...@gmail.com> wrote:
> 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.
Is there any prospect for making the version controlled source
available through a publicly accessible repository such as
<https://sourceforge.net/> or <http://code.google.com/>?
"The Inq team have made some additions to JCalendar," prompts one to
ask: Which JCalendar? Would a qualified name or link be helpful?
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Lew
> Tom wrote:
>> 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
>> welcome here.
> Is there any prospect for making the version controlled source
> available through a publicly accessible repository such as
> <https://sourceforge.net/> or <http://code.google.com/>?
>
> "The Inq team have made some additions to JCalendar," prompts one to
> ask: Which JCalendar? Would a qualified name or link be helpful?
Perhaps http://www.jcalendar.net/?
--
Lew
What, you took me seriously? Your fault.
Tom
Regarding JCalendar - that would be Kai Toedter's JCalendar (there is a link in the download page). I've spoken with him prior to making the mods/fixes we wanted and sent them to him...
Lew
> We do have a github account but haven't got round to using it yet. Or sourceforge, don't really mind. Just one more thing to do...
>
> Regarding JCalendar - that would be Kai Toedter's JCalendar (there is a link in the download page). I've spoken with him prior to making the mods/fixes we wanted and sent them to him...
Please do not use that stupid Google Groups posting style that destroys Usenet
threads. Use the style that does not destroy the threads, or use a real
newsreader, please.
No one will take you seriously if you cannot post to Usenet properly. Respect
the headers!
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
John B. Matthews
wrote:
> John B. Matthews wrote:
> > Tom wrote:
> >> 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.
>
> > Is there any prospect for making the version controlled source
> > available through a publicly accessible repository such as
> > <https://sourceforge.net/> or <http://code.google.com/>?
> >
> > "The Inq team have made some additions to JCalendar," prompts one
> > to ask: Which JCalendar? Would a qualified name or link be helpful?
>
> Perhaps http://www.jcalendar.net/?
Or perhaps com.toedter.calendar.JCalendar: <http://www.toedter.com/>.
The former appears to be proprietary and suffers a few broken links.
The latter is LGPL, but the posted API is a bit dated. It proved easy
to use, but the layout is over-constrained, with disappointing result
on com.apple.laf.AquaLookAndFeel. I may have to poke around at those
"additions" to see.
John B. Matthews
wrote:
> On 05/25/2011 08:57 AM, Tom wrote:
> > We do have a github account but haven't got round to using it yet.
> > Or sourceforge, don't really mind. Just one more thing to do...
> >
> > Regarding JCalendar - that would be Kai Toedter's JCalendar (there
> > is a link in the download page). I've spoken with him prior to
> > making the mods/fixes we wanted and sent them to him...
Ah, I see it now; it might be worth repeating it near the bottom, too.
> Please do not use that stupid Google Groups posting style that
> destroys Usenet threads. Use the style that does not destroy the
> threads, or use a real newsreader, please.
>
> No one will take you seriously if you cannot post to Usenet properly.
> Respect the headers!
Yes, please. I also responded in the original thread.
Tom
>
> Please do not use that stupid Google Groups posting style that destroys
> Usenet threads. Use the style that does not destroy the threads, or use
> a real newsreader, please.
>
> No one will take you seriously if you cannot post to Usenet properly.
> Respect the headers!
Yes, sorry about that. Not sure I've posted to Usenet since the days of rn
under ultrix (ok not quite that long ago...).
Please consider thread closed.
Lawrence D'Oliveiro
<47c0c73d-898f-492c...@glegroupsg2000goo.googlegroups.com>,
Tom wrote:
> There are a large number of applications whose purpose is to accept data,
> transform it, move it somewhere else and show it to users.
That’s what Perl was developed for.
Lawrence D'Oliveiro
<7087c7ee-e2d7-4cd3...@glegroupsg2000goo.googlegroups.com>,
Tom wrote:
> We do have a github account but haven't got round to using it yet. Or
> sourceforge, don't really mind.
Whatever site you use, make sure you put it into a distributed VCS. GitHub
is purely Git-based, which will do fine. SourceForge offers a variety of
VCSes, including I believe both the major distributed ones, Mercurial and
Git.
Lew
> Tom wrote:
>
>> There are a large number of applications whose purpose is to accept data,
>> transform it, move it somewhere else and show it to users.
> That’s what Perl was developed for.
That's what EVERY computer language was developed for, so your statement is
trivially true, Lawrence.