The Falcon Programming Language in a Nutshell
Because attributes are a very flexible means of declaring dynamic Boolean properties and a set of “similar” objects, we have used them as the main driver for message-oriented programming.
Basically, objects and instances with a certain attribute can receive messages built for that attribute's holders. The target objects will receive messages through a method named after the attribute.
The rest of the message-oriented programming support is built on this basic mechanism—message priority queues, automatic event dispatching, inter-agent messaging services and so on.
As a minimally meaningful sample would require 50–100 lines (messages are among many agents), we'll skip it here, and try to explain what's nice about message-oriented programming.
The main point is that you can summon remote execution in unknown objects willing to participate in the message without direct knowledge of them. Messages can carry anything, including methods or whole Sigma sequences for remote execution in foreign objects.
Messages don't even need to be point to point. The message receivers cooperatively can form a reply by adding something to the forming return value. For example, a central arbiter can send a “register” message, and every object willing to register can add itself to a queue of items willing to register in a queue traveling with the message. The queue even can contain target register procedures to be invoked by the arbiter once the register message processing is complete.
An example that easily displays the power of this paradigm is the implementation of an assert/retract/query mechanism.
A central object registering assertion listens for messages of these three types. Any part of the program then can send an assertion, a name bound with executable code, which can be anything, including code generated dynamically or loaded from plugins. Items in need of some algorithm can then query the system (sending a query message) asking for it to be provided.
If available, the code is returned, and it can be invoked by the agents in need of it.
You also can do this through a global dictionary, where code is associated with algorithm names, but that approach requires all users of the code to know the central dictionary and to interact with it. Asking a smoke cloud to take care of arbitrating the code repository is easier, simpler, more modular, more flexible and allows for central checking and managing. When that comes at no additional performance cost because of the language integration, it's an obvious advantage.
Stuffing all the things that Falcon can do for you into a short article is not easy, mainly because the things some will find useful may be useless for others. We didn't discuss co-routines, the indirect operator, the upcoming tabular programming, the reflexive compiler, the Falcon Template Document system (our active server pages), the multithreading module or many other things we've done and are doing to make Falcon the best language we can.
A DBI module already is available for interacting directly with MySQL, Postgre and SQLite3, and ODBC and Firebird will be ready soon too. A module for SDL is standing, and we're starting to work on a generic binding system to provide full support for Qt, GTK, GD2 and many other libraries.
We are still a small group, and the language specifications are still open. So, if this project interests you, and you want to add some binding or test some paradigm/language idea, we welcome you.
Giancarlo Niccolai was born in Bologna, Italy, and he graduated in 1992 in IT at Pistoia. He currently works as IT designer and consultant for software providers of the most important financial institutions on the continent. He previously has worked with many open-source projects and consistently participates in the xHarbour (XBase compiler) Project. He has expertise in several programming languages and deep interests in natural languages and linguistic/physiology sciences.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
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