Archive for category high-level and philosophy
is HTML the new PL/SQL?
Posted by Raibaz in high-level and philosophy, languages on March 6th, 2009
Funkiness rating
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.
There is no silver bullet
Posted by Raibaz in high-level and philosophy, tools on March 4th, 2009
Funkiness rating
As every good developer knows, there is no silver bullet in software development: no language, framework or toolkit can solve any problem, and a big deal of the effort required for any task depends on the choice of the right tool.
This may seem evident in ordinary construction (or is there anybody who would use a screwdriver to cook pizza?), but when it comes to software it’s often easy to be biased by previous experience or personal, religious views.
Even worse, the wrong tool choice may be imposed by management: usually it’s a former-programmer-now-become-manager who forces the whole development team to use his favourite language/framework/toolkit/set of practices, ignoring that the word “former” in his role means his knowledge is, at best, outdated (this is the reason why young coders are still being forced to learn vintage technologies such as PL/SQL or JSP).
As common knowledge says, anyway, management and the funky developers speak different languages, so what we call “silver bullet” in management-ese sounds like “enterprise”: it doesn’t matter if your tool is right or wrong for your problem, if it will speed up your coding or will sit between you and a delivered project waiting to be dribbled, what usually matters to the pointy-haired bosses is if it’s “enterprise” (which probably means every pointy-haired boss in the world has a secret passion for Star trek).
Let’s pick a real world class of problems as an example: CMSs.
According to Wikipedia, a CMS is “A content management system (CMS) is a computer application used to create, edit, manage, search and publish various kinds of digital media and electronic text”, which seems pretty straightforward and not enterprisable; do we really need an enterprise technology to efficiently setup a CMS-based website?
Short answer: no.
Long answer: no, and let’s see why using the most famous Java-based CMS around, OpenCMS.
(Note: in case somebody didn’t know, “enterprise” and Java are almost synonyms)
OpenCMS is the typical, almost paradigmatic case of a tool that keeps on growing in size and complexity to be as enterprisey as possible until it becomes a giant Moloch that stands in the funky developer’s way instead of letting him run freely through his own path towards a working project.
Let’s think of the most common operation you might want to do on your customized CMS: developing your own module.
Typically, a CMS module is a small snippet of dynamically generated HTML dropped in your pages, whose content is usually generated by server-side scripting; usually, CMS modules aren’t very big in terms of lines of code and computational cost, because they constitute just a small part of the page which is (as the “C” in “CMS” may suggest) focused on its main content.
So, developing a custom CMS module shouldn’t be an enormous project and thus it shouldn’t require most of the infrastructure required by medium-to-large sized software projects: what is really needed to develop a custom CMS module is a good text editor (an IDE may even be too much) and a quick and easy way to test quick and easy modifications to the source code.
OpenCMS provides a built-in text editor and WebDav support to import and export modules via http, which works in combination with the Eclipse WebDav plugin to allow importing and exporting to and from your Java IDE.
Sounds cool, isn’t it?
Unfortunately, the built-in editor looks like this:
OpenCMS Screenshot
(click image to see it full-size. Warning! May damage eyesight)
which makes it completely unusable.
Using WebDAV on an OpenCMS website, instead, requires an afternoon of configuration tweaking to your application server to be set up, and another afternoon of tweaking your Eclipse environment to reach a wonderful speed of 1 shortcut + 5 clicks + TILDE20 seconds waiting for the server to answer to deploy every single change to any source file.
“No way, i’m using FTP to upload my modified files on the application server”
Are you kidding? FTP? FTP isn’t enterprise! Call an exorcist!
OpenCMS, which is *really* enterprise, doesn’t expose its file system to you funky bastards who want to be in control…OpenCMS HAS ITS OWN FILESYSTEM.
It’s called VFS, which stands for Virtual File System, and is probably a hybrid obtained breeding a real filesystem with a db (i don’t really want to know the details, i may be embarassed), and what’s really enterprisey with it is that it can’t be accessed in any way other than OpenCMS’s own file explorer or WebDAV.
I can only imagine the amazed look on your faces, now…but the really fun thing about this OpenCMS and VFS stuff is that…somebody actually uses it!
Obviously, the number of poor people frustrating themselves with such torture is waaaaay smaller than the one of people using a working, PHP-based CMS (and this alone should be a reason NOT to use OpenCMS…unless you don’t care about user knowledge base, documentation, plugins and similar stuff), but there really is someone using it, and it’s probably someone whose management thinks PHP is good only for garage-based fansites and Java is the only possible solution for enterprise projects.
So please, the next time you begin any kind of software project, please pay a little attention and spend some time choosing the right bullet for your target, as excluding some technologies due to religious issues (yes, ‘enterprise’ is a religion, since it makes its integralists completely blind) will most likely cause you utter pain.
Besides, once you discover that the best technology for your project isn’t in your skill set, the funkiest thing you can do is to learn something new instead of dumping it and sticking with your old-fashioned framework 