If someone asked you to name the best car on the market, you'd probably tell them the answer depends on who will use the car. After all, a family of eight living in Manhattan probably needs a different type of vehicle from a single hacker living in rural North Dakota. The same is true for programming languages and development toolkits. Each has its place and is appropriate for solving different sorts of problems.
Although this might seem obvious, many programmers believe the language or toolkit they use is so good it should be used to solve all problems, all of the time. As the old saying goes, if your only tool is a hammer, every problem looks like a nail. No programming language is the best fit for all problems, which is why experienced programmers know and use a variety of languages and constantly are learning new ones.
Until only a few years ago, programmers were largely concerned with optimizing their programs for speed and memory usage. After all, processors were relatively slow, and RAM was fairly expensive, so any program that didn't try to squeeze the most out of the hardware was seen as bloatware.
Today, however, we are blessed with cheap, fast computers and cheap, plentiful RAM. This means that software engineers can and should use languages that encourage rapid development and long-term program maintenance. I'm not against optimizing programs for speed or memory usage, but they are less important than creating stable, maintainable software quickly and easily.
About two years ago, I decided I would devote a long series of columns to four basic web development technologies: mod_perl/Mason, J2EE, Zope and OpenACS. These technologies are not only interesting and useful but thought-provoking as well, providing new perspectives and ideas for web developers. And although occasional arguments arise among these communities about which product is superior, the fact is that each tries to solve a slightly different type of problem.
This month, we take some time to summarize the ideas and frameworks that we've explored over the last few years. I don't expect that everyone reading my column will jump to use all of the technologies I name here; however, I do hope to provide even the most die-hard aficionados with some food for thought.
Apache is deservedly one of the poster children of the Open Source movement. It is reliable, highly configurable, well documented, stable and extensible. You can do amazing things with Apache and can customize it in any number of ways to fit your needs. If you are writing a web application that must execute as quickly as possible, you can write a new module in C that seamlessly hooks into Apache.
Although C programs execute quickly and Apache libraries (now known as the Apache Portable Runtime) provide a great deal of useful infrastructure and support for module authors, development in C is slower and more prone to bugs than working with a high-level language such as Perl or Python. So it shouldn't come as any surprise that there are Apache modules that embed these languages inside of the Apache server. mod_perl allows you to write Apache modules in Perl, rather than C, giving you nearly unlimited control over your server with all of the speed and flexibility of Perl.
And indeed, mod_perl comes to mind whenever someone asks me to create a high-performance web application, particularly one that involves text processing or a relational database. I could write the module in C, but why bother? There are times when it makes sense to code in C, but I've generally found mod_perl to be fast enough for even high-powered applications.
Of course, the wonder of mod_perl diminishes somewhat when graphic designers enter the scene. Designers have no interest in modifying program code whenever they want to change the style (or content) on a given page, and giving them access to the source code of Perl modules is asking for trouble. Thus, dozens of different templating systems are available, each of which allows you to mix Perl and HTML in a slightly different way. One of the most popular is Mason, which has been used on a large number of heavy-duty publishing sites for years.
Mason is indeed a wonderful tool, and it provides an excellent trade-off between rapid development (thanks to Perl), easy maintenance (thanks to Mason) and fast execution (thanks to mod_perl). The Mason e-mail list is a source of useful information and support, and the package maintainers have done an admirable job of improving it steadily over time. Configuring, using and debugging modern versions of Mason make the versions that I first used several years ago appear primitive in comparison.
At the same time, Mason is an infrastructure and framework for creating your own applications. True, you easily can use Apache::Session to generate cookies and associate users with a unique ID, but anything having to do with user registration, groups and permissions, let alone full-fledged applications, are your responsibility to implement. For some projects, this is just fine, because it gives you the flexibility you may need. But the fifth time you find yourself creating a system for creating and managing users, groups and permissions, you may decide you need something with a bit more infrastructure.
|Happy Birthday Linux||Aug 25, 2016|
|ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs||Aug 24, 2016|
|Updates from LinuxCon and ContainerCon, Toronto, August 2016||Aug 23, 2016|
|NVMe over Fabrics Support Coming to the Linux 4.8 Kernel||Aug 22, 2016|
|What I Wish I’d Known When I Was an Embedded Linux Newbie||Aug 18, 2016|
|Pandas||Aug 17, 2016|
- Happy Birthday Linux
- ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs
- Updates from LinuxCon and ContainerCon, Toronto, August 2016
- New Version of GParted
- What I Wish I’d Known When I Was an Embedded Linux Newbie
- Tor 0.2.8.6 Is Released
- NVMe over Fabrics Support Coming to the Linux 4.8 Kernel
- All about printf
- Blender for Visual Effects
- A New Project for Linux at 25
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide