I cocked something up this morning. I've been rebuilding an important background system which handles time sensitive data. This morning it did an update, but I'd been so busy thinking about the complicated data processing bit that I forgot to update the part that puts the data on to the website. It was quickly mended, but it was a stupid mistake to make.
Here's todays lesson. It doesn't matter how much work you put in behind the scenes. If the bit that everyone see's is broken then you're stuffed.
That's applies to everything, particularly comedy. I love performing, but I'm a background system kind of a guy. I often forget to update the bit that everyone see's. The simple bits, like learning material, talking at a speed that everyone can hear, getting the words right. That bit bores me. It seems trivial in the face of everything else, so I let it slide.
Stupid, stupid boy.
Monday 22 October 2007
Friday 19 October 2007
Creativity?
Some amazing stuff here http://www.ted.com, but it did get me thinking. The world is falling to pieces, but the great creative minds of our time seem more interested in how to improve social networking.
Frustration.. the refrain
Calmed down since that last post. Had a ciggy which was extra specially good, cause I quit last week.
Two points that continue on from that last post:
Firstly all programming is essentially object oriented. You write programs using a set of command. Each command does a descrete task, print to the screen, compare two quantities. These commands are the limited set of objects you have to build with. They are based on even simpler commands; the machine code that runs the computer, tells it to move a bunch of 1's and 0's from one part of the computer to another.
Simple little commands build up to produce larger commands, which are combined to make the programs we use everyday. Molecules make materials, materials make bricks, bricks make houses, houses make cities, cities make countries etc etc etc. On each step up that ladder we set in stone (no pun.. achieved) the functionality of the new object. A house is a house, it's made of bricks, but you can't use a house to make a well (not without tearing the house down). We loose something of the properties of the constituent parts. A house is a better place to live than a pile of bricks, but does not have as much potential.
Point two. A program is a tool to solve a problem. If the tool doesn't fit the problem, the problem doesn't go away.
If the tool doesn't fit the problem we have two solutions:
The problem must change. This happens all the time. I want to sell my books online, but the website can't do that. I want the text on the left, but that's not possible. The problem doesn't get solved, until the tool is changed.
Solution two, some middle man/ware has to make up for the tools shortfall. Some intermediate that fills in between the tool and the problem. Ussualy that's a human. How many people have jobs that involve collating information into a specific format because the system it needs to be fed into can't cope with it any other way. The user has to serve the computer. A great example are automated switchboards, it really isn't easier for the user to have to wade through the comuters list of annoying options. It's a reversal of subject/object - who is the captain and who is the ship.
This human as middle ware issue is very common. It's slightly depressing (so many things are). In the past we did all the brain work. We calculated the accounts, we maintained the Human Resources records. Now computerised tools do lots of the work for us. But we still have work to do. Ussualy it's a task of data entry or mediation between systems. Our skills shift. Who needs brain maths when you have spreadsheet or calculator. Labour saving often includes thought saving. This is a negative path to travel. What I'm implying is that we the human middleware no longer need to perform the clever stuff, just often repeatitive and dull gap filling between the tools we use and the problems that actually exist. That's not rewarding work. It's not even mentally demanding work. It's akin to factory labour.
The more monolithic an application, the worse designed it is, the more unflexible it becomes and the more we are forced into the middleware role.
Hmmmphhh.
Two points that continue on from that last post:
Firstly all programming is essentially object oriented. You write programs using a set of command. Each command does a descrete task, print to the screen, compare two quantities. These commands are the limited set of objects you have to build with. They are based on even simpler commands; the machine code that runs the computer, tells it to move a bunch of 1's and 0's from one part of the computer to another.
Simple little commands build up to produce larger commands, which are combined to make the programs we use everyday. Molecules make materials, materials make bricks, bricks make houses, houses make cities, cities make countries etc etc etc. On each step up that ladder we set in stone (no pun.. achieved) the functionality of the new object. A house is a house, it's made of bricks, but you can't use a house to make a well (not without tearing the house down). We loose something of the properties of the constituent parts. A house is a better place to live than a pile of bricks, but does not have as much potential.
Point two. A program is a tool to solve a problem. If the tool doesn't fit the problem, the problem doesn't go away.
If the tool doesn't fit the problem we have two solutions:
The problem must change. This happens all the time. I want to sell my books online, but the website can't do that. I want the text on the left, but that's not possible. The problem doesn't get solved, until the tool is changed.
Solution two, some middle man/ware has to make up for the tools shortfall. Some intermediate that fills in between the tool and the problem. Ussualy that's a human. How many people have jobs that involve collating information into a specific format because the system it needs to be fed into can't cope with it any other way. The user has to serve the computer. A great example are automated switchboards, it really isn't easier for the user to have to wade through the comuters list of annoying options. It's a reversal of subject/object - who is the captain and who is the ship.
This human as middle ware issue is very common. It's slightly depressing (so many things are). In the past we did all the brain work. We calculated the accounts, we maintained the Human Resources records. Now computerised tools do lots of the work for us. But we still have work to do. Ussualy it's a task of data entry or mediation between systems. Our skills shift. Who needs brain maths when you have spreadsheet or calculator. Labour saving often includes thought saving. This is a negative path to travel. What I'm implying is that we the human middleware no longer need to perform the clever stuff, just often repeatitive and dull gap filling between the tools we use and the problems that actually exist. That's not rewarding work. It's not even mentally demanding work. It's akin to factory labour.
The more monolithic an application, the worse designed it is, the more unflexible it becomes and the more we are forced into the middleware role.
Hmmmphhh.
Frustration
Damn I'm getting frustrated. Trying to build a DAO in CFC. A DAO is a Data Access Object. In Object Oriented Programming (OOP) you build mini programs called objects (that's not how a technical person would describe it, but f*** em). Each object does a job, so in a calculator you might have a display object that prints out the numbers on the display, a set of button objects that can be pressed - each one with a different value, a calculation object that does the maths etc etc. It's a method of building a program in the same way that we build things in the real world.
Another example would be building a house. Building an OOP house would involve designing a Brick object - you would then replicate that brick object and connect all the brick objects together to produce your walls. You'd also have window and door objects which you would replicate and use as... windows and doors. it's a duff example in that you wouldn't build a house program - please don't get confused an think I'm describing how a 3d model of a house is constructed - It's the concept we're looking at. Our naff house has been built using three things - Bricks, windows and doors. As I the builder I designed each of these things once, then replicated them. This is the OOP fundemental - reuse. Lots of little objects that can be reused and repurposed.
It's a great idea, except it is hellishly frustrating. A key principals is that every object you make is free standing. What good is a brick if it needs to be used in confunction with a window! A brick is a unique unit that doesn't rely on anything else. Imagine building a house in the real world and watching the side wall crumble because you didn't insert a window in it. This principal that everything is free standing makes sense - but it's a git!
Making something free standing is hellishly hard.
You might think the problem is in the detail. but lets go back to that house. Bricks, Windows and Doors. Ahh, but what about the tricky bits in a house like the bricks at the corners that have to be shorter to fit in. Or the pipe work that goes round the house, that must require all sorts of different lengths and angles. Surely that makes things very hard. Well it does complicate things, but it's actually OK. OO allows for that. You can build a basic brick, and then create a variation of that brick called Half-Brick. It's still a brick, it's just a variation of one. It shares most of the same properties. It's just different in the one respect of length. (To any programmers gnawwing the qwerty keys and protesting that length should be a property, half-brick is stupid - get stuffed I'm illustating a point. Hold your nubbin and be patient).
To me the difficulty lies not in the detail, but in the wide picture. The stuff that is taken for granted. The house is built on land. Land is not flat. The house needs footings to plumb it into the ground. There needs to be a road going to the house. It needs to know it's orientation to the road. It needs an address if letters are to arrive. It needs plans to be legal.
I'm straying to far down an analogy. What I'm ranting about is the fact that every OOP project I'm involved in seems flawed by the fact that at some point the application meets the real world. The real world has infinate variation. To intigrate with the real world you need to know certain things. As soon as those certain things come into play the objects need to be subtly varied to make them fit. But that subtle variation ain't so subtle. They're the same variations that had to be written in non Object Oreinted code. They're the same conditionals that were there before. Trying to create an object that fits all circumstances nearly always becomes a lie.
Let me put it a less meladramatic way.
Programs are tools. They are there to do a job. The job that needs to be done defines the logic that we must code into our tool. The program fits around the problem, not vice versa.
Whatever form the program takes it must fit around the problem that is there to be solved. Building it in objects doesn't seem to take away that underlying fact.
I s'pose I've ranted myself into a conclusion to my own unpossed question. An object oriented approach isn't better than a Proceedural approach (the old school way of programming). It's just different. It will suit some situations better than others. The programmer is still required to understand the problem that the tool is solving. The twisted logic required to fit in with the world will still be there in either case.
It shouldn't matter how you approach a problem. What matters is the quality of the solution. (In a program that is ease of use, ease of maintenance, cost etc... it's a long list). What bugs me about programming, and technology as a whole, are those that say "Do it this way", "This way is best", "This way is standard". The illusion that there are standard problems exaserbates this issue. rarely are two things the same when you look at the details. Our society believe there is white and black, when there is only grey (and green, yellow, blue, red, pink, misty, opaque, checked and lost-in-the-post).
Another example would be building a house. Building an OOP house would involve designing a Brick object - you would then replicate that brick object and connect all the brick objects together to produce your walls. You'd also have window and door objects which you would replicate and use as... windows and doors. it's a duff example in that you wouldn't build a house program - please don't get confused an think I'm describing how a 3d model of a house is constructed - It's the concept we're looking at. Our naff house has been built using three things - Bricks, windows and doors. As I the builder I designed each of these things once, then replicated them. This is the OOP fundemental - reuse. Lots of little objects that can be reused and repurposed.
It's a great idea, except it is hellishly frustrating. A key principals is that every object you make is free standing. What good is a brick if it needs to be used in confunction with a window! A brick is a unique unit that doesn't rely on anything else. Imagine building a house in the real world and watching the side wall crumble because you didn't insert a window in it. This principal that everything is free standing makes sense - but it's a git!
Making something free standing is hellishly hard.
You might think the problem is in the detail. but lets go back to that house. Bricks, Windows and Doors. Ahh, but what about the tricky bits in a house like the bricks at the corners that have to be shorter to fit in. Or the pipe work that goes round the house, that must require all sorts of different lengths and angles. Surely that makes things very hard. Well it does complicate things, but it's actually OK. OO allows for that. You can build a basic brick, and then create a variation of that brick called Half-Brick. It's still a brick, it's just a variation of one. It shares most of the same properties. It's just different in the one respect of length. (To any programmers gnawwing the qwerty keys and protesting that length should be a property, half-brick is stupid - get stuffed I'm illustating a point. Hold your nubbin and be patient).
To me the difficulty lies not in the detail, but in the wide picture. The stuff that is taken for granted. The house is built on land. Land is not flat. The house needs footings to plumb it into the ground. There needs to be a road going to the house. It needs to know it's orientation to the road. It needs an address if letters are to arrive. It needs plans to be legal.
I'm straying to far down an analogy. What I'm ranting about is the fact that every OOP project I'm involved in seems flawed by the fact that at some point the application meets the real world. The real world has infinate variation. To intigrate with the real world you need to know certain things. As soon as those certain things come into play the objects need to be subtly varied to make them fit. But that subtle variation ain't so subtle. They're the same variations that had to be written in non Object Oreinted code. They're the same conditionals that were there before. Trying to create an object that fits all circumstances nearly always becomes a lie.
Let me put it a less meladramatic way.
Programs are tools. They are there to do a job. The job that needs to be done defines the logic that we must code into our tool. The program fits around the problem, not vice versa.
Whatever form the program takes it must fit around the problem that is there to be solved. Building it in objects doesn't seem to take away that underlying fact.
I s'pose I've ranted myself into a conclusion to my own unpossed question. An object oriented approach isn't better than a Proceedural approach (the old school way of programming). It's just different. It will suit some situations better than others. The programmer is still required to understand the problem that the tool is solving. The twisted logic required to fit in with the world will still be there in either case.
It shouldn't matter how you approach a problem. What matters is the quality of the solution. (In a program that is ease of use, ease of maintenance, cost etc... it's a long list). What bugs me about programming, and technology as a whole, are those that say "Do it this way", "This way is best", "This way is standard". The illusion that there are standard problems exaserbates this issue. rarely are two things the same when you look at the details. Our society believe there is white and black, when there is only grey (and green, yellow, blue, red, pink, misty, opaque, checked and lost-in-the-post).
Thursday 18 October 2007
Where to get started
I'm currently learning how to do Object Oriented programming (OO). What OO is I'll no doubt talk about at a later date, but for now it's enough to say that it's a more complicated way of creating computer programs than I am used to.
It's only in the last few weeks that I've actually programmed anything in OO, but depressingly its taken me about 2 years to get to this stage. What have I been doing in all that time? To begin with I had to become aware that this method of programming existed. Then I had to realise that it was worth learning; That was a big step, because it would be much easier to pass it over. Lots of people talk about the benefits of OO, but those opinions meant very little. I can program just fine without it. Indeed it took getting stuck to make me realise that this could be a way to go.
Finally I had to work out where to start. As a programmer you pick up a lot of new programming languages. A programming language is like a spoken language. "Tickle my armpit" in English versus "Tickle my armpit" in French is the same thing: words represent objects and actions, they're just different words, possibly in a different order. The principal is the same. Ask me to mime "Tickle my armpit" or sculpt it, then I'm on a new track. New concepts are involved. OO isn't a new language it's a new set of concepts. Look at a piece of OO code and although I can make guesses at what's happening I really don't have much of a clue. Things are being done for a purpose, but I don't know what that purpose is.
Where do you start to learn? To me there seem three ingredients: examples, concepts and experiments:
An example shows you how to achieve something, but just copying an example doesn't necessarily provide any understanding of the concepts that under pin it.
Take Flat Pack Furniture (FPF, lets keep the abbreviation count up). Great stuff - I built a table the other day. FPF instruction are usually step by step diagrams proceeded by a list of the parts you should have, but probably don't. 4 x screws, 8 x wooden pins, 3 x angle bits and 7 x tapered bolt things that swivel. To begin with you look at the pieces and wonder how this collection of pointless junk could ever constitute a table. Then you build. Lets dream the dream and pretend you get it right first time. Suddenly you understood what each of those parts do. It's obvious now why you need 7 x tapered bolt things; they join the flat bit of the table to legs. You know what they do and why.
You've made the table first time. You're feeling cocky. You decide build a flat pack chair. In light of the table you expect the seat to be held on with tapered bolt things, after all, it worked for the table. But no, the chair comes with 16 reversible self lubricated "L" pegs. They do the same job, but in a different way. If your desire was to become a furniture designer you then this could be a depressing moment. Some where there is a reason behind the two different methods for doing seemingly the same thing. Someone somewhere knows something you don't.
Imagine now that you use your table and chair experiences to designing and build a shed. It's probably a deathtrap waiting to happen, that's if you even manage to get started. Reversible self lubricated "L" pegs don't grow on trees, and I doubt you'll have any idea how to select, plane and mill a piece of wood.
Lets move onto Concepts. These usually take the form of an open ended list of all the knowledge you need to understand a particular process. It can be an incredibly long and hard route.
I studied engineering at university. 4 very long years spent studying. I know (or did know) how to analyse both the static and dynamic stresses in materials under a range of loads. I know how to work out the sheering forces in a screw thread, can calculate the center of gravity of a large object, and the frictional forces exerted on a flat plane. With all that knowledge can I design and build you a table? Well yes probably. it would be 6 months of complex maths and planning. The study of wood types and selection, theories on tools and sawing. The textbooks would pile high (presumably on a table not unlike the one I was designing). The work involved would be disproportionate to the problem. It would be very boring and seemingly unnecessary to go to such lengths. (There's an Ikea in Edmonton).
Experimenting is the process where by you try and fail! Then you try and fail again. You can loose limbs experimenting. With time you will get somewhere. Often where you get has been previously documented. When your front room is full of experimental tables, not a leg of equal length between them, you do wonder would it not be better to just copy an example. The time cost of reading a relevant text book might have been worth it.
I'm probably stating the obvious: When you learn something new you need all three of these qualities.
Examples are the quick start into learning a new skill. If you want to be a comedian, watch comedy. Imitating isn't a bad way to get started. At the very least it gets you started, and that's a big step.
Experiment, find out the traps and problems. Try to do something you don't have an example for. Rearrange that which you have to find out it's limits. Write your first joke, die on stage and realise you don't get it yet. This should make you aware of your current limits. It should create questions.
When you have questions look to the concepts. Find enough to get you unstuck. Answer the questions by digging deeper to understand how the examples you already have work.
I ussualy get to a point where I cycle between the three qualities. If I'm stuck I look for examples. If they don't work. I look for concepts. If they don't work I experiment. If that doesn't work I look for other examples based on what I have discovered. From this back and forth comes something new. Creation. That's the most rewarding bit. When experimentation combines with existing knowledge be it concepts or examples - and you create something that wasn't there before.
Two observations:
Object Oriented Programming is full of concepts. Most of them hidden behind complex words that aren't really necessary. It took a long time to get my head around the concepts. I probably did too much theory and too little playing. If you want to start OO I recommend starting small. Lots of examples. Read lots and try to sort the useful information from the tonnes of words and rules. You will get there, don't be put off.
If you don't balance out concepts, examples and experimenting then you can get stuck. In comedy I have got bogged down in the theories and concepts. I stopped watching it and I don't experiment enough. That's a killer. Interesting that it's almost the same trap I got into as OO.
Long post. Hope useful to someone.
It's only in the last few weeks that I've actually programmed anything in OO, but depressingly its taken me about 2 years to get to this stage. What have I been doing in all that time? To begin with I had to become aware that this method of programming existed. Then I had to realise that it was worth learning; That was a big step, because it would be much easier to pass it over. Lots of people talk about the benefits of OO, but those opinions meant very little. I can program just fine without it. Indeed it took getting stuck to make me realise that this could be a way to go.
Finally I had to work out where to start. As a programmer you pick up a lot of new programming languages. A programming language is like a spoken language. "Tickle my armpit" in English versus "Tickle my armpit" in French is the same thing: words represent objects and actions, they're just different words, possibly in a different order. The principal is the same. Ask me to mime "Tickle my armpit" or sculpt it, then I'm on a new track. New concepts are involved. OO isn't a new language it's a new set of concepts. Look at a piece of OO code and although I can make guesses at what's happening I really don't have much of a clue. Things are being done for a purpose, but I don't know what that purpose is.
Where do you start to learn? To me there seem three ingredients: examples, concepts and experiments:
An example shows you how to achieve something, but just copying an example doesn't necessarily provide any understanding of the concepts that under pin it.
Take Flat Pack Furniture (FPF, lets keep the abbreviation count up). Great stuff - I built a table the other day. FPF instruction are usually step by step diagrams proceeded by a list of the parts you should have, but probably don't. 4 x screws, 8 x wooden pins, 3 x angle bits and 7 x tapered bolt things that swivel. To begin with you look at the pieces and wonder how this collection of pointless junk could ever constitute a table. Then you build. Lets dream the dream and pretend you get it right first time. Suddenly you understood what each of those parts do. It's obvious now why you need 7 x tapered bolt things; they join the flat bit of the table to legs. You know what they do and why.
You've made the table first time. You're feeling cocky. You decide build a flat pack chair. In light of the table you expect the seat to be held on with tapered bolt things, after all, it worked for the table. But no, the chair comes with 16 reversible self lubricated "L" pegs. They do the same job, but in a different way. If your desire was to become a furniture designer you then this could be a depressing moment. Some where there is a reason behind the two different methods for doing seemingly the same thing. Someone somewhere knows something you don't.
Imagine now that you use your table and chair experiences to designing and build a shed. It's probably a deathtrap waiting to happen, that's if you even manage to get started. Reversible self lubricated "L" pegs don't grow on trees, and I doubt you'll have any idea how to select, plane and mill a piece of wood.
Lets move onto Concepts. These usually take the form of an open ended list of all the knowledge you need to understand a particular process. It can be an incredibly long and hard route.
I studied engineering at university. 4 very long years spent studying. I know (or did know) how to analyse both the static and dynamic stresses in materials under a range of loads. I know how to work out the sheering forces in a screw thread, can calculate the center of gravity of a large object, and the frictional forces exerted on a flat plane. With all that knowledge can I design and build you a table? Well yes probably. it would be 6 months of complex maths and planning. The study of wood types and selection, theories on tools and sawing. The textbooks would pile high (presumably on a table not unlike the one I was designing). The work involved would be disproportionate to the problem. It would be very boring and seemingly unnecessary to go to such lengths. (There's an Ikea in Edmonton).
Experimenting is the process where by you try and fail! Then you try and fail again. You can loose limbs experimenting. With time you will get somewhere. Often where you get has been previously documented. When your front room is full of experimental tables, not a leg of equal length between them, you do wonder would it not be better to just copy an example. The time cost of reading a relevant text book might have been worth it.
I'm probably stating the obvious: When you learn something new you need all three of these qualities.
Examples are the quick start into learning a new skill. If you want to be a comedian, watch comedy. Imitating isn't a bad way to get started. At the very least it gets you started, and that's a big step.
Experiment, find out the traps and problems. Try to do something you don't have an example for. Rearrange that which you have to find out it's limits. Write your first joke, die on stage and realise you don't get it yet. This should make you aware of your current limits. It should create questions.
When you have questions look to the concepts. Find enough to get you unstuck. Answer the questions by digging deeper to understand how the examples you already have work.
I ussualy get to a point where I cycle between the three qualities. If I'm stuck I look for examples. If they don't work. I look for concepts. If they don't work I experiment. If that doesn't work I look for other examples based on what I have discovered. From this back and forth comes something new. Creation. That's the most rewarding bit. When experimentation combines with existing knowledge be it concepts or examples - and you create something that wasn't there before.
Two observations:
Object Oriented Programming is full of concepts. Most of them hidden behind complex words that aren't really necessary. It took a long time to get my head around the concepts. I probably did too much theory and too little playing. If you want to start OO I recommend starting small. Lots of examples. Read lots and try to sort the useful information from the tonnes of words and rules. You will get there, don't be put off.
If you don't balance out concepts, examples and experimenting then you can get stuck. In comedy I have got bogged down in the theories and concepts. I stopped watching it and I don't experiment enough. That's a killer. Interesting that it's almost the same trap I got into as OO.
Long post. Hope useful to someone.
Wednesday 17 October 2007
My passions: Programming and Comedy
I've tried Blogs before and I never keep them up. I think the main reasons are that a) I'm not a confident writter and b) I never pick a subject I'm interested in. The later is a stupid reason because I have two subjects that I obcess about all the time. By day I'm a computer programmer and by night I'm a comedian. Zen and the Art of motorcycle maintenance is the inspiration between merging the two. So here we go. How to be funny and how to program. They share many of the same issues and they overlap more than you would expect.
Lets see how we do this time.
Lets see how we do this time.
Subscribe to:
Posts (Atom)