Do you have a PDF that explains the language? My opinion is that I have seen many languages come and go. Consider general programing languages. C is far superior to just about any language available. In fact the underlying code for most languages is written in C. So the question becomes, why does everyone see a need to keep creating new languages? Beyond the assembler instruction compiler for a new processor, a C compiler is usually the first compiler written for that processor. It is simple and straight forward to do, and I have done so many times. If you look at the evolution of the C language (even considering that bastard child C++) it has changed very little in 35 years, is available for all architectures, properly written code will compile for any architecture unmodified, and it has every hook needed to do any programming task.
Many decades ago, an attempt was made to make a more efficient keyboard to replace the QWERTY keyboard. Some of the fledgling computer companies in the 1970's and 80's tried to get them accepted. From a straight technical perspective, they are more efficient. They all failed to be accepted. Consider what is easier. To train a new generation on the old stuff? or to re-train half a dozen generations on the new stuff? Choices are usually made on which is easier now versus the long term benefits later. What I find interesting is how many of these "New" languages are so similar to C. Java, PHP, and such, take the base constructs of C, then add "Special" additions to do what is basically just a C function. They change some syntax to make it more BASIC like, but the general technique still follows C. So why not just use C? In my current project, I debated just writing a bunch of C functions to handle my data. Once I got into it, I realized that beyond simply reading/writing some data structures, the code was getting complex very fast. SQLite lets me offload the low level details and just write a query with SQLite handling the parsing and search. Is it ideal, hardly. But the alternative is much more complicated and not worth the effort. If your data is just a few simple data structures, sure, just write some C code. But the reality is that most well developed programs quickly branch into ever increasing complexity. Regarding SQL, many companies are attempting to replace SQL with their flavor of an interface. Embarcadero (the old Borland) has in their development system a "Universal" database interface to make accessing databases "Universal". The idea being that a database designer just wants their data and does not care about the underlying mechanisms. Wait, that is the entire concept behind every programming language. If programmers cared about the underlying mechanism at every level and just wanted to write the most optimal code possible (which is a far off concept no longer desired for some reason) then all programs would be written in assembler. I used their system for a while. Now I just write the SQL directly and just link in SQLite instead of using Embarcadero's stuff. Although some of their constructs "seemed" to simplify some tasks, the program as a whole was actually more complex. My opinion why SQL has endured is that it actually hides from the programmer the internal complexity required to implement a task. While some of the syntax may be a bit quirky, so is talking to a teenager, but we adapt. If SQL did not do what is needed then people would not use it. The reality is that SQL actually is a well thought out language, even if the syntax can be a bit bulky and awkward. If you consider "Who" will be using the language, I find that many of the "Users" are not computer scientists, but people that are trying to make a database for their business purposes, and their specialty is not the intricacies and philosophies of coding architecture. Some of us are those brainiac computer geek types. But I see a large number of users as people who "Learned Enough" to do their job. Another issue is the ability for someone a decade, or two, or three, later, who is handed the database code without any documentation, to be able to decipher the program. (remember the Y2K bug). As you develop your language, consider if someone without having read the manual, but has a background in programming, could decipher a program written in your language. ------------ Scott Doctor scott at scottdoctor.com On 6/7/2015 2:17 AM, david at andl.org wrote: > I've been reading this thread with great interest. It parallels the project > I've been working on: Andl. > > Andl is A New Database Language. > > Andl does what SQL does, but it is not SQL. Andl has been developed as a > fully featured database programming language following the principles set > out by Date and Darwen in The Third Manifesto. It includes a full > implementation of the Relational Model published by E.F. Codd in 1970, an > advanced extensible type system, database updates and other SQL-like > capabilities in a novel and highly expressive syntax. > > The intended role of Andl is to be the implementation language for the data > model of an application. It is already possible to code the business model > of an application in an SQL dialect, but few people do this because of > limitations in SQL. Andl aims to provide a language free of these problems > that works on all these platforms. > > The current implementation on SQLite uses a mixture of generated SQL and a > runtime VM. User-defined types are blobs, which the VM understands. A future > implementation could generate SQLite VM code directly instead of SQL, which > would save some overhead. > > The website is andl.org. The GitHub project is > https://github.com/davidandl/Andl. It's a work in progress. Any feedback > welcomed. > > Regards > David M Bennett FACS > > Andl - A New Database Language - andl.org > > -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org > [mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Darko > Volaric > Sent: Thursday, 4 June 2015 8:55 AM > To: General Discussion of SQLite Database; ott at mirix.org > Subject: Re: [sqlite] User-defined types > > I've tackled this problem from a couple of different angles. My goal was to > allow arbitrary user defined types, based on the builtin types (essentially > subtypes of the existing types), with a minimum of work and minimum > disruption of the normal/existing use of the database and API. > > The approaches I considered were: > > - encoding the user type codes for each data column in a separate column > dedicated to the purpose. This is a low impact but cumbersome, for instance > using a function that interprets the user type would have to have the user > type passed in for each argument, along with the actual data. > > - modifying the data file format to carry user type information. There is > space in the record/row header where you can encode this information in a > backwards compatible way, but the source code for data record access is not > friendly, basically a dense blob of code with a lot of integer literals > which are all very important, but it's hard to be sure what they entail and > that you haven't introduced a subtle bug and ultimately data corruption. > Additionally the user type would have to be passed around internally - for > example in the sqlite3_value object - and tracking down all of those > reliably is a bit of work. > > - using blobs. Although using text representation is friendly when looking > at the data with standard tools, it's slower and takes up more memory in > various places. I found that encoding some user types as blobs with a type > marker at their start (a single byte with extensions) and interpreting them > was a simple and low impact approach. I also split the standard integer type > four ways (negative and positive, odd and even) to get the scalar user types > I needed. User defined functions and collations need to be defined for > interpreting these user types of course. > > The first option isn't very practical. The second option is the fastest and > most robust solution and my long term approach which I will be going back to > after development has progressed a bit more. Currently I'm using the third > approach as an interim measure. I'm supporting arbitrary prec ints and > reals, arrays and tuples and other types this way. > > > > On Wed, May 27, 2015 at 3:48 AM, Matthias-Christian Ott <ott at mirix.org> > wrote: > >> I want to define user-defined types, i.e. types not SQLite has not >> built-in and make sure that I didn't overlook something. Is it correct >> that values of user-defined types should be stored as text and have a >> collation defined if there is an order relation for the type if the >> type cannot be represented as a subset of integer or float? >> >> Example: >> Suppose I want to store arbitrary precision integers in SQLite. I >> would create a column with text affinity, (uniquely) serialize and >> deserialize the integers to text (e.g. by converting them into decimal >> representation) and define and declare a collation that deserializes >> the texts to arbitrary integers and compares the integers. >> >> Is there another way to define user-defined types despite this method >> and virtual tables? >> >> - Matthias-Christian >> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users at mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > >
