dingfeng_quek

It's now DrRacket. DrRacket is pretty much like emacs with only 1 configuration. I use it a lot

If clarity was one of the design goals, the author should have included the 2x2 matrix. Sometimes, the best opinions aren't those that corrects our wrongly-held beliefs, but those that don't create them, which is much more silent.

Typing adds constraints - the type must be represented by and implemented in a particular type system. A trivial anti-modular constraint is that interacting modules must all use the same type system. The type system matters too - in Java, choosing from easily implementable types can easily add a lot to the complexity of the data structure, leading to a complex interface (in a more expressive type system, less of this happens).

More trivially, adding types IS adding constraints that are verifiable at compile time.

If compile-time verification of that sort is not essential (or not desired, which is the more general form of not essential), then the constraints are non-essential (or not desired).

---

Whether you choose to

1. Choose a particular data-structure and implement both modules to pass and receive that data-structure.

2. Specify an interface: The interface requires the data-structure to have certain properties (e.g. some methods work on them). The modules then build to the interface.

3. Specify that an adaptor exist to convert the data-structure to whatever the module requires.

is a somewhat different issue, although the kind of type system used does affect the implementation complexity and effort required.

It is easy to agree that there MUST be essential dependencies between modules in a system designed separated in a certain way. (Ignoring some philo arguments on identity, separation and reference point...)

The issue is whether the interfacing technique adds in non-essential coupling. A technique that has at least the constraints of another technique will also have trivially have at least the non-essential coupling of the other technique.

Types add constraints, thus increasing coupling (and decreasing modularity).

Although types have benefits. And direct modularity is seldom the only concern. I.e. Correctness and reliability also enhances modularity in an indirect way - an erroneous module definitely decreases modularity.

The presentation on the site doesn't do the language and its design justice, so I'll fill in a bit here.

Qi is a programming language with a "powerful" static type system, which can be useful. Other generally usable languages with "powerful" static typing include Haskell and Ocaml. Some people want "powerful" static typing. If you are one of those, then like me, you should be interested in Qi.

Qi has been implemented in Common Lisp. Qi code is translated into Lisp code, and Qi code can also call Lisp code - there is interoperability. If you code in Lisp or intend to do so, you can use Qi as well, and still reuse existing code and functionality.

However, few people use Common Lisp. Some of the most popular platforms do not support Common Lisp.

Shen is intended to be the next evolution of Qi; Shen is a "redesign" of Qi to reduce the effort required to implement Qi on a language. The idea is to implement Shen on popular languages, like Javascript, Python, etc.

There are three notable benefits that we can look forward to: 1. Single language across many platforms. 2. High-level language available on platforms, like the web browser, mobile devices, and so on. Haskell today doesn't run on mobile phones. 3. Qi/Shen is like a cleaned-up Lisp. Some people prefer that to languages like Javascript, to Dalvik Java, and so on.

What's pending is its implementation on the non-Lisp languages. Performance and reliability could be concerns, given the differences between its original host language, Lisp, and other languages. If the performance and correctness tests for these turn out well, there is good reason to be excited.

The release of Shen on Common Lisp is of lesser consequence. Qi already runs on Common Lisp. Releasing Shen (which is mostly a more "portable" Qi, but retaining the syntax and power) on CL just proves that Shen has been completed with nearly no errors.

Currently, there's a group working to implement it on Javascript, but they postponed the delivery to late October. Its success would be noteworthy.