Currently we have openings for a select few outstanding programmers. If you would like to work on a new breakthrough product that will transform how software is used and developed, this is your opportunity.
If you are bright, highly competent, willing to take risks and enjoy having fun working together in a team, you will fit right in. Your specific background, your number of years in the industry or the specific technologies you master are less important.
To learn more about Careers at Intentional Software Corporation, click here. And make sure to check out our recruting video!
does the product have an estimated RTM date?
I believe John McCarthy invented/discovered this in 1958.
http://en.wikipedia.org/wiki/Lisp_programming_language
How is this different?
Hello Anonymous,
but being close to the problem domain is the goal. So we need to be able to track the complexity of the domains as closely as we can – if we are more complex we get the harmful “superfluous degrees of freedom” and if we are less complex we will have to model the domain complexity with the implementation primitives and we will incur not only the conceptual costs of the inherent complexity but also the modeling overhead. This will show up in the program sources, and in run time debugging as a jumble of primitives instead of the underlying domain structures.”
Yes, we have an internal target release date. However, the most important factor controlling our release date is to ensure success with our early customers. With a technology as disruptive as ours, we have many things to learn about how to use it in real project before we release it more broadly.
On your second question regarding Lisp, we have discussed Lisp quite a bit on this blog, for example here, here and here. As we wrote in our earlier posts:
“Lisp is historically very important and intentional software is more similar to Lisp with Lisp macros than to any other of the well-known languages. But Lisp is over 40 years old now and it was born in very modest circumstances (the list primitives CAR and CDR stood for the contents of the address register and the decrement register of the IBM 704.) So Lisp used its data model for three purposes:
1. to represent the program – this is the heritage that Intentional primarily builds on.
2. to be the syntax for editing the program text
3. for the run-time environment
The unification of these concepts was and has remained very profound and placed Lisp way ahead in its application to difficult problems. However, today we enjoy more resources and face a greater variety of problems. For this reason, intentional software separates the notation from the representation (using editable projections of the program representation), and also separates the issues of the run time environment (using generative programming.)
This of course means that the system is much more complex than Lisp. But we feel that simplicity is not the ultimate goal (otherwise we would be all working on Turing Machines
And we summarized it with
“Lisp still, after more than 40 years, has a large and active user base which shows its excellence; an excellence we think should, and could, be made available to a broader audience.”
I hope this helps in answering your questions.
Traditional programming paradigm and programming languages especially non Object Oriented languages can never offer a “Silver Bullet”. I strongly believe and show that only “Loosely coupled” components can control software complexity.
Software is complex NOT because individual parts (e.g. Objects or modules) are complex. Most software parts are simple. Software is complex because, it is nearly impossible to comprehend interactions between all the parts. For example, it is nearly impossible to predict what sort of effect a small change in a part would have in other parts of the software.
The solution lies in building the software development paradigm using plug-n-play components. It requires little or almost no effort to remove each part, in order to replace it. Once removed, this part can be refined in complete isolation.
Since each part is small (e.g. about 500 lines of code), it is not complex to make changes. Then it requires almost no effort to plug-in the part, into the application. Automated tools may be employed to detect, if the changes cause any bugs in other parts of the application, which interact with the refined or replaced part.
I know, you are thinking: Dream on, this never going to happen.
I have created numerous working examples to prove that it is in fact possible. If you can prove me wrong or find any flaw, I may be interested in working for you. I spend several years to create and validate all the processes.
http://www.cbsdf.com/technologies/misc-docs/Dependencies-OOP-Vs-LC_Parts.htm
I think, a real solution lies in minimizing the dependencies between various parts and especially the dependencies must be readily identifiable. I think, we can theoretically define the least dependency each part must need. Today the dependencies between the parts are probably about 10 to 100 times.
The complexity of the software is directly proportional to the dependencies of all the parts. Any invention that does not allow continuous refinement with least possible effort can never be an Ideal solution to the software development. Hence least dependencies is the only solution.
I greatly appreciate if you can find any flaw in our processes. I have spent more than a year just to make sure that there is no flaw. I will send my resume, if you can find a flaw.
I think, one of the beigest aspects that can control software complexity is “dependencies” between various “parts” in the software application.
It is extremely important that each “part” must have least possible dependency, so that, it requires least effort to remove it. So that it can be refined in full isolation and reintegrate it back in the application. Also, the dependencies must be readily identifiable. For example, if a “part” has dependency of just five-lines of code, what is the use, if it takes forever to locate the five-lines?
Mr. Christerson, I agree with most of your post. But, I think “dependencies” is yet another dimension, which must be addressed. Unfortunately, I have yet to find a consorted research effort that addresses this most important aspect.
This is continuation of my earlier post:
http://blog.intentionalsoftware.com/intentional_software/2006/04/we_are_hiring.html#comment-24216619
What do you think?