By Dave, on October 28th, 2010
I just finished up reading “The Design of Design” by Fred Brookes JR (author of the Mythical Man Month):
This book is a reflection on the design process itself and, in particular, what good designers are made of. Overall, I feel surprisingly positive about it, and basically enjoyed it. Reading between . . . → Read More: The Design of Design
By Dave, on October 25th, 2010
Whiley adopts the Actor model of concurrency, instead of the traditional multi-threading approach used in e.g. Java. The actor model is simple and easy to use, and is less likely to result in complex race conditions or deadlocks. The Actor Model has been around for a while, but Erlang has recently brought it into . . . → Read More: Implementing Actors on the JVM
By Dave, on October 18th, 2010
Like Python, Whiley uses indentation syntax instead of curly braces for delimiting blocks. When I started using indentation syntax with Python, I was pretty skeptical, but it grew on me fast and now I really like it. However, this wasn’t the only reason I chose to use indentation syntax in Whiley. The other is . . . → Read More: Indentation Syntax in Whiley
By Dave, on October 11th, 2010
One of the next big issues needing to be addressed is the syntax for function and method pointers. The syntax I’m thinking of is close to that used in C and C++ (see e.g. here and here). My initial idea results in something like this:
define MyComparator as { int compareTo(MyRecord,MyRecord) }
This is . . . → Read More: Function Pointer Syntax for Whiley
By Dave, on October 5th, 2010
An interesting issue has arisen as a result of my recent decision to move away from a declared-type model. The issue is essentially about scope resolution of fields and local variables. For example, consider the following:
define MyProc as process { int f } void MyProc::m(int x): f = x
Now, m(int) is a . . . → Read More: Field Resolution in Whiley
By Dave, on October 4th, 2010
An interesting problem I’ve encountered many times in Java is that of conflicting names. For example, suppose I have the following code:
import wyil.lang.*; import wyil.lang.Type.*; … public static Type T_Bool = new Type.Bool();
This is all well and good. The problem arises when I want to import another class called Type from some . . . → Read More: Better Namespaces
Popular Posts