I wanted to install and play with Hadoop. I started by installing cygwin, then swung on over to Cloudera's image on vmware. I must confess I have a short amount of patience when it comes to implementing things that I am having difficulty with.
It is hard for me to deny the viability of Hadoop but I am having some heartburn over the difficulty in implementing it to the point where I can start playing around. I am not trying to implement and scale multiple clusters. I just want to install it so I can create a few map reduce jobs and get my feet wet.
Anyhow, this adventure took me to installing virtual box and then the Ubuntu 12.10 image on one of my laptops. Virtualbox is a breeze to install. Ubuntu was also easy to implement on virtualbox. I was also impressed with the ease of installing software on Ubuntu. I was so impressed with Debian's get-apt that I ended up installing the full LAMP stack and then headed off to install the 1.6 JRE and SDK. I got so into the ease of implementing software I went off and installed Ruby and Rails, as well as a number of IDE's.
I never did get around to installing Hadoop.
I must confess I am a web developer who uses WAMP and pretty much deploys off to LAMP. As such I am not much of a Linux person. I am impressed with the ease of working with Ubuntu. If you are a Windows developer looking at dipping your foot into the Linux waters I would recommend Virtualbox and Ubuntu.
Monday, February 11, 2013
Saturday, February 2, 2013
Elegant Programming Language?
In a recent thread I was participating in the inevitable language A is more elegant (better, pick another adjective) than language B sidebar broke out. I did not directly participate in this sidebar as this topic does not really fit my world view of the subject.
Here is why...
While I agree some hammers are better than others, ultimately the hammer is as good, bad or somewhere in between depending on whose hands it is in. And to this you may argue that the very best hammer in the hands of a great carpenter is ideal. I would not disagree. But, if you argued that same hammer in the hands of a klutzy homeowner makes them better, that to me is a much tougher sell.
Of course languages are a tad more complicated than my hammer analogy. As I have watched the evolution of programming languages we try to create that "silver-bullet" language but we invariably miss the mark. Likely we always will, though by no means am I suggesting that we stop trying.
Take Java for instance. Some of the filthiest most convoluted code I have seen in any language has been produced in this language through the gross misuse of interfaces. Simply put an interface in Java is an abstract concept/template that requires the implementer to define all of the underlying method stubs (to use a term all can understand) at design time.
Without diving too much further into this subject I want to add that knowing all the methods one will need for a given interface at design time that will hold true for the use of an interface through the software development lifecycle is a difficult thing to determine. Further, an interface establishes a contract with the user of the interface that says if you want to use my interface you need to declare all the methods that are in the interface in your class whether or not you intend to use them! If properly created an interface creates a piece of coding elegance that allows one to achieve both polymorphism and encapsulation at the same time. It also create a uniform consistency across the users of the interface.
Polymorphism is a rather obtuse terms so let me offer an example. I want to implement an interface for a heating control thermostat. It will have two methods, 1) check temperature, 2) change temperature. Polymorphism is a concept that essentially says I do not care what type of heating system I am connected to (Natural Gas, Electric, Wood, Coal) these two methods are applicable and work exactly the same as far as the interface consumer using them is concerned. It is elegant in the respect that the user does not have to be concerned with the underlying implementation details as to how these methods interact with the varying underlying infrastructure.
An interface when properly constructed can be a zen-like thing of sheer beauty and elegance... that is until I need to add a new method body to the interface.
The moment I deploy an interface for others to use I essentially am locked into a contract that does not allow me to extend the interface without breaking the code of those that are using my interface. So what ends up happening is a) I just brazenly extend my interface and tough luck to you, go fix your code, b) I end up deprecating my interface and creating a new one which adds more complexity to the API, c) I extend the interface by adding abstract classes and other interfaces beneath my interface that can more times than not end up being ravioli code (The OOP version of spaghetti code).
I can tell you (and frankly if you are a Java program and are being truthful you can tell me in return) countless tales of encountering many "nightmare on interface street" scenarios. But, I still think an interface is an elegant programming construct. I also contend that an interface in the hands of someone that does not understand how to properly implement one is anything but elegant.
Now, as another much quicker example. I am a big fan of Php. Many developers like to bash the language for not being elegant. I have written a great deal of elegant code using that language. I would also admit that Php does have a number of warts and omissions. As a notable omission, I am huge fan of overloaded methods/functions. I think it is one of the most elegant programming abstractions ever invented. What one has to do in Php OOP to achieve an overloaded method is so convoluted and unnatural it is essentially not usable. Not at all elegant.
So I pose these questions as food for thought.
Can we say a programming language is not elegant because hacks can come along and use it in a way that was never intended?
Can we say a programming language is not elegant because it is missing features and functionality or has some warts or anomalies as it evolves over time?
Elegance and beauty always remain in the eye of the beholder. I have seen elegant code written in Cobol which I do not consider an elegant language. I have seen monstrosities written in Java which I consider an elegant language.
In the end we will continue to have these discussions, and developers will continue to invent new languages that are meant to be the next panacea. This all is a good thing.
Here is why...
While I agree some hammers are better than others, ultimately the hammer is as good, bad or somewhere in between depending on whose hands it is in. And to this you may argue that the very best hammer in the hands of a great carpenter is ideal. I would not disagree. But, if you argued that same hammer in the hands of a klutzy homeowner makes them better, that to me is a much tougher sell.
Of course languages are a tad more complicated than my hammer analogy. As I have watched the evolution of programming languages we try to create that "silver-bullet" language but we invariably miss the mark. Likely we always will, though by no means am I suggesting that we stop trying.
Take Java for instance. Some of the filthiest most convoluted code I have seen in any language has been produced in this language through the gross misuse of interfaces. Simply put an interface in Java is an abstract concept/template that requires the implementer to define all of the underlying method stubs (to use a term all can understand) at design time.
Without diving too much further into this subject I want to add that knowing all the methods one will need for a given interface at design time that will hold true for the use of an interface through the software development lifecycle is a difficult thing to determine. Further, an interface establishes a contract with the user of the interface that says if you want to use my interface you need to declare all the methods that are in the interface in your class whether or not you intend to use them! If properly created an interface creates a piece of coding elegance that allows one to achieve both polymorphism and encapsulation at the same time. It also create a uniform consistency across the users of the interface.
Polymorphism is a rather obtuse terms so let me offer an example. I want to implement an interface for a heating control thermostat. It will have two methods, 1) check temperature, 2) change temperature. Polymorphism is a concept that essentially says I do not care what type of heating system I am connected to (Natural Gas, Electric, Wood, Coal) these two methods are applicable and work exactly the same as far as the interface consumer using them is concerned. It is elegant in the respect that the user does not have to be concerned with the underlying implementation details as to how these methods interact with the varying underlying infrastructure.
An interface when properly constructed can be a zen-like thing of sheer beauty and elegance... that is until I need to add a new method body to the interface.
The moment I deploy an interface for others to use I essentially am locked into a contract that does not allow me to extend the interface without breaking the code of those that are using my interface. So what ends up happening is a) I just brazenly extend my interface and tough luck to you, go fix your code, b) I end up deprecating my interface and creating a new one which adds more complexity to the API, c) I extend the interface by adding abstract classes and other interfaces beneath my interface that can more times than not end up being ravioli code (The OOP version of spaghetti code).
I can tell you (and frankly if you are a Java program and are being truthful you can tell me in return) countless tales of encountering many "nightmare on interface street" scenarios. But, I still think an interface is an elegant programming construct. I also contend that an interface in the hands of someone that does not understand how to properly implement one is anything but elegant.
Now, as another much quicker example. I am a big fan of Php. Many developers like to bash the language for not being elegant. I have written a great deal of elegant code using that language. I would also admit that Php does have a number of warts and omissions. As a notable omission, I am huge fan of overloaded methods/functions. I think it is one of the most elegant programming abstractions ever invented. What one has to do in Php OOP to achieve an overloaded method is so convoluted and unnatural it is essentially not usable. Not at all elegant.
So I pose these questions as food for thought.
Can we say a programming language is not elegant because hacks can come along and use it in a way that was never intended?
Can we say a programming language is not elegant because it is missing features and functionality or has some warts or anomalies as it evolves over time?
Elegance and beauty always remain in the eye of the beholder. I have seen elegant code written in Cobol which I do not consider an elegant language. I have seen monstrosities written in Java which I consider an elegant language.
In the end we will continue to have these discussions, and developers will continue to invent new languages that are meant to be the next panacea. This all is a good thing.
Subscribe to:
Posts (Atom)