Many people have asked us this question, where the language named was either Java, or VB.NET, or Python, or PHP, or Perl. The answer is actually quite simple, we knew that the vast majority of our traditional customer base would never have the time or inclination to learn these languages or else that the language in question did not implement what we needed or was not a general purpose language or not available for the platforms we wished to target. The only one to do most of that, Java, is far too complicated for people to use who have not had a university education in computer science. Since roughly 70% of our traditional customer base is made up of people who are professionals in other areas of expertise: doctors, lawyers, carpenters, truck drivers, insurance sales, auto parts supply, automotive sales, etc., there simply was no point in producing a product that could not meet their needs. In fact, it is arguable that SIMPOL Professional may be the only modern product that may meet the needs of these customers.
Some people will try to tell you that desktop databases together with development tools have passed their sell-by date. That they no longer make sense because today all development is done by highly-trained professionals. They couldn't be more wrong. There is still a huge sector of the market that is not only not serviced by the "well-trained professionals", they are also poorly served by the current array of available tools. Most of them have simply gotten too hard to use by the average, logically thinking professional. Or like some, they are simply not suited to producing a really useful piece of software. We firmly believe that there is still a solid market for a useful desktop database and development system, especially one that will allow companies to future-proof their investment in development by ensuring that the applications produced will work on multiple operating systems natively.
If you feel confident using Java, C#, or VB.NET, then by all means, please do so. Still, depending on what you are building and why, you may find that SIMPOL does a better job of meeting your needs long-term than any of the others. Java is a powerful, well-supported language that is available on numerous platforms. It has a tendency to not look native on most platforms, but they may eventually overcome that. However, Java is not greatly dissimilar to C++, so the level of programming knowledge is fairly high in comparison to SIMPOL. Also, there is no native database, though there are many to choose from as separate products. Also there is no built-in data-aware form concept, nor the other database-specific tools for which desktop database are known. C# is primarily a Windows language, although some are trying to make it available for Linux and other platforms. Still, the differences between C# and Java are small, so the level of difficulty is very similar. C# will not be available from its originator (Microsoft) for any other platform than Windows for obvious reasons. Any implementation elsewhere is the work of third-parties. VB.NET is not even an easy move for VB6 programmers, and is also specific to Windows. Please feel free to choose the tools that will solve your problems most easily. SIMPOL includes support for calling external library functions, so there is also no reason to produce a program in only one language.
SIMPOL has been in development for 7 years by a fairly small team. The language has been used in a production environment for over 5 years. In many ways, it is already ready. That is the reason for the Pre-Release program. All of our web development has been done using SIMPOL for over 5 years. Many people don't feel comfortable without a set of graphical tools in their hands, however, and actually mean: when will the form designer, report designer, file creation and modification dialogs, etc. be ready? Most of these are now incorporated in SIMPOL Personal. We made a decision early in the development process that these tools should be built in SIMPOL itself. The reasoning was this: "If we can't build these kinds of tools in SIMPOL, then it isn't going to solve the problems of our customers either." Also we felt that by building these tools in SIMPOL, we can ensure that the toolset is cross-platform and with proper design we could license the form designer, for example, to interested customers and give them the ability to control things that happen with it, by building in events that our customers can use, and methods to allow them to add and remove controls from the palette, capture when a form is saved, decide which formats in which the form can be saved, add menu items for things like pre-designed templates, etc. This will be included in the release that will be coming in Q3 2008. We are currently evaluating existing Superbase applications, since in some cases considerable reworking of the old application from semi-spaghetti code is required before it can be realistically converted. That work is normally done in SBL. Also, we have put a large amount of work into making sure that hybrid applications using Superbase and SIMPOL can be built. That allows a gradual phased migration strategy for existing Superbase applications.
Building a product that meets the needs of the next few decades and which is intended to replace a product that is as complex and evolved as the original Superbase is a fairly large undertaking. The development team was not funded by a company with a war chest like that of Microsoft, Borland, or any of the other major players. In spite of that, with a small but dedicated team of excellent people, we have been able to make (mostly) steady progress on our path to creating a new cross-platform development kit. We would have liked to have gone faster, but we were not able.
The intention has always been that it will be possible to build freeware and shareware programs using SIMPOL. The specifics of what can be distributed for free and what requires licensing is still being determined.
Current planning is targeting native Win32, Win64, Linux on Intel, Mac OS-X for PPC and Intel, and Windows CE (PocketPC/Windows Mobile). We are also considering SymbianOS (we already have the language and some basic UI support working for SymbianOS but we would revisit that if we truly choose to commit to SymbianOS development). Palm has announced that they are moving to Linux and GTK2 for their new OS and that older apps will run in an emulator. That is good news for us, since we will directly support that environment in SIMPOL. The SIMPOL language, database, and other components are written to be cross-platform by design, so if a customer needs support for another platform, such as HP-UX, or Solaris, it would be reasonably easy (especially considering how similar they are to Linux) to add that support in the future. Even very different OS's would not be particularly difficult to add, though for the GUI tools that may be time-consuming depending on the availability of wxWidgets for the target platform. The OS-dependent portions of the SIMPOL code are small and clearly separated from the rest, and the source code to wxWidgets is available and a port could be organized if required.
SIMPOL is the name of the language. The SIMPOL Professional is the primary method for developing applications in SIMPOL. SIMPOL Professional is a little different than the older desktop database products like Superbase. Superbase is an end-user desktop database that includes a development language and development tools. SIMPOL Professional comes with a top of the line Integrated Development Environment (IDE) for building and debugging programs, an end-user tool for creating files, forms, and reports, and for basic viewing of data within those forms and in record and table view. This end-user tool is built as an application using SIMPOL. SIMPOL is a general-purpose programming language that has specific extensions in the area of database-oriented application development. SBME is the database engine, but that is accessed using a set of objects from the SIMPOL programming language and is a completely separate DLL in Win32 or shared library in Linux or Mac OS-X.
Instead of being a single monolithic product, SIMPOL is actually a family of products that work together. This means that when you ship a product using SIMPOL, only the pieces that are needed have to be included.
Superbase Developers plc decided to restructure their business and in the process SIMPOL was sold to Simpol Limited. Simpol Limited took on the development team of SIMPOL and has positioned itself to promote and ensure the success of SIMPOL on the world market. In order to deal with the issues surrounding the ownership of the name Superbase, no final decisions have been made with regard to the naming of individual products.
We have several news groups on our news server that are dedicated to SIMPOL. That is the best place to ask questions, since everyone can read both the question and the answer.
SIMPOL stands for Superbase International Multi-Platform Object Language. It is pronounced the same as the word "simple". It is also meant to be simple to use.
SIMPOL has been designed from the start to be very easy to learn. Superbase Basic Language (SBL) has over 270 keywords that can then be combined in different ways and with various parameters. SIMPOL has only about 20 keywords of which only about 10 are regularly used. Everything else in SIMPOL is an object. The IDE provides a great deal of help using SIMPOL, since it can display intelligent help in various places as you are working on your program, including the function prototype and members of your functions and types. At the same time it is not required to create user defined types if you do not wish, the language can be used fairly effectively for functional programming. To get the hang of the language can take an hour or two and to learn what is available in terms of objects provided may require a little reading in the documentation, but it should be possible to produce usable code quite quickly.
SBL began life as a very primitive form of BASIC that only supported a single program at a time in the buffer and the only method of program flow was using GOSUB, GOTO, and RETURN. All variables were global in scope and creating reusable code was extremely difficult. It was then extended to support SUB main() as the starting point for a program, local variables inside of FUNCTION and SUB blocks, and got the ability to respond to events using the EVENTCLASS mechanism. Eventually another layer was added in terms of an object BASIC, but limited to the use of existing objects and with a large number of idiosyncracies to try and accomodate the older language elements and for retaining compatibility.
The real problem is that the SBL language is badly overweight and it is difficult for newcomers to get to grips with it, primarily because there are too many different ways of accomplishing the same thing. Also, many projects from Superbase customers that started a long time ago have made only limited use of the newer facilities but still run in the older philosophy of everything global. Another big problem is that Superbase suffers from the "current everything" problem. It has a current file, current form, current window, current index for each file, and a current record for each index. Many of problems people have with their own programs can be traced back to this. As a result, we decided to vastly simplify the language and by making everything an object we could also guarantee that once people get used to the new syntax, they would actually be far more productive, since there is no longer a current anything, because nothing is global anymore and the way things are accessed is through a variable that refers to an object. In that way, there isn't a global current record, for example, but there may be any number of current records held in different variables (or in various positions in an array).
SIMPOL and various components have already been run on Win32, Linux for Intel, Mac OS-X on PowerPC, and SymbianOS 6 on the Nokia Communicator. Currently the primary work is on Win32 and Linux. Before release there will also be work on a native Win64 release. We will eventually provide support for Windows CE (PocketPC, Windows Mobile) and embedded Linux with GTK on the Palm devices. Other targets are not currently scheduled, though they are regularly under consideration.
There are numerous ways in which both languages differ from each other, and also a large number of ways in which they are similar. SBL is interpreted and SIMPOL is compiled. SBL today is actually a collection of four different styles of BASIC, from line numbered BASIC, to structured BASIC both with GOTO and GOSUB as the means of calling certain routines, to a more modern BASIC using SUB main() and allowing user-defined SUBs and FUNCTIONs with local variables, and finally incorporating an object-oriented BASIC limited to pre-existing objects. SIMPOL is like the second two of those but with the added ability to create your own objects. It does not allow global variables but has well thought out support for passing objects around where they are needed. SBL is very easy to try things out in, and automatically can print to the built-in view window. SIMPOL is more structured, so trying things out takes a tiny bit longer. SBL has a usable but primitive set of development and debugging tools. SIMPOL has a feature rich and powerful integrated development environment (IDE) that is purpose built to make writing and debugging programs easier and faster. SBL has hundreds of keywords and some built-in objects. SIMPOL has about 20 keywords and numerous libraries providing objects that can be used to build even more sophisticated objects.
The SIMPOL IDE has extensive support for debugging programs. It is actually much easier to debug a program in SIMPOL than in SBL. The IDE has support for real breakpoints (including breaking only on a certain condition), the ability to examine the values of variables and objects, etc. It also includes a profiler to help you identify where your code is spending most of its time. See the IDE Tutorial and the IDE Handbook for more information.
It certainly takes a bit more than just opening an empty buffer in the old program editor and typing in a few commands and then running the program, that is true. On the other hand, it doesn't actually take all that long to start the SIMPOL IDE, create a new project (in a subdirectory called SBNG\Projects\tests for example) and to then type in the program there and try it out in the IDE. This is part of the price that we pay for not requiring all of the possible components to already be loaded and not requiring you to ship all possible components when you ship a program. This is the component architecture. Still, with very little practice it will become second nature and the tests directory will become a personal scratch area to try things out.
No. SIMPOL programs, similarly to Java programs, compile to a cross-platform byte code that is interpreted by the runtime libraries on each platform. There is no need to recompile the program. The same *.smp program will run on all platforms.
Yes. It is necessary that your program has been compiled to reference the required components as part of its project settings, but once the components have been referenced in the program, all of the form controls can be created at runtime from source code. In SIMPOL, the new form format is actually XML, and the library that reads the form format, parses it, and creates the actual form from it is itself written in SIMPOL.
In SIMPOL we will eventually support OLE2 automation as a client and the use of ActiveX controls. DDE client and server support are also possible to include if there is sufficient need. This is an area that we need more feedback about from our customers. Obviously, any applications using OLE2 or ActiveX controls will not work properly on any non-Windows platform.
We have looked at some of these issues. Although we won't necessarily add this support immediately, we have evaluated allowing SIMPOL programs to call Java classes using the Java Native Interface. Since we also include the XML Document Object Model Level 2 support in SIMPOL, it should also be possible to implement support for SOAP (Simple Object Access Protocol) on top of the XML DOM support to add the ability to interact with and expose web services. There is also some discussion about eventually compiling SIMPOL programs as Java byte code with some helper classes for our types and also to the Common Language Runtime (CLR) from .NET, but it is too early to make these decisions.
Although it is a little early to evaluate SIMPOL in every way for comparison to SBL, it is fairly clear that in many areas, SIMPOL is faster than SBL, in spite of the fact that it is doing quite a bit more (all SIMPOL strings are Unicode 3.2 strings in UCS2 format — 2-bytes per character currently). SIMPOL numbers have no floating point limitations because we don't use floating point. SIMPOL integers have no realistic limitations in terms of size and scale. As time goes on, we will continue to evaluate the speed of SIMPOL where it appears to be slower than it should and will optimize those areas as required.
Many of us over the years have felt the lack of a proper grid control in Superbase. The SIMPOL wxform has a grid control. This is one of the advantages that we have gained by choosing to use the wxWidgets GUI tool set for our cross-platform GUI. wxWidgets includes numerous useful controls, including a powerful grid control, tabbed notebooks, tree controls, bitmap buttons, and so many others that they are too numerous to mention here. We will also have some form of detail block to cater for those users that still want to use the detail block approach.
No, SBME files are container files. An *.sbm file can contain one or more database tables and all of the various portions of the database tables (data definition, indexes, etc.) are contained within the file.
No. Each *.sbm file only requires one file handle regardless of how many database tables it may contain or how many indexes any table may have.
SBF files are comparable in speed to the fastest of our competitors in the desktop database arena and faster than many. SBME files tend to be faster. In fact the more records a table has, the faster it seems to be. In spite of that, SBME was not originally designed to be especially fast, but rather to be efficient when used on small devices. That means that the database takes up as little space as possible and requires as little memory as possible when running.
The single-user database engine is 114KB in size on Win32. The multi-user client engine is about 124KB. The multi-user server engine is around 150KB. How much cache memory is used can be decided by the user when they open the single-user engine. The PPCS-based client engine does not cache records since there is no safe way to tell when the cache should be dumped.
SBME files have a theoretical size limitation of 64 Exabytes on Win32 on an NTFS file system. On Linux the maximum size is based on the file system limitations of the target file system, though currently they are limited to 2GB in size until support is added for the large volume commands. This will be done prior to release of the first commercial version.
SIMPOL will also have a Form Designer and Graphic Report Designer. These tools are being built in SIMPOL itself. The Form Designer will have two modes, one for printable forms and one for display forms. This will allow greater flexibility than was provided in the past. Display forms will look native on each platform, whereas print forms will try to be consistent on all platforms (within the limitations of available fonts of course). The Graphic Report Designer is intended to support labels as a type of report. It will also allow for a number of more modern targets for the output of the resulting report, such as HTML and eventually PDF. As for the menu and icon bar editors, there is planning for also providing these editors.
As was briefly mentioned elsewhere, SIMPOL is incorporating the wxWidgets toolkit for its cross-platform GUI support. wxWidgets includes far more controls than the older Superbase product ever dreamed of. This includes all of the usual controls plus others like an HTML control, various types of tabbed notebook styles (using tabs, a listbox, a combobox, and a tree control), various styles of tree control, listbox controls, in sufficient variety to supply the needs of most applications. There is also a rich text control for supplying an editor, a grid control that can be used in many ways, common dialogs such as print, font select, color select, open and save file, select directory, etc. There is a document architecture with print preview capability. We are evaluating the various bits of functionality to determine which pieces are available consistently across our target platforms and we are then implementing them as time permits. Not all controls will be available immediately, or even ever. We will implement only those controls that appear to provide significant value to our users. We may also implement our own control types if things are required that are not provided for by wxWidgets controls.