While checking out the search engine terms to my blog, I found an interesting one there: “why so many programming languages?” A great question indeed. If you take a look at the Wikipedia page on programming languages, you will be surprised by the number of programming languages today. To give you a hint, the languages are categorized into different sections by their first letters. When I browsed the page, I found most of them were new to me and will definitely remain so in the future.
After Java 6.0 released in 2006, it’s been 5 years during which Sun Microsystem was sold to Oracle. Today the 7.0 is finally GAed. It includes quite a few changes including small language changes as well as new and improved APIs.
The language changes are mostly small and may not affect you, for example, the switch statement now works with strings. The new try-with-resource statement, which is similar to using statement in C#, helps you with cleaner code, see the difference shown in the following
As software engineers, we most likely have learned the three key characteristics of object oriented programming: inheritance, encapsulation, and polymorphism. Over the years I study and practice OOP, I realized that inheritance is out of date and arguably misleading, therefore should be replaced.
In OOP, inheritance refers to a relationship between two classes in which a subclass inherits the properties and methods of its super class. The term inheritance is not really a good one because
During last 60 some years after computer was invented, there have been hundreds, if not thousands, programming languages. If we include domain specific language (DSLs), which accorinding to Martin Fowler may include regular expression, spreadsheet, etc, the number can be even bigger, not to mention more programming languages continue to emerge.
This would be a big burden if we have to learn all of them. Luckily, we don’t have to. In fact, most of us just need to learn several most popular ones. Even better, these popular languages may look very similar in syntax. As a result,
In object-oriented programming, static methods are the methods that are defined with static keyword. They don’t have access to non-static instance variables. This very limitation can be an easy cure for many programming pitfalls I’ve seen over the years.
- A static methods prevents you from using instance variables for passing information around, for example, as parameters to or as result from it. As a general rule, you should not define an instance variable if it’s not an intrinsic property of a class or type. It may seem obvious,
I have been reading Martin Fowler’s book Domain-Specific Language during last two months. Now I am not fully done with the book but have a good idea because the rest of the book is about individual DSL patterns, which I think are better read when used.
I got two key points from the book. One is that the key to DSL is semantic model (“The semantics of a program is what it means – that is, what it does when it executes”). You can implement semantic model as APIs/frameworks in system languages like Java. If you are confused by the question, “what is the difference between DSL and normal code on top of high level APIs?
There have been long debates on whether object oriented is the future of programming. Repeating it over here doesn’t make it any clearer. As you can tell from my blog, I am an OO bigot because it can significantly improve productivity. If you are not convinced about OO benefit, you can look around those top programming languages mostly support OO these days.
By reviewing the whole software lifecycle, however, you will find a gap between requirements and OO programming today. While describing application requirements, a business user almost always describe them in a number of steps (procedural). It’s not realistic to expect requirements described in an OO way. While developing, programmers write and see classes and objects.
How to bridge the gap between the procedural requirements and object oriented programming? It basically boils down how to
While reading the recent Dec 2010 issue of MSDN magazine, I found an article (Multiparadigmatic .Net, Part 4: Object Orientation) with misunderstandings on object oriented design. I was surprised that the author reached conclusions like, “squares aren’t rectangles,” and “no happy ending here.” The conclusions are based on misunderstandings of object oriented design.
Let me show you what the root problem is and how to get a happy ending. After reading this, you won’t be bothered by “squares aren’t rectangles.”
What’s the problem?
As most people already know, inheritance or generalization (I prefer the latter) is an important feature of OOD. Using it effectively can lead to a good object model and concise codebase. In an inheritance relationship, a subtype must maintain “IS-A” relationship with its super type, for example, a Student type IS-A Person. I think most people are just fine with this.
When a developer learns a new programming language or API, the first thing is probably to try out a HelloWorld sample. As said, real programmers don’t read documents. Although I don’t fully agree on that, it has some truth in it.
In my own experiences, I normally continue with other samples after HelloWorld one. When something is not quite clear, I check out the API reference or read some tutorials. Anyway, I am not telling you how to learn a new language or API, but trying to make a point here on the importance of code samples for the developers. In my opinion, samples are the most effective way to empower your users.
I think you would agree with me, there are too many bad samples. Here are some typical symptoms:
- Too much boilerplate code to a point that the code illustrating the API usage got buried. Typical boilerplate code includes extensive exception handling, GUI, logging, etc. Some samples even have a common library that could confuse your users totally.
- Too many API calls in one sample. You may need several APIs for a use case, but don’t aim one sample for multiple use cases.
- Too much object oriented. Object oriented programming is a best practice for application development. But it could confuse your developers sometimes.
- Dependencies on other APIs. To run the sample, your users need to install other libraries which may or may not need extra configuration or tuning. To understand the sample, users need to understand additional APIs. Extra burden, really!
- Of course, typical bad smells of programming which are not unique for samples. For example, bad naming, unnecessary global variables, using object attributes for passing values between methods, etc.
Now, how you can develop great samples? Besides the best practices writing great applications, you want to follow the following guidelines:
Just came back from a SDForum meeting organized by its emerging technology SIG. The topic was about the 4 languages in the title. It’s not much about any emerging technology per se, but pretty controversial among the developers.
The organizers invited four panelists and one moderator:
- Clojure advocate – Amit Rathore, author of the forthcoming “Clojure In Action”
- Go advocate – Robert Griesemer, Google, co-author of Go
- Scala advocate – David Pollak, lead author of Lift
- Ruby advocate – Evan Phoenix, lead developer of Rubinius, a high performance Ruby VM
- Moderator – Steve Mezak, co-chair of the SDForum Software Architecture and Modeling SIG, author of Software without Borders
Each of the panelists had 10 minutes of introduction of the language in the first part. Then, they all answered questions ranging from language strength/weakness, library/tool/IDE support, application framework, advice on migrating existing codebase, to how these languages compare to each other.
Here are introductions from the languages’ homepages. See if you can map them to the languages.