on Jan 14th, 2009New Programming Paradigms
Over the last two or three years, I have seen introduction of many new psuedo programming languages(if I can call it that) that help users build applications over the web. Most of these languages are built to work with or as a service. I shall wildly switch between a web service and also the langauge to interact with that webservice; so get the message when I switch from one to another. Let me take one of these languages called YQL. A sample instruction would look like this:
/* Get the latest 10 photos from flickr where the photo name contains cat */ SELECT * FROM flickr.photos.search WHERE text='Cat' LIMIT 10
As you can clearly see the language makes querying a service and receiving its response really really simple. This is how most new psuedo languages are. They work with service end points and emulate an existing programming language’s syntax to do that. These languages are built with mashup’s in mind. The dangers of such an offering are already imminent. Services are good as long as they are up and live. Take for example any of the Google or yahoo Api’s and you will find wrappers written by people in such pseudo langauges to make your life simple. Even in the enterprise space there are such languages being built which query custom services and makes building applications really really simple.
Another observation of mine involves loose typing in these languages. Most new languages are loosely typed. Most of them take from python which lets the user take care of the typing. SQL by far has been the most emulated language amongst these pseudo langauges. Take for example JoSql to add SQL like capabilities to operations like file handling or Linq in .NET which exposes a sql like interface to datastructures. These improvisations have dramatically reduced time to turn ideas into code and rapidly prototype the application.
There are limitations to using such improvisations; some that even I can vouch for. Loosely typed and unstructured languages are good as long as you are not working on large scale systems. If you are hacking up a solution to a problem that you are facing, these pseudo languages look to be real problem solvers but when it comes to working in teams, projects that need to go into production, you start getting into big problems. Though I am a python fanboy, I faced problems when I was working on python and perl on a large project with a team. Interfaces would be unclear, poor documentation would literally spell doom and tons of other problems that we never thought we would face. There are others who complain of the very same thing. I am guessing we will see a flood of such languages in the future thanks largely to applications evolving slowly into services and it will be difficult to guage the quality of these services. Twitter’s API tried to make their service more stable but the mechanism they chose didn’t satisfy many developers. Lets hope we figure out a way to make these more reliable and stable. I guess its the developers call to be judicious about what language and service to choose when building applications.
New Programming paradigms http://is.gd/fOCO
I agree with the pitfalls that you have mentioned. Designing a large scale system with such languages saves time but it puts in an undesired amount of hand waving. The most definite problem is in maintaining such code … 3 days is the limit within which you will understand your own perl/python codes … if you have to debug a perl code written by someone else then all the best to you …
Although, the trend of using these languages for something beyond an initial prototype is, IMO, in colleges and maybe small companies, particularly start-ups. I haven’t seen big players falling for them. What do you think?
Large companies still prefer to user Perl and python for serving front ends and also some back end code. Maybe the programmers that these companies can afford are bloody brilliant or they have found out new ways of testing and maintaining perl code and have good project docs and stuff. From what I heard, some critical and large systems are still built using Java or C++ and python or Perl interfaces to these are exposed.
[...] [...]