Programming Languages

What programming language should I learn, a link I found on Twitter (like most of the other things I seem to find, nowadays) is a nice list and a good map for some one who is learning languages and looking for experimenting more.

I think for each language we can add a set of additional reasons – for example:

php – any work on mediawiki, drupal, joomla etc.
c# – any work on web parts, dotnet components, silverlight RIA
python – any work on django, nltk, machine learning, Plone, zope

In addition, I would add these languages. They are on my list to play around with and build a few prototypes (not sure when I get to them, though)

Boo – A python inspired language for writing DSLs (domain specific languages)
L Sharp or Lisp or Scheme – A list based language for learning programming
Squeak – A small talk based language for building delightful interactive applications
Berkeley Logo – For simulations, nothing beats this lisp inspired language
Prolog – for building logic programs and expert systems (though expert systems are fading away with machine learning based languages)
Haskell – Seems to be catching fire and may be one of the preferred languages for building multi-core apps
Erlang – Another language for building highly robust, scalable, multi-core apps
AIML – Artificial Intelligence Markup Language for buidling chat bots (even has a python AIML engine). Currently working with a student to build a chatbot for SugarCRM
SPARQL – A semantic web query language (easy if you already know SQL)
RDF and OWL – Not really languages in the conventional sense but I consider them as data languages

After writing all this, I decided to put this in my blog since it is worth remembering and updating them.

When I watch some videos on Lisp/Scheme, I understand why Lispers are so religious about their language. I have not seen more efficient/concise ways of solving problems or clarity of concepts.

When the Web Becomes a Database

This was what we were dreaming about 7 years ago. This image is taken from the home page of our first web site (Feb 23, 2001), still sitting on the internet archive.

That is a bit of a background. You know why I got excited when I saw this article.

Every time there is a major shift in technology, this shift needs to be motivated by addressing a new class of problem. This means doing something that could not be done before. The last time this happened was when the relational database became the dominant IT technology. At that time, the questions involved putting the enterprise in the database and building a cluster of Line Of Business (LOB) applications around the database. The argument for the RDBMS was that you did not have to constrain the set of queries that might later be made, when designing the database. In other words, it was making things more ad hoc. This was opposed then on grounds of being less efficient than the hierarchical and network databases which the relational eventually replaced.

Today, the point of the Data Web is that you do not have to constrain what your data can join or integrate with, when you design your database. The counter-argument is that this is slow and geeky and not scalable. See the similarity?

A difference is that we are not specifically aiming at replacing the RDBMS. In fact, if you know exactly what you will query and have a well defined workload, a relational representation optimized for the workload will give you about 10x the performance of the equivalent RDF warehouse. OLTP remains a relational-only domain.

I started my career working with CODASYL based network databases (DBMS-11 to be precise) in 1978. Then we built a composite database (part network, part relational) in 83 and a SQL engine in 85-86. Computing was very different then. Relational databases had a slow start but once the performance improved (due to improvements in relational technology and hardware speeds), they took off.

Almost 20 years later, after the first commercial relational databases started becoming mainstream, we need to rethink data and access to data. The scale is different. The needs for access is different. What we need to get out of databases is going to be very different.

Along the way, there were attempts at extending relational databases in different directions (text databases, multi-media databases, object databases) but none of them had either the simplicity or elegance of relational databases.

What are some possible technologies for the new databases of the future? This article provides some insights.

However, when we are talking about doing queries and analytics against the Web, or even against more than a handful of relational systems, the things which make RDBMS good become problematic.

It is worth watching this space, especially, if you make a living working with relational technology. When the web becomes a database (even parts of it), there will be lots of challenges and hence lots of new opportunities.

LinkLog: Semantic Web

Semantic Web from A Chat with Dave Beckett

Semantic Web…it’s about connecting things together, about getting the jobs done

If every one uses the semantic web data formats, they all connect together.

I think data centric approach is better than API centric approach, because the data will live longer than APIs.

The Semantic Web in one slide from POWDER – Smarter Navigation On The Web

• Allows machines to process the meaning of data

• Data is distributed and extensible

• Machines can automatically deduce facts and relationships

• (which means you can offer users more of what they want and less of what they don’t want)