Inq: New Scripting Language & Execution Environment for Java
Inq (www.inqwell.com) is a more than just a language - it's an application server and GUI environment for rapid development of distributed applications.
In recent years enterprise frameworks have come and come again. There has been much discussion of their benefits and promise of code reuse. As a developer I never saw much of this mythical reuse. I generally found myself implementing the same boiler plate code of database adapters and GUI table models over and over again.
I have generally worked in environments where feature creep would be a luxury - most often requirements are poorly specified and incomplete and the landscape subject to change by new regulations or client demand. Such is the world of the finance industry and yet systems have to be produced. When the world changes how does your design stand up? Do you throw it all away and start again or make-do-and-mend? How long will it take? How much will it cost?
IT departments attempt to mitigate the high cost of change by imposing strict requirements definition and a formal project process. But is that good enough? Does it actually solve the problems or just brush them under the carpet? When the chips are down the user is king and if making them conform to the methodology won't work what do you do? Answer - come up with a new methodology (or is it an old one?)
Inq is a new scripting language written in Java. It's a dynamic language that uses a node space and simple eval-based functions to model the real world. Node structures are built to order so relationships can be loose and allowed to evolve.
But Inq is also an execution environment for client and server. Its key features are:
- Server-side atomic transactions and automatic instance locks
- Complete insulation from SQL with full database implemention independence
- Caching of database result sets
- Events as transactions create, modify and destroy application type instances
- A process architecture with conditional monitors for simpler concurrency handling
- Easily laid-out GUIs with automatic binding of views to models
Inq is free to use. We developed it because we got bored and wanted to put the fun back into programming.
You are invited to learn more at www.inqwell.com
- Login or register to post comments
- 3326 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)










Comments
Denis Robert replied on Wed, 2008/11/05 - 6:08pm
It's not going to go anywhere as long as it's closed-source. Period.
OtengiM replied on Wed, 2008/11/05 - 8:07pm
OtengiM replied on Wed, 2008/11/05 - 8:11pm
Also what GUI's?, Swing is already deprecated, what a dumb idea of Sun to kill the best multiplatform GUI framework.
So how I could easily laid-out GUIs with automatic binding of views to models? if there is not gui anymore, Javafx sucks.
Java is done for the client side, period.
partyzant replied on Thu, 2008/11/06 - 2:19am
in response to: drobert_bfm
[quote=drobert_bfm]It's not going to go anywhere as long as it's closed-source. Period. [/quote]
After all, to achieve success, you need to be open source. Just like Java has always been. Or C#. Oh well.
Raphael Miranda replied on Thu, 2008/11/06 - 6:39am
in response to: partyzant
Java is(almost) 100% open-source, and Even Microsoft has been actively supporting Mono. They haven't always been but the fact is they are now.
At this day and age that you have to integrate entire universes written in different languages, yes, openness is a necessity for success.
Jacek replied on Thu, 2008/11/06 - 7:40am
in response to: OtengiM
OtengiM, stop spewing what you read on someone else's blog last night.
Java UI development is just fine...not necessarily breathtaking, but just fine and gets the job done in a productive and reliable way.
And unlike the .Net world, you don't have to rewrite it every 2-3 years when MS throws a whole new API at you and tells you the old one is now deprecated.
partyzant replied on Thu, 2008/11/06 - 9:49am
in response to: xymor
[quote=xymor]Java is(almost) 100% open-source, and Even Microsoft has been actively supporting Mono. They haven't always been but the fact is they are now. [/quote]
C# is nowhere near open source, Mono is irrelevant. I doubt that even 1% of .NET deployments would be on Mono.
Java had long been the market leader before it was opensourced.
[quote]At this day and age that you have to integrate entire universes written in different languages, yes, openness is a necessity for success.[/quote]
No, it is not. Specification preciseness, accuracy and stability are necessary. You may be able to maintain those with an open source implementation, or you may not.
Raphael Miranda replied on Thu, 2008/11/06 - 11:48am
in response to: partyzant
I agree, but anyone who has dealed with several proprietary software vendors trying to integrate diverse solutions know that most of the time, finding a software that has all those qualities is almost impossible and even when those qualities are present there are hundreds of obstacles, sometimes even political stances get in the way.
With open-source in the worst case adapt the code to your needs, whatever that may be. That is a very powerful quality. Specification preciseness, accuracy and stability - for better or for worst, it's all in your hands to provide those things as opposed to relying on others to provide them.
partyzant replied on Thu, 2008/11/06 - 3:20pm
in response to: xymor
[quote=xymor]I agree, but anyone who has dealed with several proprietary software vendors trying to integrate diverse solutions know that most of the time, finding a software that has all those qualities is almost impossible[/quote]
The same for open source projects.
However if you look only for mature and maintained projects, it gets easier. No matter whether the project is proprietary or opensource. I think that more proprietary projects reach maturity than open source ones, but when already mature they probably all do have those qualities. To some extent, at least. It must be verified anyway.
Bugs do happen in both worlds, but I believe that more opensource projects are developed using the CADT model than proprietary ones.
[quote]With open-source in the worst case adapt the code to your needs, whatever that may be. That is a very powerful quality. Specification preciseness, accuracy and stability - for better or for worst, it's all in your hands to provide those things as opposed to relying on others to provide them.[/quote]
No, it's a myth, plain and simple.
Yes, that's what opensource advocates say, but starting a private fork of an opensource project means covering the costs of further source tree maintenance, at the very least. This may be acceptable for giant companies like Google but in the rest of the world, the world of tight budgets and lesser companies that don't have the perpetuum mobile profit generator Google has, it simply is not an option. For a single component it may seem a good solution, but a real project often uses more than 30 foreign components, now think about taking just ten components into own maintenance.
Depending on the size of the problem, it often pays better to work around the bugs or get rid of the component in question and write just the necessary bits in house. While it probably means that the budget will be exceeded, there's a better chance of avoiding a total disaster. The "opensource way" of "You can DIY" works only for trivial bugs in trivial projects.
I'm not telling not to touch the opensource. Some opensource software houses, like ASF, are more responsible and stable than many commercial companies, it's probably safe to depend on most of the components they provide. Taking some new shiny component from a company noone ever heard of or from a happy CADT bunch, that is asking for trouble.
If you're responsible for a project with a budget and a deadline, you have to be responsible about the dependencies as well and this means that you probably should choose only mature components that come from good, reputable software houses, opensource or proprietary, and never rely on whatever bullshit ESR wrote, to bail you out should you make the wrong choice.
newton_dave replied on Fri, 2008/11/07 - 9:02am
in response to: OtengiM
*What's* a fad? New languages? Most of the stuff we use now was a new language once--somebody's pet project.
Features that go in to your "non-fad" languages often come from the "fad" languages--who do you think did generics in Java? Where do you think most of the functional stuff in C# came from?
newton_dave replied on Fri, 2008/11/07 - 9:04am
in response to: Jacek
OtengiM, stop spewing what you read on someone else's blog last night.
[/quote]
But... then teh intarnet would stop.
hookfi replied on Sun, 2009/05/31 - 7:52am
angela1981 replied on Fri, 2009/07/17 - 9:20pm