I was looking over some of the archives of Bruce Eckel a while ago and came across his Static vs Dynamic post comparing the two types of languages.
Again and again, the argument about Static vs Dynamic languages seems to devolve into an argument about finger typing: whether not declaring types is worth the loss of the safety net of compiler checking. This argument seems to originate particularly from the 'Static' camp since from their point of view, the real difference between static and dynamic languages is the lack of type declarations.
The sad thing is that the Static camp's focus on the argument that 'reducing the amount of typing is not worth the loss of compiler checking' always seems to coerce the dynamic language crowd into the argument that type declarations really aren't needed.
I think that is missing the whole point.
It's true that many claim that dynamic languages help reduce the amount of code you have to write to get a particular problem solved. However, this reduction in code is not because of the lack of type declarations. It's because more time than not, dynamic languages provide the programmer with more powerful abstraction techniques. From the point of view of the dynamic language 'weenies', the problem with Java (and its evil twin C#) isn't that you are forced to declare types. It's that the type system hinders your ability to create more powerful abstractions. Code blocks and list continuations and the like don't seem to be possible using the type system of these so-called static languages.
And, the fact is, that power doesn't simply come from dropping the static type system. As an example, Coldfusion is a dynamic language in the sense that you do not need type declarations. However, it sucks at creating abstractions. Thus, it isn't considered under the 'dynamic language' umbrella, even though, based on the 'Java crowd' definition of dynamic languages, it should be.
The sad thing about the whole argument is that the Java evangelists seem to forget an important point. Many of the more prominent Java developers made the switch to Ruby and Python based on first-hand experience. Although they 'knew' Java's compile-time type checking was too important to give up, their actual experience using these dynamic languages showed them to be much more productive outside of the restrictive shell that Java's type system enforces.
I guess my plea, although it may fall on deaf ears, is to simply try to code something significant in Python. Do a project using Ruby. And truly use it. Don't code Java in Ruby/Python. Try to leverage the power that the language provides. Try it yourself on just one project, and make a judgment call on real experience. And see for yourself how better abstraction capabilities lead to a better coding experience.
Monday, December 24, 2007
Thursday, December 6, 2007
The Ills of Procrastination
Sometimes, procrastination can really suck your life out.
I'm sitting here trying to motivate myself to do SOMETHING, but no go. I have a bunch of work to do, but nothing doing... my brain is frozen.
I guess that happens to the best of us.
It's also the reason why I think working 'regular hours' can totally suck from a productivity standpoint. I typically work from home rather than the office, and on a day like this, if I were home, I'd just go and take a nap or relax in some way, and get to work later in the night. Of course, that luxury isn't available when at the office. You just can't 'do something else'.
So, instead, I sit here, and try to beat off the procrastination. Unfortunately it is beating back. And it hits much harder.
I'm sitting here trying to motivate myself to do SOMETHING, but no go. I have a bunch of work to do, but nothing doing... my brain is frozen.
I guess that happens to the best of us.
It's also the reason why I think working 'regular hours' can totally suck from a productivity standpoint. I typically work from home rather than the office, and on a day like this, if I were home, I'd just go and take a nap or relax in some way, and get to work later in the night. Of course, that luxury isn't available when at the office. You just can't 'do something else'.
So, instead, I sit here, and try to beat off the procrastination. Unfortunately it is beating back. And it hits much harder.
Tuesday, December 4, 2007
Converting Ruby to Java
I readily admit that my previous post about the lack of distinguishable efficiency between Ruby and Java was absolutely off-base. Completely.
I'm still working on that same simulation program that I described yesterday. Why? Although I designed the program using Ruby, I need to provide the source code in Java. I always knew this, my thought process was that I would try out the development process using Ruby, and then port the program to Java once I was completed. Which is what I attempted to do last night. Which was another 'eye-opening' experience.
It seems that my current lack of Java exposure has numbed me to the amount of cruft in a typical Java program. I started the port fairly straightforwardly... copy the Ruby code into a Java class, and change the various Ruby-specific keywords to their Java equivalents, and that should be it.
So, I begin to change def to public void/int/boolean, end to }, and removing the @ and : from instance variables and symbols respectively.
It was then I began to realise how much visual clutter Java forces on you. I needed to put the opening brace after every method definition. I needed to add opening and closing parentheses to all my method definitions AND function calls. And don't forget the dear old semi-colon after every line. Nope, we can't use the if/while/unless statement modifiers, so every one of those becomes a full-blown if statement block, complete with all its brace-y goodness.
Just making all the syntax changes was an experience... by the time I was done, my code was noticeably longer, and just seemed much more like code and less readable as a result.
But, the difference between Java and Ruby goes beyond syntax. So, the stage two of the conversion involved changing constructs such as blocks, array sorting, use of hashes etc to Java equivalents. And there was where the true differences between the languages surfaced. You see,he language you use does influence your coding style, by making certain things easier to do. Thus, the natural syntax of hashes make them extremely popular, as Rails can attest to. Of course, the Java equivalent is a huge pile of clunkiness that I don't even want to think about.
The end result is that after the straightforward conversion of standard syntax differences, I actually had to then rewrite logic for the Java version because of its lack of certain Ruby functionality.
That is to be expected, right? I mean, they are different languages after all. Some things will be easier in Ruby than in Java and vice versa, right?
Of course, so far, I've only come across things that are harder in Java than in Ruby. I've yet to find something that Java does better.....
Hmm....
PS. What has me particularly cranky is the fact that in converting some of the Ruby constructs to Java, I broke something, and I'm having a hard time figuring out what. And it's annoying me that I have to go through the same debugging process again in Java that I went through in Ruby....
I'm still working on that same simulation program that I described yesterday. Why? Although I designed the program using Ruby, I need to provide the source code in Java. I always knew this, my thought process was that I would try out the development process using Ruby, and then port the program to Java once I was completed. Which is what I attempted to do last night. Which was another 'eye-opening' experience.
It seems that my current lack of Java exposure has numbed me to the amount of cruft in a typical Java program. I started the port fairly straightforwardly... copy the Ruby code into a Java class, and change the various Ruby-specific keywords to their Java equivalents, and that should be it.
So, I begin to change def to public void/int/boolean, end to }, and removing the @ and : from instance variables and symbols respectively.
It was then I began to realise how much visual clutter Java forces on you. I needed to put the opening brace after every method definition. I needed to add opening and closing parentheses to all my method definitions AND function calls. And don't forget the dear old semi-colon after every line. Nope, we can't use the if/while/unless statement modifiers, so every one of those becomes a full-blown if statement block, complete with all its brace-y goodness.
Just making all the syntax changes was an experience... by the time I was done, my code was noticeably longer, and just seemed much more like code and less readable as a result.
But, the difference between Java and Ruby goes beyond syntax. So, the stage two of the conversion involved changing constructs such as blocks, array sorting, use of hashes etc to Java equivalents. And there was where the true differences between the languages surfaced. You see,he language you use does influence your coding style, by making certain things easier to do. Thus, the natural syntax of hashes make them extremely popular, as Rails can attest to. Of course, the Java equivalent is a huge pile of clunkiness that I don't even want to think about.
The end result is that after the straightforward conversion of standard syntax differences, I actually had to then rewrite logic for the Java version because of its lack of certain Ruby functionality.
That is to be expected, right? I mean, they are different languages after all. Some things will be easier in Ruby than in Java and vice versa, right?
Of course, so far, I've only come across things that are harder in Java than in Ruby. I've yet to find something that Java does better.....
Hmm....
PS. What has me particularly cranky is the fact that in converting some of the Ruby constructs to Java, I broke something, and I'm having a hard time figuring out what. And it's annoying me that I have to go through the same debugging process again in Java that I went through in Ruby....
Monday, December 3, 2007
Programming in Ruby
It's been a while since I've been here.... I know...
Work's been pretty hectic these last few months, and it continues to be so, but I've come to realise that you just have to make time for the things you want to do... because there will ALWAYS be things to do.
I did spend the last week working hard at a computer simulation program for my sister. It's a computer simulation of a networking link, which is actually not really relevant. The key point is that it was a fairly straightforward program... a school project-type thing, which is indicative of the scope. That is, it was a small and straightforward program.
Because of time constraints, and also because I wanted to increase my learning, I developed the program using Ruby... my first test run of Ruby development without Rails.
And I must say, it was an interesting experience.
First, the negative....
There is much talk in the Ruby space about how dynamic languages save you from having to deal with the boilerplate code that is common with static languages (i.e. variable declarations, interfaces et al).
That is very much true. However, what those dynamic language gurus fail to point out is that much of this boilerplate can be provided by the IDE. Granted, it is still visual clutter, but the actual typing is minimized. In fact, that was my biggest gripe with working in Ruby... the comparable lack of help from the IDE. Context sensitive hints are much less effective and focused in the dynamic space, which can actually make you slower compared to Java and its pals.
And of course, the automated refactoring support is much less robust, which means back to manual refactoring. Of course, the fact is that the amount of refactoring that needs to get done is much less, but when you do need an "Extract Method" command, you do miss it.
There is one benefit to the lack of variable type declarations that is not mentioned very often though....
Because a variable can hold anything, it makes variable naming extremely important. You can't infer anything from the variable type, so as the developer, the variable names have to contain all the relevant info... which makes you as the developer much more conscientious about choosing proper variable names to portray all the necessary information. This is especially important in function signatures.
Overall though, the experience was quite pleasant. For the most part, the language did stay out of my way and allowed me to think in the domain rather than in the language. And, the open class structure did prove to be useful as well (I monkeypatched the Symbol class to allow sorting of symbols with minimal effort).
I think those two are the more important features that make Ruby such a pleasant experience: - the well-thought-out standard API, and
- the open classes to enhance any standard class when it doesn't quite fit your needs.
All in all, I think Ruby will be a valuable addition to my toolkit... and is definitely a language worth exploring even outside of the magic that is Rails.
Work's been pretty hectic these last few months, and it continues to be so, but I've come to realise that you just have to make time for the things you want to do... because there will ALWAYS be things to do.
I did spend the last week working hard at a computer simulation program for my sister. It's a computer simulation of a networking link, which is actually not really relevant. The key point is that it was a fairly straightforward program... a school project-type thing, which is indicative of the scope. That is, it was a small and straightforward program.
Because of time constraints, and also because I wanted to increase my learning, I developed the program using Ruby... my first test run of Ruby development without Rails.
And I must say, it was an interesting experience.
First, the negative....
There is much talk in the Ruby space about how dynamic languages save you from having to deal with the boilerplate code that is common with static languages (i.e. variable declarations, interfaces et al).
That is very much true. However, what those dynamic language gurus fail to point out is that much of this boilerplate can be provided by the IDE. Granted, it is still visual clutter, but the actual typing is minimized. In fact, that was my biggest gripe with working in Ruby... the comparable lack of help from the IDE. Context sensitive hints are much less effective and focused in the dynamic space, which can actually make you slower compared to Java and its pals.
And of course, the automated refactoring support is much less robust, which means back to manual refactoring. Of course, the fact is that the amount of refactoring that needs to get done is much less, but when you do need an "Extract Method" command, you do miss it.
There is one benefit to the lack of variable type declarations that is not mentioned very often though....
Because a variable can hold anything, it makes variable naming extremely important. You can't infer anything from the variable type, so as the developer, the variable names have to contain all the relevant info... which makes you as the developer much more conscientious about choosing proper variable names to portray all the necessary information. This is especially important in function signatures.
Overall though, the experience was quite pleasant. For the most part, the language did stay out of my way and allowed me to think in the domain rather than in the language. And, the open class structure did prove to be useful as well (I monkeypatched the Symbol class to allow sorting of symbols with minimal effort).
I think those two are the more important features that make Ruby such a pleasant experience: - the well-thought-out standard API, and
- the open classes to enhance any standard class when it doesn't quite fit your needs.
All in all, I think Ruby will be a valuable addition to my toolkit... and is definitely a language worth exploring even outside of the magic that is Rails.
Sunday, July 22, 2007
My Journey to Behaviour Driven Development
So, I have busy the last couple of weeks hacking away at a pretty large model. It is the primary model used for the entire Time Keeping module in my application, and as such, it needs to contain some significant domain logic.
Initially, in the spirit of having proper testing, I was attempting to use Test::Unit as my testing framework. However, having experienced unit testing in Java, in particular a continuous testing plugin that monitors your project in real-time and indicates failing tests almost immediately, I was compelled to search for the same type of responsive environment while developing in Rails.
The first stop on my journey towards continuous testing took me to the Autotest plugin. This plugin was quite useful in that it monitored your source files, and on each save, it ran the tests (be they functional, unit or otherwise) that may possibly have been affected by your recent changes. And to some extent, this worked... after a few seconds of saving a file, the corresponding tests would run, showing the results in the Test::Unit GUI provided in the RadRails IDE.
Those few seconds of waiting bothered me though. Because of that wait, my development process just felt slower. I felt more anxiety to write a series of tests, rather than one at a time since I could spread that time delay over a larger chunk of development effort. but, it felt 'wrong' to rush ahead too far, since the spirit of unit testing, and specifically Test Driven Development, is to write a test, watch it fail, write just enough to make it pass, and repeat. Writing too many tests at once seemed to go against the spirit.
And so, I began another search... this time to find a way to speed up the time it took for Test::Unit to do its thing. And then I ran across RSpec. In my search, this RSpec project kept coming up...
So, I looked at RSpec... and cringed. I did not want to learn a whole new DSL... a whole new syntax... I just wanted to make my tests run faster. But every search for faster testing seemed to always throw this RSpec system in my face.
Finally, I had enough. I re-directed my research to RSpec, and the accompanying Behaviour Driven Development (aka BDD). I can't say that first (or second or even third) impressions left much of a mark, except for the fact that persons mentioned that the RSpec runner launched faster than Test::Unit.
So, I took the dive, and began using RSpec. And as I got more and more comfortable, I have realised that it has totally changed the way I think about my problems. I am not trying to be dramatic for the sake of drama. But my statement still holds... RSpec changed how I thought about my programming problems.
Typically, when thinking about a problem, I would think about the solution. I would envision how the code for a particular method would work, and then mentally test my proposed solution to see how it stood up. If satisfied, i would begin implementing that solution in code... filling in the blanks that my mind couldn't see. If I weren't satisfied, I would adjust my solution, and 're-test it' again. That was my essential programming technique for small-scale problem-solving.
Analysing my thinking process now though, I realise that now, my first step is to think about the specification of how the method would work. When thinking about the problem, I think of how that method should respond in various solutions. Although I do sometimes think about the actual solution, my focus while thinking is now almost totally on specifying how the solution should work in given scenarios.
The funny thing is that, with proper specifications, the solution, i.e. the internal code of the method, usually becomes obvious.
In other words, the general flow moves away from me trying to come up with tests to verify that some piece of code I am considering towards trying to put into words what that code should do, and then writing the code to comply with those specs.
The funny thing is, the outward difference between BDD and TDD is really non-existent beyond the syntax. However, I realise that BDD, by changing the language that is used, drives you more quickly to the aim of the game.... to develop an executable set of specifications for your code, which also serves as a low-level regression test suite.
PS. I still find that RSpec takes too long to respond to file changes when using the Autotest plugin. However, because of the difference in focus, I tend to write a series of specifications for a small aspect of functionality, and use the resulting error messages to guide me in developing the solution code.
I still would like to find a way to increase the responsiveness of the Autotest... but that's a problem for another day
Initially, in the spirit of having proper testing, I was attempting to use Test::Unit as my testing framework. However, having experienced unit testing in Java, in particular a continuous testing plugin that monitors your project in real-time and indicates failing tests almost immediately, I was compelled to search for the same type of responsive environment while developing in Rails.
The first stop on my journey towards continuous testing took me to the Autotest plugin. This plugin was quite useful in that it monitored your source files, and on each save, it ran the tests (be they functional, unit or otherwise) that may possibly have been affected by your recent changes. And to some extent, this worked... after a few seconds of saving a file, the corresponding tests would run, showing the results in the Test::Unit GUI provided in the RadRails IDE.
Those few seconds of waiting bothered me though. Because of that wait, my development process just felt slower. I felt more anxiety to write a series of tests, rather than one at a time since I could spread that time delay over a larger chunk of development effort. but, it felt 'wrong' to rush ahead too far, since the spirit of unit testing, and specifically Test Driven Development, is to write a test, watch it fail, write just enough to make it pass, and repeat. Writing too many tests at once seemed to go against the spirit.
And so, I began another search... this time to find a way to speed up the time it took for Test::Unit to do its thing. And then I ran across RSpec. In my search, this RSpec project kept coming up...
So, I looked at RSpec... and cringed. I did not want to learn a whole new DSL... a whole new syntax... I just wanted to make my tests run faster. But every search for faster testing seemed to always throw this RSpec system in my face.
Finally, I had enough. I re-directed my research to RSpec, and the accompanying Behaviour Driven Development (aka BDD). I can't say that first (or second or even third) impressions left much of a mark, except for the fact that persons mentioned that the RSpec runner launched faster than Test::Unit.
So, I took the dive, and began using RSpec. And as I got more and more comfortable, I have realised that it has totally changed the way I think about my problems. I am not trying to be dramatic for the sake of drama. But my statement still holds... RSpec changed how I thought about my programming problems.
Typically, when thinking about a problem, I would think about the solution. I would envision how the code for a particular method would work, and then mentally test my proposed solution to see how it stood up. If satisfied, i would begin implementing that solution in code... filling in the blanks that my mind couldn't see. If I weren't satisfied, I would adjust my solution, and 're-test it' again. That was my essential programming technique for small-scale problem-solving.
Analysing my thinking process now though, I realise that now, my first step is to think about the specification of how the method would work. When thinking about the problem, I think of how that method should respond in various solutions. Although I do sometimes think about the actual solution, my focus while thinking is now almost totally on specifying how the solution should work in given scenarios.
The funny thing is that, with proper specifications, the solution, i.e. the internal code of the method, usually becomes obvious.
In other words, the general flow moves away from me trying to come up with tests to verify that some piece of code I am considering towards trying to put into words what that code should do, and then writing the code to comply with those specs.
The funny thing is, the outward difference between BDD and TDD is really non-existent beyond the syntax. However, I realise that BDD, by changing the language that is used, drives you more quickly to the aim of the game.... to develop an executable set of specifications for your code, which also serves as a low-level regression test suite.
PS. I still find that RSpec takes too long to respond to file changes when using the Autotest plugin. However, because of the difference in focus, I tend to write a series of specifications for a small aspect of functionality, and use the resulting error messages to guide me in developing the solution code.
I still would like to find a way to increase the responsiveness of the Autotest... but that's a problem for another day
Thursday, July 12, 2007
The Inaugural Rails Post
I've started doing some research on Ruby on Rails, and I must say, I'm impressed... so much so, that I decided to create a semi-major application in it to observe what the experience would be like. So, this is going to be my Rails Journal, so to speak.
What is the application I am building? Well, with the aim of not disclosing too much and getting myself in trouble, it's a client-server application that allows employees to interact with the HR department. The original version of the application was actually a web app, built using Coldfusion, and recently, my company was contracted to build a new version of the application using a development tool called Servoy. Unfortunately, the experience wasn't the most pleasant.
My aim is to attempt to rebuild that same application using Rails, as a way of determining whether Rails is suitable as a platform for our company's development projects moving forward. Thinking about it logically, I believe Rails is ready and capable, but I'd have a hard time convincing my boss to give it a try without something concrete to use as proof. And hence, HR on Rails was born (for lack of a better name for my project).
In a way, this project will actually be quite a good test as to the viability of Rails. I was not present for the building of the original system in Coldfusion, nor was I part of the current project when most of the ground-work was being done. By the time I joined the project, most of the infrastructure was already set up so that I don't have any experience in building the majority of the applcation. Thus, in Rails, I will have to come up with a base infrastructure myself. As well, since each member of the development team was solely responsible for a specific module, I don't have any experience in developing the functionality of any particular module beyond my own. So, I'll be getting the full Rails experience by being forced to create most of the application's functionality from scratch. At the same time, my familiarity with my own module will help serve as a launching point for creating functionality, once I get past infrastructure set-up.
So, I intend to write about my journey through Rails, as I bring HR on Rails from concept to reality. Hopefully, it will be a fun ride...
What is the application I am building? Well, with the aim of not disclosing too much and getting myself in trouble, it's a client-server application that allows employees to interact with the HR department. The original version of the application was actually a web app, built using Coldfusion, and recently, my company was contracted to build a new version of the application using a development tool called Servoy. Unfortunately, the experience wasn't the most pleasant.
My aim is to attempt to rebuild that same application using Rails, as a way of determining whether Rails is suitable as a platform for our company's development projects moving forward. Thinking about it logically, I believe Rails is ready and capable, but I'd have a hard time convincing my boss to give it a try without something concrete to use as proof. And hence, HR on Rails was born (for lack of a better name for my project).
In a way, this project will actually be quite a good test as to the viability of Rails. I was not present for the building of the original system in Coldfusion, nor was I part of the current project when most of the ground-work was being done. By the time I joined the project, most of the infrastructure was already set up so that I don't have any experience in building the majority of the applcation. Thus, in Rails, I will have to come up with a base infrastructure myself. As well, since each member of the development team was solely responsible for a specific module, I don't have any experience in developing the functionality of any particular module beyond my own. So, I'll be getting the full Rails experience by being forced to create most of the application's functionality from scratch. At the same time, my familiarity with my own module will help serve as a launching point for creating functionality, once I get past infrastructure set-up.
So, I intend to write about my journey through Rails, as I bring HR on Rails from concept to reality. Hopefully, it will be a fun ride...
Amazed by the new 'Web'
I've become a bit of a Google fan-boy these days...
Just recently, I configured my work email to be accessible via Gmail and having used that web client for a while, along with this 'Blogger' system, I must say... we've come a long way. It is truly amazing how the Web has been transformed.
I mean, a lot of people don't seem to have any appreciation as to just how far we've come with regards to website interactivity in general... this being especially true for those who are relatively new to the online experience.... after all, this is all they know. But, things have truly come a long way.
My boss and I have been having a continuous argument about the future of software development. "The world of desktop applications is dead - everything will soon be on the Web, " he claims. When I first heard him say it, I thought it was a blanket statement that couldn't possibly be true. After all, we all know that the Web, despite the attractiveness of accessibility from any machine, is still a slow and clunky experience in comparison to desktop software. Yes, there is an abundance of uses for web applications, especially in the corporate world, but there are still many things that can't be done effectively on the web. Or so I thought...
I can see his point of view much better now, having spent some time using Gmail and Google Reader.... Gmail, in particular. And I must say... I am impressed. In fact, I dare say that, in comparison to a desktop email client like Thunderbird, I actually prefer the Gmail experience. What I've realised is that this new Web (the Web 2.0, as they call it) is changing the game. It's not so much that Web software moving closer to desktop software in terms of functionality... it's that Web software is actually changing the whole UI metaphor... and it's for the better.
Don't get me wrong... I love desktop software. But I find myself being drawn to Web software more and more. And it's not like my driving reason is because of the mobility - for the last 8 or 9 months, I've been using a single laptop for work and at home almost exclusively. However, the interactivity.... in particular, the difference in interactivity... dare I say, the improvement in interactivity of Web software vs. desktop software is truly drawing me in.
As I said.... we've come a long way....
Just recently, I configured my work email to be accessible via Gmail and having used that web client for a while, along with this 'Blogger' system, I must say... we've come a long way. It is truly amazing how the Web has been transformed.
I mean, a lot of people don't seem to have any appreciation as to just how far we've come with regards to website interactivity in general... this being especially true for those who are relatively new to the online experience.... after all, this is all they know. But, things have truly come a long way.
My boss and I have been having a continuous argument about the future of software development. "The world of desktop applications is dead - everything will soon be on the Web, " he claims. When I first heard him say it, I thought it was a blanket statement that couldn't possibly be true. After all, we all know that the Web, despite the attractiveness of accessibility from any machine, is still a slow and clunky experience in comparison to desktop software. Yes, there is an abundance of uses for web applications, especially in the corporate world, but there are still many things that can't be done effectively on the web. Or so I thought...
I can see his point of view much better now, having spent some time using Gmail and Google Reader.... Gmail, in particular. And I must say... I am impressed. In fact, I dare say that, in comparison to a desktop email client like Thunderbird, I actually prefer the Gmail experience. What I've realised is that this new Web (the Web 2.0, as they call it) is changing the game. It's not so much that Web software moving closer to desktop software in terms of functionality... it's that Web software is actually changing the whole UI metaphor... and it's for the better.
Don't get me wrong... I love desktop software. But I find myself being drawn to Web software more and more. And it's not like my driving reason is because of the mobility - for the last 8 or 9 months, I've been using a single laptop for work and at home almost exclusively. However, the interactivity.... in particular, the difference in interactivity... dare I say, the improvement in interactivity of Web software vs. desktop software is truly drawing me in.
As I said.... we've come a long way....
Popping My Cherry
Well, this is my welcoming call to the world of 'Blogging'. It's quite anti-climatic, if you ask me.
Of course, I am no stranger to the whole 'let's talk about me' phenomenon - I've been keeping a fairly regular journal of my rather mundane life since 2000... it's now a 1100+ page monster that seems to hang Word on a regular basis... so much so that recently, I've have to split it into two out of frustration.
Come to think of it, my history with journals hasn't really been the best... specifically when it comes to letting others read the crazy things that go on in my mind.
(I've allowed two ex-girlfriends to look through it, with the same end result... they getting pissed about something I've written. In fact, that might actually be a major contributing cause to their 'ex' status... it's a funny thing about women... they claim to want honesty, but the reality is that, at least in my experience, they don't respond that well to it. But I digress...)
With that type of history, why in the world would I want to start a blog? When I figure out the answer to that one, I'll get back to you....
Of course, I am no stranger to the whole 'let's talk about me' phenomenon - I've been keeping a fairly regular journal of my rather mundane life since 2000... it's now a 1100+ page monster that seems to hang Word on a regular basis... so much so that recently, I've have to split it into two out of frustration.
Come to think of it, my history with journals hasn't really been the best... specifically when it comes to letting others read the crazy things that go on in my mind.
(I've allowed two ex-girlfriends to look through it, with the same end result... they getting pissed about something I've written. In fact, that might actually be a major contributing cause to their 'ex' status... it's a funny thing about women... they claim to want honesty, but the reality is that, at least in my experience, they don't respond that well to it. But I digress...)
With that type of history, why in the world would I want to start a blog? When I figure out the answer to that one, I'll get back to you....
Subscribe to:
Posts (Atom)