Saturday, February 5, 2011

Attumi (email Batch D) - A Java-like Language with default immutability

This is the fifth in a series of 5 posts:

This is the final post showing the self-email-chain I wrote in response to my creative brainstorm started in 2010/November regarding my designing a "What's next?" language to follow Java.

Here is the fourth and final batch notes, mostly unedited:

<BATCH_D>
  1. make sure that interfaces provide extendable/configurable factories for implementations based on general performance requirements (as opposed to encoding them in a particular implementation strategy available at the time the code was written) - this will enable better and deeper implementations to be written, thereby elevating the available performance without code recompiles - it will also allow better self-tracking resources which can replace their implementations with better strategies through accumulated metrics (perhaps with secondary thread "watchers" who keep the metrics costs away from the primary code pathway)
  2. facilitate collections code mapping to support a SQL query style syntax (should work very efficiently with immutable object trees) - thought based on this FLOSS extension for Java: http://josql.sourceforge.net/index.html
  3. vastly reduce the cost of composition to reduce the desire to use inheritance - consider having a class able to implement an interface and also specify the internal reference to a class to which all non-reimplemented methods will be forwarded (UnassignedReferenceException thrown if method forwarding attempted and instance has not assigned the internal reference)
  4. move equals() and hasCode() out of Object and into an interface - logically groups the functionality so that if one is reimplemented, so is the other - do not implement at Object...do like Eiffel and have as independent implementation which can be specialized/extended via inheritance or interface/composition
  5. consider adding Iterable interface by which is optimized for use in for() loops
  6. provide tuples (temporary grouping of values without methods without having to formally define a class, i.e. a temporary struct) for both arguments into a method (like Java's varargs) and as a return value - should minimize amount of boilerplate "temp" code required to implement simple composition and re-implementation classes and methods
  7. default to NotNullable for all declarations and require Null be explicitly requested/defined
  8. default to methods NOT being overridable (must explicitly identify method as being overridden)
  9. can allow decendants to extend (don't have to make final) immutable classes as the immutable guarantee holds
  10. when determining requirements for collection type, use these characteristics: A) identity duplicates allowed (==), B) value duplicates allowed (.equals), C) value similarity allowed (Comparator), D) iterator ordered (Comparable.compareTo()), E) immutibility, F) degree in which to favor speed (of specific operations) versus space (weak and/or lazily instantiated context) - use a builder with these parameters to return appropriate implementation to specific interface - enable plug-in replacements at Builder itself (for replacement implementations)
  11. in specialized file for enhancing execution optimization logic, allow alternative lower level optimization (perhaps even assembly) where the context of the assumptions outlining the use of the alternative code would be asserted and it would only call the alternative if the assumptions were true
  12. consider all potential sources of side-effect randomness and attempt to eliminate to allow perfect deterministic models to be written without accidental side-effects (ex: Java HashSet/HashMap.keySet() and the multi-threaded GC interaction resulting from the default implementation of hashcode being an interpretation of the instance's memory location - use in thread Random)
  13. Research Google's Go as a possible influencer on direction of design : http://golang.org/doc/go_faq.html
  14. Good Java concurrency subtlety article (influence how operators are grouped - increase domain of atomicity - or explicitly disallow the syntax - i.e. assume immutable and multi-threaded throughout the entire language - create "safe zones for mutation" and for "thread communication"): http://www.ibm.com/developerworks/java/library/j-concurrencybugpatterns/index.html
  15. Nice coverage of using inheritance in OO versus delgates in functional languages (need to facilitate both) using Clojure: http://www.ibm.com/developerworks/java/library/j-clojure-protocols/index.html
</BATCH_D>

As I said with batches A, B and C, depending upon interest, I will consider diving into some/all of these and exploring my thoughts and reasoning.

2 comments:

  1. I made my way through the entire group of batches today - I think you have some interesting ideas. Some of them strike me as things I have seen in other existing languages ( SQL like syntax, for instance, as well as temp "tuple" returns are found in C# already with Linq... which ROCKS ).

    I look forward to talking a little more about this with you!

    ReplyDelete
  2. Bill,

    I am discovering that little bits of what I thought are available in lots of different places. I just had not found something that had them in such a high concentration as I did upon investigating Scala. And as I have dug deeper and deeper into Scala, I am finding even more alignments and parallels. It's great fun.

    Tonight, I posted my first entry in a series exploring Conway's life. I am looking forward to playing in this area over the next couple of months and enjoying learning and applying techniques in Scala.

    ReplyDelete