Back in the old days when dinosaurs were the rulers of the Earth and mankind was still far to come, PL/SQL was one of the funkiest languages a developer could have: it allowed you to perform any sort of complex operation on your data without leaving your DBMS (typically, the big creepy Moloch known as Oracle).

Back then, hardware performances were worse than crap (think about Moore’s law and apply it to ages ago), so any possible room for optimization had to be explored and performing operations on data without converting it to programmer-friendly format was more of a commitment than a choice.

After a while, the natural process of language evolution came in and many factors determined PL/SQL’s obsolescence, the most notable being the paradigm shift from procedural languages to object-oriented languages and the natural process that tends towards higher level abstractions as time goes by, along with the emerging need of appealing GUIs and multi-tiered systems which made it impossible to have entire, complex applications made out just of data-processing logic.

Nowadays, then, PL/SQL has been replaced by ORMs such as Hibernate (and its brother NHibernate) or Ibatis, even if some dinosaurs who can’t accept the change still exist: performance issues due to data conversion from DB to OO data types aren’t a concern thanks to the increase in hardware performances and ORMs allow the funky developers to intentionally ignore the underlying logic of the DBMS, which is topic for the DBAs, and focus on business objects, thus providing a higher level of abstraction.

As of today, then, the typical OO programmer isn’t required to write complex PL/SQL stored procedures that need thousands of LOC just to perform CRUD operations (ideally, he shouldn’t be required to write even the simplest of SQL queries thanks to the ORM layer sitting between him and the DBMS, but sometimes knowing SQL for a quick check on the DB can still help) and is now able to handle data in the most comfortable way, which is the object-oriented way.

(Note: the “Why (PL/)SQL sucks and you should use an ORM” topic is extremely wide and isn’t the main topic of this post, so we won’t go any further on this which is just an example)

Back in the early days of web development, developers were required to write massive amounts of monkey code: think of huge layouts made of tables, hundreds of thousands of lines of CSS to fix every possible browser quirk (don’t forget IE4!) and javascript code filled with document.getElementById and document.getElementsByTagName, all written by hand (don’t get me started on those deadly technologies that mix server-side business logic and presentation html, such as JSP and poorly-written PHP…you just need to know that those who practice these criminal activities should burn in hell).

Now think of those monsters you probably have seen in museums that look like DECLARE FOO (BAZ AS INTEGER, QUUX AS VARCHAR) AS PACKAGE, DECLARE PACKAGE BODY FOO, BEGIN, /*250 LOC to perform 2 queries, possibly with proprietary DB commands */ END…any similarity?

This is low-level, and low level is bad.

Why?

Low level == more lines of code == more space for bugs.

Low level == less space for abstraction == less time to focus on application logic and more time spent on trivial operations

In general, when you have to write low level, boilerplate code the best solution is to have someone else write it for you, and i’m not meaning offshoring.

The quick, dirty and oldschool solution is using a WYSIWYG editor that writes code according to what you specify visually, but it still produces a huge amout of code, which sometimes isn’t really the best you could get (it seems impossible, but there are websites made with FrontPage!) and still needs to be scanned through when debugging, so the best solution would be to have someone trusted to write code in a black box way such that you don’t need to see it…after all, who cares about how Hibernate performs his transformations from Criteria queries to SQL? It works, and it’s as much as i want to know.

HTML has been providing a higher level abstraction for quite a long time now: the DOM.

Just as Hibernate lets you handle DB data as objects, the DOM allows the funky developer to handle the HTML structure of a web page in an object-oriented way, as if it was a tree.

This is already quite funky, but the Javascript DOM API isn’t perfect (document.getElementById isn’t a perfect way to refer to a single element in a page, come on), so another level of abstraction was required.

A vanilla abstraction may be represented by all those funky Javascript frameworks that provide nice and clean APIs to perform complex tasks such as animation or drag&drop, but they still leave you unprotected from the evil beasts of CSS hacking: a good abstraction would let the developer abstract (exactly) from these implementation details allowing him/her to focus on what really matters in his/her application, i.e. business logic.

The question, now, is “are there any abstractions of this kind?” and the answer, luckily, is “yes”.

There are frameworks, such as GWT or Echo2, that allow the developer to write Java code as if he/she was writing a desktop application, but the output is valid and working XHTML+CSS+Javascript that autonomously deals with OS issues, browser quirks and any other display of Satan’s existence in the real world.

“But i don’t know Java, i only know HTML, CSS and Javascript!”

Ok, you can sit there, in the back row, next to the PL/SQL dinosaurs.