Frequently Asked Questions
- 1. How did you come up with Inq?
- 2. What's The Development Environment?
- 3. You Don't Like OO - Why Is That?
- 4. You talk about "Constant Change" but surely you just need to nail down the user requirements as early on as possible?
- 5. How come you didn't use well-known frameworks like Java EJB, Spring or any others?
- 6. What's the difference between Inq and typical languages like Java/C++?
- 7. Is Inq a Domain-Specific Language?
- 8. You seem to have concentrated on desktop clients - why is that and does Inq also support web clients?
- 9. How big is the Inq runtime jarfile?
- 10. How do I integrate other java libraries to Inq?
- 11. How do I connect to JMS queues with XML messages?
- 12. Aren't scripted languages slower then Java?
- 13. How do you make an Inq application scale for many users and/or more data?
- 14. Who has used Inq so far?
- 15. Why should I use Inq instead of Spring etc?
- 16. Is the Inq language extendable?
- 17. Do You Have an IDE or a Debugger?
- 18. What are your future plans for Inq?
- 19. Do you provide consultancy for Inq?
1. How did you come up with Inq?
An interesting question with a complicated answer. Inq is made up of three things:
- The Inq language;
- The underlying Java framework;
- The years of utter frustration in building/supporting complex software systems, thinking that there must be a better way.
Frustration: The driver of Change?
We've worked with financial systems for many years, the majority of the time in Front Office. These environments are extremely challenging: loosely specified requirements, a strong need to deliver systems quickly yet the ability to factor in unknown future requirements which could leave you with some immensely tough implementation choices. And we haven't even touched how often people change their minds when it comes to the GUI. In a nutshell, we strongly feel that the modern IT environment is one of constant change.
We wanted to be in a position where when our users asked for something, we'd have the confidence - in our abilities and software tools - to say "Yes, no problem!". Not being able to do this is quite frankly, frustrating!
The vast majority of banking systems are pretty much the same in that they shuffle data from one end of the organisation to another - doing some creating, modifying, aggregating etc. along the way. They all have some combination of: database(s), transactions, events, messaging, background processes, multiple users doing lots of stuff and interactive front-end GUIs with validation and work-flow. They integrate with other systems both upstream and downstream. It is only the business logic and GUI presentation which varies.
We decided to create a software framework which captured these common elements and lets you easily design and code up the final business specific part. It's the classic 80/20 rule.
The framework would be a tool which we wanted to use for ourselves. Back in the early 1990's we were writing in C++/Motif using David Flanagan's xmt Toolkit for front-end GUIs. At the time the Design Pattens book (by Gang of Four) and other Object-Oriented methodologies were becoming mainstream. We started writing an OO framework in C++ using Doug Schmidt's ACE toolkit. When Java came out we saw that the JVM offered a lot of the ACE features out-of-the-box. In fact there is Java ACE (JACE) which is but a small fraction of ACE. Like many other developers we soon dumped C++ for Java - sorry Bjarne ;-) One problem we hit early on was that even though at the time we were big fans of OO, we realised quickly that in an OO framework, it is almost impossible to prevent framework classes intruding into the application classes. We needed a way to specify application objects in a "framework-agnostic" way. We looked into Java Beans and the Java Reflection API but we were rapidly coming to a conclusion that OO was giving us more problems then benefits. This led us into the realms of metadata and opaque objects, which is just a small step away from a typeless, object-based environment. A few years later we came to realise this was called a prototype environment, where others had already done a good deal of work, for example the Self language and runtime environment.
So we wrote a Java framework from the ground-up which allows you to specify and build typeless, opaque prototypical application objects. The framework can then manipulate these objects for it's own purposes such as persistence, caching and triggering events without you having to worry about it.
The Inq Language
Now that we had our framework we started using it in earnest. We realised that our Java applications were simply instantiating and wiring up objects. At the time IBM's Alphaworks team released its Bean Markup Language, BML. BML is an XML document which when run by the BML parser, used the Java Class Loader and Reflection API to instantiate objects and call methods to wire them up. We liked the fact that we didn't have to go through the hassle of editing, compiling, testing and deploying java classes and jars. Just modify the BML and re-run. Except, BML is just not attractive to developers. It is basic and lacks expressiveness, so we created our own richly defined Inq XML dialect, used XSLT to convert Inq-XML to BML and then ran that through the BML parser. It worked but it was a huge can of worms! XSLT is nice and powerful but, like shots of Sambuca, too much too often and life becomes blur. Furthermore, because the end object-structure within the application was the same, the applications still ran just as fast but all that XSLT processing and BML parsing did not make for speedy launch times.
It was a no-brainer to conclude we needed our own language. As fans of lex and yacc, we used JavaCC to help create our own language where the keywords and semantics map on to the underlying framework functionality yet maintain a high level of expression without being terse. Doing this allowed us to have a language which focuses on that final 20% - the business logic and end-user GUI presentation. We don't waste time (say) on how an object is kept in sync between server and client process, the underlying framework does that for us.
A very neat yet significant natural step of this effort was the Inq runtime environment. The Inq runtime can run standalone humming away burning a few CPU cycles. It does nothing until you stream in some Inq script, at which point it becomes "alive" with your application - be it server-side or client-side GUIs. And that's not all, you can change the application logic, while it is still running...safely.
What Inq means for us is that when we write an application we can spend far more time thinking about the application business logic and front-end GUI design. This is because we know we can confidently build it, deploy it and most importantly of all, change it quickly - whenever we want.
2. What's The Development Environment?
Pretty frugal at the moment. Any decent text editor perhaps with syntax highlighting (eg UltraEdit), MySQL and its jdbc driver for the database, Glass Fish for the message broker and source code control of your choice. And that's it!
Lately we've created "general" projects in Eclipse, just for its file organisation, searching and so forth.
3. You Don't Like OO - Why Is That?
The underlying java code which supports Inq makes good use of OO techniques. It is very easy to spot design patterns like Composite, Visitor, Prototype, Flyweight, Builder, Strategy and so forth. The framework functionality is well-defined, stable and extensible. It is easy to write code for this situation using any OO language because we own the problem domain 100%. But outside in application-land, life is not quite so simple.
The typical scenario is that someone (a designer) has to come up with a class model which is reusable and adaptable to future need. What we've noticed is that the base classes at the top of a class-model are too generic and the child classes at the bottom are a bit too specific - neither case brings about huge amounts of re-use. The classes in the middle are reusable but only up to a point. The class-model is based on the designer's OO experience and their understanding of the business requirements now and the foreseeable future. The quality of these requirements are dependent on the end-user having a very good idea of what they want and their ability to communicate these requirements to the designer. All of this makes the task of Object-Oriented modelling......subjective! An alternative view of the class-model is that it is just a snapshot of the designer's understanding for that moment in time. If you took five different designers you could end up with five different class-models. If you got them all into a room you'd have some heated debates but the end result would be the same. All of this means that at some point (eg when requirements are miscommunicated or they change in subtle ways) the class-model has to be looked at again. Either some hard choices have to made to implement some awkward solution or the model needs to be refactored. Adding new code is low risk, deleting existing code is also fairly manageable, but changing existing working tested code is a major career-breaking decision. Refactoring a class-model requires extensive care.
Much later when we came across Object-based languages we briefly dipped our toes into Philosophy. We're not experts so please take the following with a pinch of salt! Object-oriented analysis and design is very similar to Classification Theory ie the formation of taxonomies as used by Aristotle and Plato. We were surprised to read that modern day philosophers have something better than Classification Theory. So what was the new thinking? Prototype Theory - see Eleanor Rosch, Lakoff and Wittgenstein. You can read more about Prototype-based languages yourself.
In a nutshell, we feel that although OO class-models are re-usable, they themselves are not resilient to change.
4. You talk about "Constant Change" but surely you just need to nail down the user requirements as early on as possible?
Let's be clear, of course, nailing requirements is important. The key point is that requirements are subjective, open to miscommunication or misunderstanding and liable to change. Imagine software development is like a bunch of soldiers marching on-foot across a bog-ridden moor. The Major-General barks an order giving you a rough idea of your destination. Off you trudge trying to make sure you have the right equipment, you avoid the mines, ditches and that everyone on the team are motivated and headed in the right direction (where's the map?).
After you get on to this death-march, imagine if your destination changes, and keeps changing. Like, huh? You would be quite right to be upset. Now imagine you're given an fast zippy All Terrain Vehicle. Will you now care so much if your destination changes? More then likely you will welcome the change, it gives you the chance to skid around, show-off and kick up the dirt. Change is good but please note, Inq is not silver-bullet; you can always crash that ATV if you're not careful.
5. How come you didn't use well-known frameworks like Java EJB, Spring or any others?
Well, when we started on Inq there was no EJB or Spring etc. As mentioned elsewhere, these frameworks come with their own baggage. If we were building something like Inq today we would still probably do it all ourselves.
Add to that we decided to leave OO behind in the application world whereas these frameworks still operate in that space. They do not deliver on separation from the application, reduction of repetitive code and economy of expression, all goals we think Inq achieves well.
Lastly, we wanted to address both client and server. Those frameworks don't particularly address those two things together.
6. What's the difference between Inq and typical languages like Java/C++?
Languages like Java and C++ are all-purpose languages. They are designed for wide variety of uses. Inq is both a runtime environment and a language geared towards a certain type of problem-domain area.
Inq is a script which when executed at runtime instantiates and wires up your application. Inq syntax is designed to look similar to Java/C/C++ but the number of language constructs is kept to a minimum in terms of typedefs and functions.
7. Is Inq a Domain-Specific Language?
We don't see it as such. With its built-in supoprt for persistence, transactions, concurrency, events and MVC it is aimed at making short work of typical data-processing applications (known in today's jargon as enterprise applications). However it can be used as a utility scripting language too.
Having said that there is a lot of interest in DSLs at the moment. Recently we came across this presentation by Peter Friese of Itemis, whose Xtext tool is aimed at supporting DSLs in Eclipse. We thought this slide and the one following it (roll the mouse over) summed up our philosophy rather well:
Slides (c) Peter Friese (http://www.peterfriese.de / @peterfriese)
8. You seem to have concentrated on desktop clients - why is that and does Inq also support web clients?
We have put a lot of effort into desktop applications for two reasons:
- that's what we wanted at the time and in particular we wanted the liveness desktop applications can support;
- we wanted to have desktop applications centrally managed like web applications already are.
However recently we have been working on making our applications available as both desktop and web clients. We're integrating Inq's ability to produce JSON with the qooxdoo framework. The same Inq server-side functionality can be used with both desktop and web clients.
We touch on this in the petstore example. We will be producing the web version of petstore soon.
9. How big is the Inq runtime jarfile?
Inq itself is something less than 3 Mbytes. Its dependencies are about the same. That is all you need for all server-side and client-side applications.
10. How do I integrate other java libraries to Inq?
You can call java code from Inq scripts. There are a number of cases covered in the examples directory on the distribution that use the Inq callmethod statement. More info on calling Inq from Java later.
11. How do I connect to JMS queues with XML messages?
Inq has built-in support for generating and parsing XML. These are used and discussed in the petstore blueprint application.
12. Aren't scripted languages slower then Java?
A broad question that can be looked at in at least the following ways:
- Inq is not interpreted continuously. When you run an Inq script, the Inq runtime creates (or recreates) framework objects and connects (or reconnects) them to each other safely. Once this is done, the objects within the Inq runtime are no different to any other typical Java application. We have worked on systems that do this using Java or XML for the wiring. The principle is the same but all expressiveness and readability is lost.
- The Inq language has reified many of the concepts current languages compile away (or implement in their VM) so that, for example, things like MVC are part of its runtime. This will have a straight-line execution cost but our experience is that this is only a minor factor. Much more time is spent on things like persistence I/O, data marshalling, events and client/server traffic. These are areas where Inq seeks to gain and we've concentrated on them a great deal in its implementation.
- Inq is a single small jar file where all the framework classes are heavily used. We're not JIT experts but we can only imagine that this situation is ideal for inline compiling by the Java Hotspot compiler. Most applications we have seen have a many jar files with a huge number of classes. We assume the Hotspot compiler may have its work cut out in these cases.
There are others who share our view on dynamic languages like Inq.
13. How do you make an Inq application scale for many users and/or more data?
A great question. At the moment, Inq operates with many clients connecting to a single server. With its concepts of transactions, locks and inter-process cooperation via events this works well. As intimated above, we think these ideas reduce the overall load on a server considerably and make the most efficient use of, say, available WAN bandwidth.
We do recognise that one size does not fit all and that there will inevitably be processing-intensive tasks that would require multiple servers. We have a plan (not least driven by the projects we are working on) - please stay tuned.
14. Who has used Inq so far?
Well, we've used Inq extensively ourselves to build a high-performance real-time trading system to manage Contract for Difference and Equity Swap Financial products also known as Synthetics. You can read more at www.xylinq.com.
15. Why should I use Inq instead of Spring etc?
Here are a few reasons...
- An Inq application generates a fraction of the amount of code. These things are difficult to quantify sensibly so we are just going to suggest a (conservative) figure of 25%.
- The entities you define (your typedefs) carry no infrastructure baggage, nor any specific relationships amongst them. This means they are immediately useable elsewhere. You will find you do not repeat yourself when pushing your data into new "problem domain" areas.
- There is very little "boiler plate" code to write. What you do produce is wholly concerned with your solution. You get there quicker.
- Because of Inq's simplicity and the separation its runtime provides from common services, your application is easy to extend and maintain.
- Your code stands a much greater chance of reuse. With Inq it is possible to use existing code in applications that have not even been developed yet. The Item Choser and Attribute Editor are examples of this. In our applications we have code that manages date-ranged typedefs in a common way (ask if you want further details).
- Inq leverages your typedef's meta data by making it available to its GUI and reporting functionality. Just by defining your entities alone you have already achieved significant progress.
16. Is the Inq language extendable?
Preserving the semantics of Inq is important to us so we don't permit commits to its source. If you have an idea then feel free to get in touch or post on the forums.
17. Do You Have an IDE or a Debugger?
Sadly not yet... we had a look at Xtext but haven't the time to pursue that further at the moment.
18. What are your future plans for Inq?
The future plans for Inq will most likely be driven by how it is used. Until now, these drivers have come from Xylinq and ourselves. We hope others will come from our peers.
On our To-Do list we have:-
- Inq server farms / peer-to-peer networks
- Further integration with such things as Benjamin Sigg's Docking Frames.
- Completion of the browser-fronted version of petstore
19. Do you provide consultancy for Inq?
Yes. We'd be very happy to teach you how to use Inq, help you start off an Inq project on the right footing and even code it for you too. Feel free to contact us here.