From Java To Scala: immutability

Showing posts with label immutability. Show all posts

Sunday, February 26, 2012

A core principle behind functional programming...

I just stumbled upon a Wiki link on twitter about "Persistent data structure". After reading it, I think this is one of the essential implementation points behind any functional programming language, including Scala. Now, I just have to figure out how to think like this for myself as I design and implement my own programs. I'm learning so much as I get deeper and deeper into Scala and functional programming.

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>

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)
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
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)
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
consider adding Iterable interface by which is optimized for use in for() loops
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
default to NotNullable for all declarations and require Null be explicitly requested/defined
default to methods NOT being overridable (must explicitly identify method as being overridden)
can allow decendants to extend (don't have to make final) immutable classes as the immutable guarantee holds
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)
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
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)
Research Google's Go as a possible influencer on direction of design : http://golang.org/doc/go_faq.html
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
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.

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

This is the fourth in a series of 5 posts:

This is the next 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 third batch (of four) notes, mostly unedited:

<BATCH_C>

define notion of an init-once, read many method (for lazy initialization) to clear overhead of check for initialization every time method called
default of transparency (everything is public) and hidden state must be specifically called out
check out http://fantom.org/ for their approach to multi-threading (i.e. actor based with immutability)
allow passing parameter by name (while ensuring no speed gain/loss for using name as opposed to position - use stubbed API call point to map name to position
allow defaulting of unpassed parameters - when combined with parameter by name, vastly reduces boilerplate code for implementing class constructors
allow struct/tuple (multi-value) return instance so return from function can be multi-dimensional without formalization of class definition (temp class which will likely reify into real class later)
consider removing null entirely (force the meaning of empty, or undefined)
mature versions of modules, packages, access along with something like partial classes (develop requirements for information hiding versus deployment versus security)
promote aspect oriented programming (useful for logging/transactional separated from functional code) - consider it being useful for debugging (and during debugging, allow aspects to be explicitly skippable)
consider defining a "test" characteristic that when a class is defined as a test, it can have access to more private parts of a package/module so as to allow for exhaustive testing without impacting the design by forcing the package/module to expose things to the world just so testing can be complete
facilitate immutable pathing to enable soft/weak reference implementation - lazy instantiation pathway can be marked with degree of expense in regenerating so that how that reference is stored (more local to CPU all the way to some form of swapped network based storage) enabling a continuously changing set of options for memory locality - also enables regions to cycle through heating up (come closer to CPU) and then cooling down (push closer to network storage)

</BATCH_C>

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

Friday, February 4, 2011

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

This is the third in a series of 5 posts:

My last post, ...(email Batch A), explained the creative brainstorm started in 2010/November regarding my designing a "What's next?" language to follow Java. And I shared the first email covering my first batch of self-directed notes for exploring the things I would want to consider incorporating into a design.

Here is the second batch (of four) notes, mostly unedited:

<BATCH_B>

consider use of transactional memory model to handle concurrency (as opposed to lock based model), push distributed (Erlang-like) model into separate/library/framework
Source occurs as a named resource (name spaces are merely dot separated identifiers) and stored as ASTs (expressed both in platform independent binary as well as well formed Schema defined XML file) as opposed to the currently more common text file - enables ability to have text representation be human language independent (i.e can be represented in English, Chinese, etc.), allows personalized layout and indentation (avoiding entirely issues around syntax formatting flame-wars) and enables source to reside in a file, set of folders/files, different kinds of DB, over network streamed from undefined data source conforming to API (ex: Web-dav)
when defining reference, possible states {once-at-definition, *once-post-definition*, many} X {*no-null*, nullable} where * is default
when defining class, possible states {*immutable*, mutable} X {*not-derivable*, derivable} where * is default
enforce immutable by requiring all references be to immutables, i.e. if class is immutable, the semantics are guaranteed to be immutable all the way down through any references chains (will enforce acyclic graph, i.e. child cannot contain reference to parent or parent's parent, etc.) - must use external supplemental data structure to facilitate traversing child to parent relationships
execution start-up will pass "main()" a map of key/value pairs - which will be able to be represented as a simple property file/stream, XML file/stream, etc. will be completely generified to make code not care how the execution started and obtained the initial values
design ability for an immutable data structure to lazily fill in state without requiring all state to be completed in definition by the time the constructor terminates (may be challenging to prove from a code path perspective, if not careful)

</BATCH_B>

As I said with batch A, Depending upon interest, I will consider diving into some/all of these and exploring my thoughts and reasoning.

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

This is the second in a series of 5 posts:

Early last November (not December like I said in my "Why?" post), I had lots of things rolling around in my head about what to do "next" after Java. I wanted to complete my board game rules model in Java. I toyed with doing the UI. I was just not at all attracted to the tonnage of boilerplate required to do a Java UI with any tool. And I was already getting sick of Java boilerplate anyway even with all the help from the numerous tools Eclipse provides.

And it looked like Objective-C was just going to be tons more boilerplate, only I had to also learn and become competent in Objective-C and the IOS libraries, first. Not at all attractive, either. I had immersed myself in the C#/.NET books and was actually looking forward to some change and some new things (like LINQ, real properties, etc.) which put C# significantly less long in the tooth as Java (I know, I know, it's coming in Java 7, or 8...or whenever the hell Oracle says it will...eff Oracle).

I didn't plan the thought avalanche. I never do. They come to me completely unbidden. I already have several programming projects and business I wanted to start. And I had at least two business completely unrelated to technology (use, but are not driven by) I was playing with building. My creative juices were flowing in those other areas. And then on the way to work during my commute, it hit me like a lightening bolt in the form of a question...

"What if I was to modify Java until it's default state aligned with my primary use case pathways? What if I made Java immutable by default, and then made mutability a pain to get to and if used?"

What if being mutable had to be defined as "the unsafe side-effecting dangerous malicious memory leaked thread-deadlocking code is here" via copious annotations assisting the compiler (which would complain vociferously if the code writer were to forget the slightest "thar be dragon har" indications)? And that was just the start. Once I had the seed idea to take Java and shift it about until it suited me, I could then make it mean the removal of lots of boilerplate, re-prioritize things that mattered, rip out legacy crap (like raw collections) and then like. It was like a fantastic thought experiment all in my own private programmer's fairy-land.

I then began to privately email myself. Anytime I was coding on any project, home or work, I would just jot down some thoughts around the "pain point" and solution like notions that would come to me. That way, I would just continuously have the stream of thoughts and be able to adapt and play with them as needed. It was so much fun. I could now sit back and just enjoy writing Java code while my brain solved both the current coding problems the "Java" way and another part of my brain was off playing with how it really should work. And the modifications were all the way from very low level implementation efficiencies to very high level pattern extractions/abstractions.

So, what did those thoughts look like? Well, I was going to do tons of clean up on my notes and make them all spiffy. However, I would rather do more fun things like read more about Scala, and code in Scala, and make suggestions/requests to the Scala team around things that burped up for me during the last three months. I made all these notes before venturing out to start researching existing JVM alternatives. I had not investigated a single JVM language until AFTER I wrote all these notes. So, in a way, it was quite pleasant to have a strong sense of what I wanted before I actually took the leap and started researching other languages which might fill the bill. Besides, it's not my style. I like problem solving, even problems that have already been solved. It's why I love to play Go. It's why I do Sudoku, it's why I dig little puzzle games like Osmos and Chime.

Here is the first batch (of four) notes, mostly unedited:

<BATCH_A>

Consider an OO language design where immutability was the default:

immutability assumed unless otherwise explicitly called out and specified (use marker interface mutable in similar way abstract is used on abstract classes)
reduce security issues via content changing unexpectedly in deeper structures
create basic method parameter checks (i.e. simplified preconditions for null, ranged values, size, etc. - most all the pre-conditions typically used to validate basic parameters to a constructor)
use builders to have mutable content until ready to build immutable instance (like StringBuilder for strings, include ArrayBuilder for arrays)
all "primatives" are formal Objects and optimized internally for performance value (including arrays)
add option execution suggestion plan to help structure CPU and memory layout for optimally executing

can allow array of Integer to be grouped internally into a memory block of ints[] which are then accessed via pointer arithmetic
enables faster iterators where boundary checks can be disabled
separates the code abstraction definition (i.e. design) from the actual instruction and memory layout generation (i.e. implementation)

optimized relationship with Collections library (allowing for internal implementation to eliminate unnecessary boundary checks)
consider partial construction and lazy instantiation of additional immutable state as important (so as to only engage in CPU and memory for the execution pathways actually used)
ensure only an immutable instance may be passed from one thread to another (reduces memory coordination/collaboration/optimization issues substantially)
an immutable object is state whereas a mutable object has state
when designing Collection builders, ensure specification of requirements (i.e. read heavy, write heavy, etc.) which then interprets and selects implementation (i.e. ArrayList for lots of random access reading, LinkedList for lots of insertion and sequential traversing)
within implementation of actual compiled code, consider a reference to be more than just a memory pointer, but an actual object representing data

for an array of Integer, it could be type, count, size of single entry, pointer to start of a memory block
for a specific instance of Integer in the array, it could be type, container reference (above), index (and if immutable, the operation for this fetch only has to occur once to the locality needed to operate on it)

Review Java and Eiffel design for other possible ways to add semantics

</BATCH_A>

And that was the first brain-storm. Depending upon interest, I will consider diving into some/all of these and exploring my thoughts and reasoning. If there's no interest (and mine wanes such that I don't bring it up on the Scala mailing lists), it will just dissipate into the Internet ethers. I'm just glad to have had those thoughts pass through my head, get dumped out and can let them go. {smirk}