Wednesday, November 30, 2005
Shape Code After Language II
If you shape your code after language then you can read your code aloud, and what is easy to say, it is easy to code.
In the previous post I mentioned how code shaped after language could be hard for other developers to read, and how easy it was for users. It looked like there was almost an inverse relationship between developer skill and code understanding :-)
Seriously, I think that as developers we have got used to a contrived way of writing code. Sometimes we get confortable in our own ways, with the language crutches and patterns that we have built. We are so used to our way of doing things that we cannot even conceive there can be a better way. I have been watching the whole java vs ruby diatribe on The Server Side and it amazes me how much java programmers were defensive in their ways. When they looked at ruby they couldn't see simplicity, just a threatening difference. I must say that those strong reactions played not a little role in my switching over to ruby.
While reading the bizarre Why's Poignant Guide to Ruby, I stumbled on this passage from chapter 3:
When you decide to start focusing on the human-oriented semantics of the language, a strange thinks happen - you will see that you will start focusing more on what things you want rather than on how you want to do them. Initially you are likely to experience it as frustration. You will feel like you cannot say what you want in simple human terms. You will want to go back to code to get stuff done, rather than trying to find the right words to compose some prose.
If you manage to overcome this feeling, maybe just setting some time aside to try to do it as well as you can, you will see that the way you use human words is changing the shape of your code. If you want to be understood by humans you will tend to talk in terms of intents, of things that you want, without going much in detail about how to do them. These details can be sketched out later on if necessary by exploding chosen parts of the code.
Let me show you a simple example example: choose those houses that cost less than 200'000 euros from a text file
An instinctive approach could be something like:
Iteration I
choose_those_houses_that_cost_less_than_200000_euros_from_a_text_file
we say what we mean. we start from the intent and we express it via human language
Iteration II
choose_houses_that_cost_less_than_200000_from(a_text_file)
we removed the "those", which didn't add much to the intent, and we say that the text file is a variation point. we have also implicitly expressed the intent of being able to change file. Note that we haven't expressed the intent of changing the selection criteria.
Also, I'm playing at home here. I am not going to specify that I am dealing in euros.
Iteration III
choose_houses_that_cost_less_than 200000, from=a_text_file
I dropped the brackets on arguments since I have decided that I am going to do this in Ruby. I have also created another variation point for the selection threshold. The second parameter is prefixed by a 'from='. What am I doing there? Suppress your coding habits and just read it aloud skipping the punctuation: choose houses that cost less than 200000 from a text file
It can't get much cleare than this, can it? This is what I call prose - code transliteration without punctuation and symbols.
By the way, the 'from=' is a trick that consists in the implicit creation of the local variable 'from' before passing its value to the function. You could have also used a hashmap in Ruby. Something like: :from => a_text_file. That would have been more in the Ruby Way kind of style, but for today I want it my way.
Iteration IV
choose_houses_that_cost_less_than 200000, from_the=textfile("houses.txt")
reading it aloud: choose houses that cost less than 200000 from the text file "houses.txt"
I have added the possibility of specifying the file name. I have also accomodated the longer file specification, changing the sentence from
to
'from' has become 'from_the' for no other reason than it sounds better this way when close to its neighbourgs.
This intent could have also been specified as:
choose_houses_that_cost_less_than 200000, from_the_textfile="houses.txt"
but in this case I just took the opportunity to wrap up a bit of meaning (the concept of textfile) and keep it outside the function that I am calling. What is the return value of textfile("houses.txt") ? It could be the text of the file. It could be a File object. It could be a parsified collection of houses. Or maybe it's just a string.. maybe it's just returning the argument itself! Who cares? The overall meaning is clear. We are not refactoring code, we are doing intent refactoring here.
If you are relying on your hard won coding instincts this will drive you crazy. Just deep breathly and read the code aloud.
Iteration V
chosen_houses = houses_that_cost_less_than 200000, from_the=textfile("houses.txt")
puts chosen_houses
I have added the code to keep my selection into a variable and the code to print out this selection to screen.
Initially I wrote:
chosen_houses = choose_houses_that_cost_less_than 200000, from_the=textfile("houses.txt ")
but I din't like it. It must be due to the repetition of 'choose'. chosen equals to what we choose. It's not bad, but it's not great either. The language is still young and we can mould it to what appeases our ear. Generally speaking, when I find two similar words in a row (chosen and choose) I try to keep one and drop the other. In this case "chosen_houses" becomes simply "houses".
The call to the function "houses_that_cost_less_than" simply return houses. It returns what it states: houses.
When I print it out I use the ruby method "puts". I don't like it a lot. I would have rather used:
print chosen_houses
or
chosen_houses.display
but 'puts' is truly ubiquitous in Ruby and this time I felt that complying with the confortable habit of just typing those four easy letters was the more expressive thing to do.
Iteration VI
def houses_that_cost_less_than( a_threshold, houses)
houses.select { |house| house.price < a_threshold }
end
chosen_houses = houses_that_cost_less_than 200000, from_the=textfile("houses.txt")
puts chosen_houses
Now there is some meat! I have defined what I mean by that function, and I have said it in Ruby's own terms. We can't go much lower level than that. Fortunately Ruby is very legible, and this code is expressive even in its raw form. If I read it aloud it is: [from] houses select [an] house [when] house.price < a threshold
In a different language it would have been much less legible. When you read a chunk of code, it should convey its meaning - its intent - in seconds. If it doesn't it needs intent refactoring. A readable, easily digestible chunk of code, is called Stanza, just like the stanzas of a poem.
Note that by writing that code in such a way that it is expressing its intent in the simplest way, we have also implicitly taken a design decision. 'houses' is an enumerable object containing house elements that have a price.
Iteration VII
def houses_that_cost_less_than( a_threshold, houses)
houses.select { |house| house.price < a_threshold }
end
def houses_file(filepath)
File(filepath).readlines.collect { |line| house_from line }
end
chosen_houses = houses_that_cost_less_than 200000, from_the=houses_file("houses.txt")
puts chosen_houses
I have decided to make textfile("houses.txt") into houses_file("houses.txt") . I was pushed to do this by the decision of returning a set of houses. I wanted to make it slightly clearer without compromising the expressiveness of the code. This is another important trade-off. It's not like language-level syntax has no importance, it's just that it should come second after expressiveness. In this case this change also akes the intent clearer, by specifying that the file is a special kind of file, a house file.
We have also defined the insides of this function. Once again it was so simple to express it in ruby that it was pointless to detail it further: [from the] File [in] filepath read lines [and] collect [every] line [by getting an] house from [the] line
This is a bit more complex, but if you do Ruby it's clear at a glance. Note that I say File(filepath) and not File.new(filepath).
I don't like constructors. Constructors are for objects, not for people. And we don't want to see objects, we want to see intents. We want a File made from a filepath, we are not interested in creating objects. I don't need a "new", I just need to say that I want a File. When I read I don't want to see that File is an object that gets constructed there and the "new" just obscures the meaning. In Ruby it's pretty easy to define an implicit constructor so that the 'File(filepath)' syntax works without any problem
We have also defined a 'house_from' that is going to parse a line and produce a 'house' object.
Iteration VIII
def houses_that_cost_less_than( a_threshold, houses)
houses.select { |house| house.price < a_threshold }
end
def house_from(text)
city, address, price = text.split(",")
return House(city,address,price)
end
def houses_file(filepath)
File(filepath).readlines.collect { |line| house_from line }
end
chosen_houses = houses_that_cost_less_than 200000, from_the=houses_file("houses.txt")
puts chosen_houses
We have defined house_from where we split the text along commas and get the information that we use to define a 'House'. We could have done it all in a single operation:
return House *text.split(",")
but we would have lost the meaning of the fields extracted from the text line. House is another implicit constructor.
Iteration IX
class House
attr_accessor :city, :address, :price
def initialize(city, address, price)
@city=city; @address=address; @price=price
end
end
in this iteration we conclude by definining the House in simple terms.
In the previous post I mentioned how code shaped after language could be hard for other developers to read, and how easy it was for users. It looked like there was almost an inverse relationship between developer skill and code understanding :-)
Seriously, I think that as developers we have got used to a contrived way of writing code. Sometimes we get confortable in our own ways, with the language crutches and patterns that we have built. We are so used to our way of doing things that we cannot even conceive there can be a better way. I have been watching the whole java vs ruby diatribe on The Server Side and it amazes me how much java programmers were defensive in their ways. When they looked at ruby they couldn't see simplicity, just a threatening difference. I must say that those strong reactions played not a little role in my switching over to ruby.
While reading the bizarre Why's Poignant Guide to Ruby, I stumbled on this passage from chapter 3:
Read the following aloud to yourself.
Yep, do just as Why says: read the code aloud.
When you decide to start focusing on the human-oriented semantics of the language, a strange thinks happen - you will see that you will start focusing more on what things you want rather than on how you want to do them. Initially you are likely to experience it as frustration. You will feel like you cannot say what you want in simple human terms. You will want to go back to code to get stuff done, rather than trying to find the right words to compose some prose.
If you manage to overcome this feeling, maybe just setting some time aside to try to do it as well as you can, you will see that the way you use human words is changing the shape of your code. If you want to be understood by humans you will tend to talk in terms of intents, of things that you want, without going much in detail about how to do them. These details can be sketched out later on if necessary by exploding chosen parts of the code.
Let me show you a simple example example: choose those houses that cost less than 200'000 euros from a text file
An instinctive approach could be something like:
- open the file
- parse it line by line
- put houses data in a container
- loop on the container
- check for condition < 200'000
- if the condition is satisfied print out the names
Iteration I
choose_those_houses_that_cost_less_than_200000_euros_from_a_text_file
we say what we mean. we start from the intent and we express it via human language
Iteration II
choose_houses_that_cost_less_than_200000_from(a_text_file)
we removed the "those", which didn't add much to the intent, and we say that the text file is a variation point. we have also implicitly expressed the intent of being able to change file. Note that we haven't expressed the intent of changing the selection criteria.
Also, I'm playing at home here. I am not going to specify that I am dealing in euros.
Iteration III
choose_houses_that_cost_less_than 200000, from=a_text_file
I dropped the brackets on arguments since I have decided that I am going to do this in Ruby. I have also created another variation point for the selection threshold. The second parameter is prefixed by a 'from='. What am I doing there? Suppress your coding habits and just read it aloud skipping the punctuation: choose houses that cost less than 200000 from a text file
It can't get much cleare than this, can it? This is what I call prose - code transliteration without punctuation and symbols.
By the way, the 'from=' is a trick that consists in the implicit creation of the local variable 'from' before passing its value to the function. You could have also used a hashmap in Ruby. Something like: :from => a_text_file. That would have been more in the Ruby Way kind of style, but for today I want it my way.
Iteration IV
choose_houses_that_cost_less_than 200000, from_the=textfile("houses.txt")
reading it aloud: choose houses that cost less than 200000 from the text file "houses.txt"
I have added the possibility of specifying the file name. I have also accomodated the longer file specification, changing the sentence from
from=a_text_file
to
from_the=textfile("houses.txt")
'from' has become 'from_the' for no other reason than it sounds better this way when close to its neighbourgs.
This intent could have also been specified as:
choose_houses_that_cost_less_than 200000, from_the_textfile="houses.txt"
but in this case I just took the opportunity to wrap up a bit of meaning (the concept of textfile) and keep it outside the function that I am calling. What is the return value of textfile("houses.txt") ? It could be the text of the file. It could be a File object. It could be a parsified collection of houses. Or maybe it's just a string.. maybe it's just returning the argument itself! Who cares? The overall meaning is clear. We are not refactoring code, we are doing intent refactoring here.
If you are relying on your hard won coding instincts this will drive you crazy. Just deep breathly and read the code aloud.
Iteration V
chosen_houses = houses_that_cost_less_than 200000, from_the=textfile("houses.txt")
puts chosen_houses
I have added the code to keep my selection into a variable and the code to print out this selection to screen.
Initially I wrote:
chosen_houses = choose_houses_that_cost_less_than 200000, from_the=textfile("houses.txt ")
but I din't like it. It must be due to the repetition of 'choose'. chosen equals to what we choose. It's not bad, but it's not great either. The language is still young and we can mould it to what appeases our ear. Generally speaking, when I find two similar words in a row (chosen and choose) I try to keep one and drop the other. In this case "chosen_houses" becomes simply "houses".
The call to the function "houses_that_cost_less_than" simply return houses. It returns what it states: houses.
When I print it out I use the ruby method "puts". I don't like it a lot. I would have rather used:
print chosen_houses
or
chosen_houses.display
but 'puts' is truly ubiquitous in Ruby and this time I felt that complying with the confortable habit of just typing those four easy letters was the more expressive thing to do.
Iteration VI
def houses_that_cost_less_than( a_threshold, houses)
houses.select { |house| house.price < a_threshold }
end
chosen_houses = houses_that_cost_less_than 200000, from_the=textfile("houses.txt")
puts chosen_houses
Now there is some meat! I have defined what I mean by that function, and I have said it in Ruby's own terms. We can't go much lower level than that. Fortunately Ruby is very legible, and this code is expressive even in its raw form. If I read it aloud it is: [from] houses select [an] house [when] house.price < a threshold
In a different language it would have been much less legible. When you read a chunk of code, it should convey its meaning - its intent - in seconds. If it doesn't it needs intent refactoring. A readable, easily digestible chunk of code, is called Stanza, just like the stanzas of a poem.
Note that by writing that code in such a way that it is expressing its intent in the simplest way, we have also implicitly taken a design decision. 'houses' is an enumerable object containing house elements that have a price.
Iteration VII
def houses_that_cost_less_than( a_threshold, houses)
houses.select { |house| house.price < a_threshold }
end
def houses_file(filepath)
File(filepath).readlines.collect { |line| house_from line }
end
chosen_houses = houses_that_cost_less_than 200000, from_the=houses_file("houses.txt")
puts chosen_houses
I have decided to make textfile("houses.txt") into houses_file("houses.txt") . I was pushed to do this by the decision of returning a set of houses. I wanted to make it slightly clearer without compromising the expressiveness of the code. This is another important trade-off. It's not like language-level syntax has no importance, it's just that it should come second after expressiveness. In this case this change also akes the intent clearer, by specifying that the file is a special kind of file, a house file.
We have also defined the insides of this function. Once again it was so simple to express it in ruby that it was pointless to detail it further: [from the] File [in] filepath read lines [and] collect [every] line [by getting an] house from [the] line
This is a bit more complex, but if you do Ruby it's clear at a glance. Note that I say File(filepath) and not File.new(filepath).
I don't like constructors. Constructors are for objects, not for people. And we don't want to see objects, we want to see intents. We want a File made from a filepath, we are not interested in creating objects. I don't need a "new", I just need to say that I want a File. When I read I don't want to see that File is an object that gets constructed there and the "new" just obscures the meaning. In Ruby it's pretty easy to define an implicit constructor so that the 'File(filepath)' syntax works without any problem
We have also defined a 'house_from' that is going to parse a line and produce a 'house' object.
Iteration VIII
def houses_that_cost_less_than( a_threshold, houses)
houses.select { |house| house.price < a_threshold }
end
def house_from(text)
city, address, price = text.split(",")
return House(city,address,price)
end
def houses_file(filepath)
File(filepath).readlines.collect { |line| house_from line }
end
chosen_houses = houses_that_cost_less_than 200000, from_the=houses_file("houses.txt")
puts chosen_houses
We have defined house_from where we split the text along commas and get the information that we use to define a 'House'. We could have done it all in a single operation:
return House *text.split(",")
but we would have lost the meaning of the fields extracted from the text line. House is another implicit constructor.
Iteration IX
class House
attr_accessor :city, :address, :price
def initialize(city, address, price)
@city=city; @address=address; @price=price
end
end
in this iteration we conclude by definining the House in simple terms.
Saturday, November 26, 2005
Shape Code After Language
Shape code after language, or Shal if you need an acronym to remember it.
The idea of deriving design concepts from user vocabulary is not a new one.
Needless to say, I drank too much coffee, I started wearing black turtlenecks and I didn't get much done at all.
I developed a bad case of writer's block. On one hand I couldn't go back to 'just coding'. On the other hand the design hyperuranium was so full of possibilities that I just didn't know where to start from without tying myself up in conceptual knots.
Anyway, while I was floating in Plato's hyperuranium, somehow it occured to me to read the missing chapter. It is there that I found a simple powerful technique.
1. Write down what you understand about the domain in plain English.
2. Nouns should be classes
3. Verbs should be methods
These days I try to evolve my code by the motto: "If it's easy to say, it should be easy to code".
Now, the thing is that 99% of user requests are very simple and reasonable requests within the users' own model. If you can distill that model, you will be able to make them feel understood. And it's true: you will genuinely understand them!
Your software will have become a true nooartefact - an artefact encoding business knowledge in executable form. Much more than what we think of as being an application.
Evans had some very profound insights, yet I see people that have read the book asking questions like "should a Repository be implemented as a Singleton?", as if DDD is dealing with fixed patterns. I believe that Evans has opened a door on fantastic new possibilities, but most of the community is still fixated on the door frame and doesn't see that there is something beyond the threshold.
Then the unthinkable happened. I gave in to Vb.
I stopped trying to write java code in Vb and I just tried to do the simplest thing within the Vb language.
That was when I discovered Shal - Shape (code) After Language
Shal is a principle that I discovered over the years, while playing with different formats of coding and modelling. Shal is about allowing user language to drive your code production, not only on a modelling level, but as much on the micro-level as possible.
The idea of deriving design concepts from user vocabulary is not a new one.
I believe I read about it for the first time in what we have always called The Booch Book, but that you can find in bookstores as Object Oriented Analysis and Design. This book is definitely a classic, a must read for any developer. It is by reading the booch book that I came to realized that whenever I was writing code I was actually modelling. It was this insight thet started me focusing more and more on the design aspects of what I was doing.
After a while spent thinking about design I felt into the trap that these days is known as BDUF (Big Design Up Front). I started feeling that I couldn't even touch the keyboard until all the design elements were clear in my head. I was coding less and less and I kept haunting coffee bars where I spent hours scribbling and leaving behind a trail of napkins covered in cloud-shaped diagrams.
I remember that modelling felt like planning a platonic ideal world, later to be incarnated in code. The clouds would have opened showing the shining design behind them, as a beam of pure rational light would have moulded the humble software clay into an earthly embodiment of my model. The code was a mere detail.
I remember that modelling felt like planning a platonic ideal world, later to be incarnated in code. The clouds would have opened showing the shining design behind them, as a beam of pure rational light would have moulded the humble software clay into an earthly embodiment of my model. The code was a mere detail.
Needless to say, I drank too much coffee, I started wearing black turtlenecks and I didn't get much done at all.
I developed a bad case of writer's block. On one hand I couldn't go back to 'just coding'. On the other hand the design hyperuranium was so full of possibilities that I just didn't know where to start from without tying myself up in conceptual knots.
The booch book had put me in this situation, but it also helped me to break through it. You see, while reading the book for the first time I had skipped the chapter on analysis. Analysis was for wimps! Wasn't it true that analysis was that thing that coders that couldn't program were doing? The fact that analysts were wearing suites while posing as wannabe white collars didn't really help their credibility at the time.
Anyway, while I was floating in Plato's hyperuranium, somehow it occured to me to read the missing chapter. It is there that I found a simple powerful technique.
1. Write down what you understand about the domain in plain English.
2. Nouns should be classes
3. Verbs should be methods
Amazingly it worked. It was as simple as it was effective: I could translate ideas to design and I could derive my code from it. Suddenly I was back in business.
There was just this nagging uneasy feeling about some mysterious subterranean link between words and design, between words and the world. However I wasn't paying it too much attention - it was just a cool trick that I could use to kickstart my design. After doing this verbs and nouns analysis thing I had some good raw platonic material that I could chop, stretch and abstract into orbit, away from its humble origins in the user language.
There is a subtle point here - at the time I felt that the analysis of user language was just helping me to look in the right direction where I would have eventually found some kind of perfect design. These days I tend to think that the design is already there, in implicit form, in the user's language, but I'll get to this point later.
The next big conceptual step in the direction of Shal came many years later, while reading the ground-breaking Domain Driven Design book by Eric Evans. I wasn't really looking for that kind of book. I was hunting for some Xp stuff. After all design was so passe!
Design was just the intellectual hubris of neo-platonic structured thinking and intelligent design theories. The stuff that worked evolved from the bottom. The intelligence was not in the coder and was not in the code, but somehow it was in the whole, it was emerging and unfolding as all the parts interacted, respectfully listening to each other and adapting around the problems.
Design was just the intellectual hubris of neo-platonic structured thinking and intelligent design theories. The stuff that worked evolved from the bottom. The intelligence was not in the coder and was not in the code, but somehow it was in the whole, it was emerging and unfolding as all the parts interacted, respectfully listening to each other and adapting around the problems.
Yet, there was 'Domain' in the title and I think I remembered that the xpers somewhere were saying you should listen to domain experts.. so I went for it. Plus the hard cover with the Kandinsky picture looked great.
The DDD book changed the way I think about software. While reading the book I had this continuous stream of epiphanies as I started re-interpreting a number of situations in a different light.
The users had the model. We were just trying to dig it out through careful questioning.
The users had the model. We were just trying to dig it out through careful questioning.
The users had the model but they didn't know it explicitly. We were going to unfold it, in a very xp kind of way, but we were going to create a model, a design that was going to map to user language. Often to the very words of the user language, as Booch suggested. Amazingly if code was aligned to the user language, then things that could be expressed in the user language could also be expressed into code.
This was an incredible eye opener. The user language was not just a starting point for design. The deep user language was the goal of design!
These days I try to evolve my code by the motto: "If it's easy to say, it should be easy to code".
If you can make code that behaves as the user language then you don't break user expectations. When your model is not isomorphic to the user model, the code will not be very reactive to new user requirements. Every time users will ask for a little change, it will take you a long time to express it in code, and this will leave the users frustrated. This happens because this change is totally simple within their implicit domain model, and they don't see or understand your software model.
If you write your code so that "If it's easy to say, it should be easy to code", then they will find acceptable if it will take you a long time to code something that they have trouble explaining in the first place. They will perceive it as a complex concept, and they will understand that it will be complex for you to produce as well.
Now, the thing is that 99% of user requests are very simple and reasonable requests within the users' own model. If you can distill that model, you will be able to make them feel understood. And it's true: you will genuinely understand them!
Your software will have become a true nooartefact - an artefact encoding business knowledge in executable form. Much more than what we think of as being an application.
I am amazed by the fact that Evans and DDD don't have a larger following. I have given the book to a few people to read, but they didn't seem over impressed. They seemed to feel that meddling with the domain was contrary to their domain-agnostic software engineering purity.
Evans had some very profound insights, yet I see people that have read the book asking questions like "should a Repository be implemented as a Singleton?", as if DDD is dealing with fixed patterns. I believe that Evans has opened a door on fantastic new possibilities, but most of the community is still fixated on the door frame and doesn't see that there is something beyond the threshold.
After having read about DDD I had another short milder case of BDUF. This time around I didn't start dressing in black, but I started using crayons to sketch domain models. I still drank lots of coffee. It must be one of those Hegelian thesis-antithesis struggle things. You believe one thing, then you convert to the opposite, then you abstract them together and move on to a new struggle on a higher level of knowledge.
At the time I was reading Evans' book, I also started working with Excel and VBA on a daily basis for my job. I had been programming in Java for many years by that point, and this turn of events seemed a bit of a step back. I didn't give up and I took it as a challenge - writing good code under extreme conditions.
The philosophy of DDD inexorably trickled down to the VBA code. My code started taking new shapes, struggling against the rigidity of the programming language. Then I started applying a few tricks that Evans suggested in the book. Things such as method chaining and object algebras.
The philosophy of DDD inexorably trickled down to the VBA code. My code started taking new shapes, struggling against the rigidity of the programming language. Then I started applying a few tricks that Evans suggested in the book. Things such as method chaining and object algebras.
My code started acquiring more character and usability, but it was still weighted down by an excess of pattern-like code and design habits. I had factories, repositories and configurators lying around, obscuring the domain model.
Then the unthinkable happened. I gave in to Vb.
I stopped trying to write java code in Vb and I just tried to do the simplest thing within the Vb language.
Then I stopped trying to write Vb code according to the classic Vb style. I started making heavy use of Variants, while trying to make clear the semantics of the arguments that I was passing, rather than focusing on the syntax and on the types. My methods could digest arrays, collections, dictionaries, excel ranges or strings, as long as the concept that I was passing to the method represented a "sequence of elements". The disambiguation was happening inside the method itself, where I handled the different types case by case.
This simplified the model enormously, cutting off a huge amount of fat. Then I started breaking all rules. I had functions and classes and methods with the same name. I played with syntactic ambiguity, while avoiding semantic ambiguity in the user domain model.
I had module constants without prefixes indicating which module they were from. I was accepting untyped parameters everywhere. I used singletons. I made heavy unnecessary use of named parameters. I abolished the use of 'New' and I had functions to build even the simplest objects. Except that sometimes the functions were building objects and sometimes they were not, and you had no way of knowing without looking at the code.
I had module constants without prefixes indicating which module they were from. I was accepting untyped parameters everywhere. I used singletons. I made heavy unnecessary use of named parameters. I abolished the use of 'New' and I had functions to build even the simplest objects. Except that sometimes the functions were building objects and sometimes they were not, and you had no way of knowing without looking at the code.
Eventually the surface layer of my code started resembling the user language very closely. Users were incredulous when looking at the code. They were understanding the meaning of what was written and they could even make simple changes without my help. The people that had more trouble were the other programmers and those users that were trying to apply plain vanilla OO to it. They were asking "Is that an object? does it accept collections or arrays?". I was just replying: "It doesn't matter if it is an object. Look at what it represents, read it out aloud, and see how it gets used."
That was when I discovered Shal - Shape (code) After Language
Wednesday, November 23, 2005
Ruby Facets
Ruby Facets is a most excellent little framework working in the direction of language first design and expressive coding. I am now in the process of cleaning up my small frameworks and see what is in common with Ruby Facets.. I'll try to post them as soon as I have got some time.
stay tuned.
stay tuned.
Monday, November 21, 2005
Do With
Another small gold nugget by Dave Astels:
I think I am going to add Dave to my Links menu.
very nice and readable.one = ['a', 'b', 'c']
other = ['x', 'y', 'z']
one.do_with(other) { | a, b | puts a + b }
I think I am going to add Dave to my Links menu.
Sunday, November 20, 2005
Instant Intent
I have put on sourceforge a few small fragments of code that I kept using over and over to state the intent of my code: Instant Intent.
These poor man's "testing" functions allow you to express the intent of a piece of code and later run a reality check against it. However, these days I don't like using the 'test' word, but I prefer to think in terms of intents and reality checking.
Dave Astel calls them behaviours, but I think I will stick to intent for the time being, just to avoid polluting the semantics of the concept I want to explore.
Some things you can do with intents:
expect 5, (3+2)
(3+2).should_be 5
expect_about Pi, 3.14159
expect_exception (StandardError){
These poor man's "testing" functions allow you to express the intent of a piece of code and later run a reality check against it. However, these days I don't like using the 'test' word, but I prefer to think in terms of intents and reality checking.
Dave Astel calls them behaviours, but I think I will stick to intent for the time being, just to avoid polluting the semantics of the concept I want to explore.
Some things you can do with intents:
expect 5, (3+2)
(3+2).should_be 5
expect_about Pi, 3.14159
expect_exception (StandardError){
puts 5/0}
Code as Language II
I have found the Ruby Extension project.
Let's see what I can get from a first quick pass..
Excerpt VII
very nice for metaprogramming. metaprogramming in ruby can quickly get quite messy if you are not careful to continuously refactor your intent.
Excerpt VIII
Excerpt IX
Excerpt X
Excerpt XI
Of course. of course!
Excerpt XII
Excerpt XIII
Excerpt XIV
How do they do it? I have to find out.
Very useful and very dangerous.
I can see lots of interesting work been done here by exploiting the context of a call.
Let's see what I can get from a first quick pass..
Excerpt VII
str = "Hello, \n\n world!"
str.define_method(:heading) {
('*** ' + self.join + ' ***').indent(3)
}
str.heading # -> " *** Hello, world! ***"
very nice for metaprogramming. metaprogramming in ruby can quickly get quite messy if you are not careful to continuously refactor your intent.
Excerpt VIII
person = OpenStruct.new do |p|Ah, I have written stuff like this in the past! This is very much in the spirit of the nooclay. Maybe I should publish my Clay code one of these days.
p.name = 'John'
p.age = 90
end
Excerpt IX
class Personautoinit is v. useful. that's another bit of nooclay behaviour.
attr_reader :name, :age, :pension
autoinit :name, :age do |p|
@pension = 30000 + (@age - 65) * 350
end
end
Excerpt X
HELP = %{
| Usage: ...
| Lorem ipsum...
}.trim('|') Ah, this is similar to Brian Marick's code trick. I like it. Text should become a first class citizen of code.Excerpt XI
STR = "Hello, world!"
STR.starts_with? "Hello" # -> true
STR.ends_with? "world" # -> false
File.write("hello.txt", STR)
Of course. of course!
Excerpt XII
arr = [1, 3, 5]I wrote it myself in the past. very useful and practical.
arr.rand # -> 1, 3, or 5
arr.none? { |n| n.even? } # -> true
arr.one? { |n| n > 4 } # -> true
Excerpt XIII
Class.by_name "Process::Sys" # -> Process::Sysagain, very useful metaprogramming.
Process::Sys.basename # -> "Sys"
Excerpt XIV
Binding.of_callerThis allows you to access the context of the caller of a function.
How do they do it? I have to find out.
Very useful and very dangerous.
I can see lots of interesting work been done here by exploiting the context of a call.
Nooclay
Imagine a new smart software material that reacts to the actions and expectations of the shaper. A sort of software live clay.
Imagine a software material so advanced and yet so simple to interface with. Not just a few intents, but the evolving semantic universe of human knowledge.
Imagine a semantically rich material that changes shape in your hands, following your hints, your nudges, and at the same time offering the forms of the culture it has been tuned to.
Imagine Nooclay.
A sort of nooclay is already possible. A software material with a cultural bias that is opinionated and makes assumptions, yet allows you to bend it to new shapes.. even if it give its best, it is really smooth when following that specific bias, the stylistic school it has been tuned to.
Imagine a software material so advanced and yet so simple to interface with. Not just a few intents, but the evolving semantic universe of human knowledge.
Imagine a semantically rich material that changes shape in your hands, following your hints, your nudges, and at the same time offering the forms of the culture it has been tuned to.
Imagine Nooclay.
A sort of nooclay is already possible. A software material with a cultural bias that is opinionated and makes assumptions, yet allows you to bend it to new shapes.. even if it give its best, it is really smooth when following that specific bias, the stylistic school it has been tuned to.
Code as Language
Code should be more like language. Code should speak to people.
After reading some of Brian Marick's stuff I have been wondering if there were other projects on the web working to the same goal.
Guess what? If you can think it, on the internet you find it :-)
Here is a small review and lots of cut&paste, mainly from comp.lang.ruby..
From "Readability" inflation:
Excerpt I
Well, of course, it allows you to write more uniform code, transforming the block definiton into a tool to define new syntax.
Excerpt II
Yep, it does. Much better.
I used to think of named parameters (an Ada idiom, if I am not wrong) as a bureaucratic heritage from dying programming languages. These days I think they are fundamental to write readable programs. How else would you know the meaning of a parameter, without chasing words with the mouse to get tooltips to pop up?
Still, I think they should be optional. There is no point in saying:
since this would make perfect sense:
without adding any readability that I can see over the Microsoft version.
Must agree with Microsoft, just this time. The implicit result variable makes beautiful code possible.
Excerpt IV
Very nice, I'll check if it has been aliased in any ruby library
From Ruby Facets 0.6.2:
Excerpt V
Perhaps it would also be a nice idea to add Enumerable#count,
Kernel#with and Object.new with a template block?
obj # => "foo"
obj.reverse # => "bar"
I like the count, it reminds me of the COUNTIF in Excel. Actually I would rename it to count_if.
The 'with' is quite cool. How do they do it? I wonder how it is implemented.
I like to be able to make context explicit.
Excerpt VI
Thanks for that. Can I humbly suggest that Numeric#ago be changed to
Numeric#before? If we're trying to mimic English, you'd never say "10
days ago yesterday" in English, but you would say "10 days before
yesterday". So instead of making people call
very nice, I am impressed. great readibility.
I'll explore some more examples and possibly some libraries. I will also try to organize the material that I find in some categories.
After reading some of Brian Marick's stuff I have been wondering if there were other projects on the web working to the same goal.
Guess what? If you can think it, on the internet you find it :-)
Here is a small review and lots of cut&paste, mainly from comp.lang.ruby..
From "Readability" inflation:
Excerpt I
Similarly, if you're used to:
f = lambda {|a,b| ... }
then after a while, you might find that so natural that you feel
"ready" for
Well, of course, it allows you to write more uniform code, transforming the block definiton into a tool to define new syntax.
Excerpt II
> def foo(a =>, b =>, c =>)
> obj = -> (a, b = 1){ block }
def foo(a:, b:, c:)
Yep, it does. Much better.
I used to think of named parameters (an Ada idiom, if I am not wrong) as a bureaucratic heritage from dying programming languages. These days I think they are fundamental to write readable programs. How else would you know the meaning of a parameter, without chasing words with the mouse to get tooltips to pop up?
Still, I think they should be optional. There is no point in saying:
plot_point x: x, y: y, color: chosen_color
since this would make perfect sense:
plot_point x, y, chosen_color
Excerpt III
Consider Microsoft's Monad's
get-childitem | sort-object extension | foreach { $_.filename}
vs Ruby's
get-childitem.sort_by{|child| child.extension}.map{|child| child.filename}
without adding any readability that I can see over the Microsoft version.
Must agree with Microsoft, just this time. The implicit result variable makes beautiful code possible.
Excerpt IV
> Case in point, what's the english equiv of #===. I'd really like to
> have one.
How about "contains" or "includes"? > have one.
String contains "abc"
0..10 contains 5
1,2,3,4 contains 3
/^[a-z]*$/ includes "apple"
It would be nice if Array#=== was aliased to Array#include? So that
somearray === someval
Very nice, I'll check if it has been aliased in any ruby library
From Ruby Facets 0.6.2:
Excerpt V
Perhaps it would also be a nice idea to add Enumerable#count,
Kernel#with and Object.new with a template block?
Samples:
[1, 2, 3].count { |item| item > 1 } # => 2
with("foo") { reverse } # "oof"
obj # => "foo"
obj.reverse # => "bar"
This is the way I understood how 'with' would work:
s = "hello"
with(s) {
reverse!
capitalize!
I like the count, it reminds me of the COUNTIF in Excel. Actually I would rename it to count_if.
The 'with' is quite cool. How do they do it? I wonder how it is implemented.
I like to be able to make context explicit.
Excerpt VI
Thanks for that. Can I humbly suggest that Numeric#ago be changed to
Numeric#before? If we're trying to mimic English, you'd never say "10
days ago yesterday" in English, but you would say "10 days before
yesterday". So instead of making people call
10.days.ago( Time.now - 1.day )
they could call
10.days.before( Time.now - 1.day )
instead. And if Time.yesterday and Time.tomorrow had been defined, you
could simply call
10.days.before Time.yesterday
And maybe this would cause transitional issues, but it might be good to
redefine Numeric#ago to refer to a time relative to the current moment,
which is in line with what it means in English.
yesterday = 1.day.ago
last_monday = 8.days.ago
Similarly, Numeric#later could go the other way:
tomorrow = 1.day.later
next_tuesday = 6.days.later
And Numeric#after could add time to any arbitrary starting point:
very nice, I am impressed. great readibility.
I'll explore some more examples and possibly some libraries. I will also try to organize the material that I find in some categories.
Saturday, November 19, 2005
Evolving Maru Batsu from Intents
Wednesday, November 16, 2005
Liquid Developers
The implicit community I wrote about in the previous post incarnates my ideal of development as a very fluid discipline that blurs the boundaries between knowledge weaving, personal mastery, people organization and code evolution.
When I think about these people, I think of them as a new kind of reinassance avant-garde.
I think of them as being Liquid Deveopers.
When I think about these people, I think of them as a new kind of reinassance avant-garde.
I think of them as being Liquid Deveopers.
Blogging Plans
I have been writing up for a book project of mine for a few months now. I do that on and off, following my mood and my need to fix my ideas on paper, and I have got about 200 pages of structure and raw material.
I started blogging to be able to compare papers with other people from the community that I am watching. What community? Well, it is an implicit community. It is there, because I see it, and because many of these people know one another's work. Yet it doesn't exist as a single place and it keeps changing all the time. That's why I call it an implicit community.
I have been watching this community for a while, and in the writings of these people I have found many of the same ideas that I was putting on paper. Very often I found out points of view that I had never considered, and I had to go back to my notes, evaluate the impact on my work and the factor in this new knowledge.
After a long time of timid wall-papering I finally took the step of signing up for a blog, and I now want to start writing up some of those notes, hoping that the idea of a potential public will help me to focus thoughts and developments in a productive way.
After a long time of timid wall-papering I finally took the step of signing up for a blog, and I now want to start writing up some of those notes, hoping that the idea of a potential public will help me to focus thoughts and developments in a productive way.
Brian Marick is my hero
Today I saw a post by Brian Marick, the author of Exploration Through Example. This post was about multiline strings in Ruby.
Just a small tiny thing you might think. Why can't he just accept multilines as they are and align his text to the left border of the screen. Why does he bother making up strange formatting conventions that tell to the code where the actual beginning of the line is? Why, for heaven sake, does he waste precious memory cycles?
Brian Marick is my new hero. Because he thinks about these details and because he does care about them. In his blog he talks mainly about testing and how to do testing by example, but what I really care about is his underlying philosophy, which it seems to me to be very much people oriented and language oriented.
He seems to care about aestethics, perception, expressiveness, mental models and human factors of coding. He cares for what, in my circle, I like to call "Software Ergonomics" and "Language Development".
He also care about what I call "Knowledge Ecology". I started blogging because I have been reading the blogs of people like Brian and I felt like contributing with my own experiences.
I don't know if you are reading this Brian, but I really dig your style. Kudos to you and please keep up with the excelent work.
Tuesday, November 15, 2005
Liquid Languages
I know, I know, C++ macros have got a bad rep, and we have all seen how the misguided use of macros can create all sorts of problems. However, when macros are not simply a language add-on, but they can be more deeply integrated, wonderful things can be done.
I am sure I am not the only one that has been feeling frustrated by the impossibility of molding his libraries into something that was smoothly integrating with the language. Blocks and continuations are a step forward. Have a look at Ruby, JRuby or Groovy, and also have a look at the Java Syntactic Extender, another project that tries to revamp the aging Java language.
Tuesday, November 08, 2005
Four Stages of Mastery 2
The Initiate – makes it
The Adept – makes it modular
The Master – makes it elegant
The Enlightened Master – breaks the symmetry
The Adept – makes it modular
The Master – makes it elegant
The Enlightened Master – breaks the symmetry
Four Stages of Mastery
The Initiate – thinks about the algorithm
The Adept – thinks about structure
The Master – thinks about intent
The Enlightened Master – thinks about people
The Adept – thinks about structure
The Master – thinks about intent
The Enlightened Master – thinks about people
Thursday, November 03, 2005
Liquid Materials
Some materials are more flexible than others. Flexible, dynamic materials make a medium.
The Web is a medium. Wiki is a medium. As strange as it may sound, Excel is often a medium.
The whole concept of Mashup and Web2.0 is a new medium in itself, allowing to build things from it. A Mashup, as far as I understood it, is an "application" that uses existing services and information from the web, collating them into a new knot of active executable knowledge, not originally present in any of its parts.
YubNub is another example of emerging medium. YubNub concept is so simple and powerful that its implications take your breath away. YubNub is about building a command line to the Web. On the Web. This is a medium bootstrapping itself to new heights!
Envision the level of integration you could achieve when a tool like YubNub and web applications (and services) start moving in step, striving to achieve reciprocal leverage.. this is a whole new world of knowledge at your fingertips, embeddable into smart servants and enhanceable via human interaction.
The Web is a medium. Wiki is a medium. As strange as it may sound, Excel is often a medium.
The whole concept of Mashup and Web2.0 is a new medium in itself, allowing to build things from it. A Mashup, as far as I understood it, is an "application" that uses existing services and information from the web, collating them into a new knot of active executable knowledge, not originally present in any of its parts.
YubNub is another example of emerging medium. YubNub concept is so simple and powerful that its implications take your breath away. YubNub is about building a command line to the Web. On the Web. This is a medium bootstrapping itself to new heights!
Envision the level of integration you could achieve when a tool like YubNub and web applications (and services) start moving in step, striving to achieve reciprocal leverage.. this is a whole new world of knowledge at your fingertips, embeddable into smart servants and enhanceable via human interaction.
The Web as a Medium
The web is more like a medium than a program.
A program has a set of expectations on user interactions and well-formed steps that must be followed to obtain certain results. If the program has been designed to do a certain thing, then you have to struggle against the program if you would like it to do something different.
A medium has a more liquid nature.
A medium is based more on conventions than strict rules.
A medium suggests, but doesn't enforce.
A medium is made for people to move through it, leave signs, start jobs and leave them there to be completed later.. maybe for someone else to see them and add their own bit to them. A medium is somewhat loose and open-ended, allowing continuous semantic hijacking by its users.
A program has a set of expectations on user interactions and well-formed steps that must be followed to obtain certain results. If the program has been designed to do a certain thing, then you have to struggle against the program if you would like it to do something different.
A medium has a more liquid nature.
A medium is based more on conventions than strict rules.
A medium suggests, but doesn't enforce.
A medium is made for people to move through it, leave signs, start jobs and leave them there to be completed later.. maybe for someone else to see them and add their own bit to them. A medium is somewhat loose and open-ended, allowing continuous semantic hijacking by its users.
