Thanks for the suggestion, Tinkster. I had hoped for a less piecemeal solution. Digging into the internals of a large C++-based API such as QT to build a database front end nearly from scratch would entail quite a large undertaking. With all of the code floating about the web, such a strategy for an intermediate solution sounds like overkill, especially when we have such nearly complete projects as Rekall and other soon-to-be-available utilities such as the aforementioned OpenOffice database access application. By the way, the specifictation for the proposed Rich Text Control of the database project reveals that it won't bind to database fields in the initial release, which brings to question any reason for its inclusion in the release (in my understanding of the language used), so I don't intend to hold my breath waiting for it to come out. Of course, I realize that OpenOffice already has a database access utility, but I've read horror stories about the complexity involved in its configuration. I've also noticed the dearth of documentation about the tool.
I suggested a Python- or Java-based approach because these newer languages have features which lend to more rapid prototyping. I managed to cobble together part of an image browser in Java, including a fairly well-designed directory tree component, in a fraction of the time in which I could have done it with C or C++. In fact, through years of tinkering with C and C++ I have developed quite a distaste for those older languages.
It truly surprises me that with all of the open-sourced projects I'd have any trouble finding examples of a PyGTK-based formatted text widget or XML editor widget. I mention a PyGTK-based example because Rekall scripts use PyGTK widgets, which suggests that other PyGTK-based widgets would fit more easily into scripts for the Rekall front end, and I suggest Rekall due to its apparent completeness and readiness for use. If I could cobble together a script to bind an XML editor widget to a database field-and I could do this if I had more knowledge about the involved systems-I'd have what I need.
I see all of the pieces to the puzzle out there. They already exist. I just haven't discovered any obvious ways to put them together, due to poor documentation and lack of examples. Even the available source code I've seen hasn't offered any obvious solutions, due to either poor design or poor coding style.
My pet project involves reinventing a different wheel. Of course, I like to think of it as building a better mousetrap. At the risk of sounding crazy, I'll summarize my ideas.
I've grown weary of wresting with formal programming languages and plain text editors. All programming languages that I've encountered have basically the same major flaws, which put the burden on the programmer instead of on the computer, where it belongs. Even newer languages, such as Java, Python, etc., continue to incorporate these flaws. Nowadays, our computers have enough processing power that we can start to shift the burden.
What specific flaws do I see?
The first one I'd like to mention involves the second of my two aforementioned peeves, the plain text editor. How long have we had applications and standards for formatted text? Why do we still use plain text editors for writing code? I've spent too much time editing comments when changes in comments fouled the right margins. I've spent too much time dinking around with indentation when changes introduced new scopes. I've spent too much time trying to identify which files contains specific constructs. Even the new-fangled IDEs, for old and new languages alike, fail miserably in functionality and usability.
What do I see as a solution? Using formatted text would solve half of the problem. Indentation tags would allow proper layout with word wrapping. Changes to the code which add or delete a scope would only entail the click of a button or a CTRL-key sequence to increase or decrease the indentation. You could still have your syntax highlighting. You could also make changes to the layout to highlight specific constructs or to make the code more readable. Want to change the appearance of specific items throughout the entire project? Change a global stylesheet. You could comment portions of code by simply changing the tag applied to it (with a simple click of a button or key combination), and whereas you could have visual cues as a result of the styles applied to the tag (eg., italics, font size, etc.), you wouldn't have to add line noise with // or /*...*/ or # or ; or any of the other symbols that different languages have used to delineate comments.
I see another method to improve code-related information management. Putting code in a database would offer many advantages and possiblities. (Before anyone suggests it, I'm aware that such systems do exist, e.g. Suneido, etc.) A database of code would simplify browsing that code. A database of code would allow you more choices involving how you wanted to view it without making any changes to the code. A database of code would increase the available options for querying that code. Surely you can envision other advantages and possibilities.
Alright, we have tables of formatted text, which will address some problems related to information management and productivity. With that out of the way, let's address the flaws of existing programming language. First, what do we see as flaws?
The syntaxes of most languages impede productivity. For example, look at any C++ or Java class definition, and you'll see the following:
class ....
int ...
void ...
int ....
int ....
void ....
In Java, it gets even worse, as illustrated by the following:
public class ...
private int ...
public void ...
int ...
protected int ...
public void ...
Of course, I omitted the names to exaggerate my point. For some reason, the language designers decided that the type and the visibility should appear first. This syntax hides the attribute that conveys the most information to the programmer, the most unique attribute of an element: its name. Even the javadoc utility gets this backwards. When you look up a word in a dictionary or a glossary, do you search for the word by its part of speech? Do you search for it by its definition? (Though this might be useful sometimes, it's the exception rather than the rule.) NO! You look for the word! Otherwise our dictionaries would list entries by part of speech or by definition. Why would the syntax of a programming language define it the other way around? Mathematical convention? I can't think of any other possible reason.
Sure we have tools and IDEs that will extract the information for you and give you a list or a tree with the names sorted any which way. Sure, when you want to see the definition of a function, you can use your editor to search an open file for the name of the function. But when you click on the tree node or when you hit CTRL-F and type in the name you want to find and your tool takes you to the function definition, you still face this ugly wart in your code. What if you want to use grep to recursively search a directory tree for the definition of the symbol? For each line that grep returns, you'll have to scan past the beginning of the line to find the name.
This "convention" obscures information, and it's simply backwards. After all, what is source code but a dictionary of terms and their definitions? Why shouldn't the syntax of a programming language reflect this basic fact?
Almost every time I look at someone else's code, it amazes me how difficult it is to read, partly due to sloppy naming conventions and the mixture of sloppy naming conventions in separate APIs, but mostly due to problems in the language design which encourage and even demand these ugly naming conventions. Most programming languages force you to give a name to every element. Most programming languages prohibit delimiting compound names with spaces. Many programming languages use case-sensitivity, which also makes code more difficult to read and more difficult to type.
This only begins to describe the flaws I have noticed. Natural language...
Don't get me started. I've ranted long enough for tonight.
Of course, some of these issues have been the topic of many language wars. Let's not go there. I merely wanted to identify some issues that I plan to address with a new programming language to hopefully make programming a more productive endeavor.
Now, I need some tools to achieve these aims. As I mentioned, it completely surprises me that I haven't found any open source projects that will fit my needs out of the box. Thus, I realize that I'll have to put some of the tools together myself. I can reinvent part of the wheel, but I can't do it from scratch, especially when I intend to reinvent a whole other wheel. I can't afford to reinvent too many wheels. Nobody lives forever.
