I view computer science as the set of techniques that make computers useful and cost effective.

I view computer language design through the same set of glasses.

I am designing an object oriented language that has functionality approximating a RDBMS with some extras.

* I see a Table as a disk based List where schema is equivalent to a Class description.
* Rows in those tables are Objects.
* Objects are composed of an ordered list of other Objects that are fixed length but can access variable length data elsewhere.
* Functionally a List and a Table are identical except that a List must fully reside in memory whereas a Table does not.
* Indexes (which are functionally equivalent to an ordered List) can be attached to Lists/Tables or not. I have BTree and Hash indexes.
* If they are attached, then they can only be updated by changing the data in the List/Table.
* A Map is an unordered, schema/class less bag of Objects
* Objects can be stored in Maps and Maps can update Objects.
* Relations are lookups in Lists/Tables or lookups using associated Indexes.
* Selection is a built-in function of a List.
* Aggregation is a built-in function of a List.
* Table constraints and relational integrity are ensured using triggers.
* Sorting a List doesn't require any change to attached Indexes.
* Allowing duplicates in an Index is a switch.

I am not interested in "tuples", "relations" or any other Math that doesn't make my system more useful. Math purity matters nothing to me. Whether a "set" allows duplicates or not is a programmer decision to me.

Most of my database facilities look like what RDBMS produces internally based on parsing of SQL statements. I implement SQL by using a macro to create the code necessary to functionally execute the SQL statement which is not much different from the approach of most RDBMS authors.

If you asked how close my design is to a "real relational model", I don't know, nor do I care. I have programmed in SQL for over 20 years and it is the good functionality of RDBMS that I want to include, rather than "relational purity". I have a list of "good design qualities" that should be maximized and Math purity isn't one of them.

The highest goal for me is that it be useful and as productive as it can be. I believe that writing complex code, solving complex problems isn't so difficult. Simple code, solving complex problems is difficult. Having code simplicity is one of my goals but many times that gets in the way of having the tools to get the job done. Trade offs must always be made. Which trade offs are implemented normally defines the strength and breath of a computer language.

My language was designed to meet most of the needs of a business, be delivered over the web, and be easily and quickly changed while having very high availability. My language wasn't designed for embedded programming or creating operating systems.

I think most current programming languages don't have enough tools to look after structure in the "large" and aren't simple enough in programming the "small".

I reject the edit, compile, link, run, stop, repeat pattern.

I see computer systems as always being alive and changing continuously over time. I don't think a company's computer system should just store the accounting but should be the DNA of the company as a whole. It should be the only employee that never goes on vacation, takes time off and never quits. In the end, I think a company's computer system should '''be''' the company. I don't think current computer language systems facilitate this goal.

Here are just some of the ''bad'' things that stop continuous living computer systems.

* Having separate production and development systems
* Separating the data from the programmers that are trying to enhance the system (in a RDBMS)
* Publishing versions of software on a 6 month or yearly basis
* Not allowing simple changes in real time
* Requiring the system to stop to change data structures
* Not allowing distribution of functionality to other computers without program changes

In general, I reject the data entry, check for mistakes, process batch, print reports paradigm.

I believe in interacting with the data directly, using structured tools and analyzing data using data cube type approaches where the computer is used as an analytical tool rather than a dumb data repository.

I believe that web applications are the future of computing and integration of different systems will happen by using messages of the web. I don't think it is necessary to physically integrate different programming languages directly either through libraries or through a common VM.

If you think that much of the above isn't about "Math Purity", I would counter that by saying that language design can't be separated from the set of problems your language is designed to tackle. If anything from Math is "useful", I would borrow it without a second thought but rejecting non-Math "useful" ideas, to maintain some equivalence with Math is not optimal.

-- DavidClarkd

[please add comments at the bottom]

''It reminds me distantly of DEC RMS, but not for any particular reason.  I'm curious what problems your language is intended to solve, especially in terms of what other database languages (such as TutorialDee, SmeQl, etc.) or language-SQL combinations (usually Java/C#/Python/whatever + SQL) don't solve, and/or in terms of what historical systems like Pick or ExBase did or didn't do.''

''Re "I believe that web applications are the future of computing and integration of different systems will happen by using messages of the web."  How does that differ from WebServices?''

''Re "I view computer science as the set of techniques that make computers useful and cost effective."  How does that differ from SoftwareEngineering?''

I think it is not optimal to have data at a distance as in current RDBMS, even if networks become even faster. Having a "data layer" in Java on one computer, stored procedures in the DB and triggers when the schema can't accommodate some constraint isn't optimal!

''Which DBMS (or DBMSs) are you referring to here?  Or are you referring to an architecture -- e.g., J2EE -- that favours using an ApplicationServer between the DBMS and the client-side applications?''

Although I disagree with some RAD design methods, I do think that software needs to change much quicker and easier than any system I have seen. I also want the unusual ability to do anything a programmer can do, from a program running inside the system, including accessing the documentation, with the proper security clearance, of course.

I have a whole set of documents on my web site that not only talk about what my system is but also '''why''' I designed each major feature as I did. I would be happy to answer any questions about those features or debate my design decisions.

I have programmed in many languages but no one is familiar with them all, including me. If other languages include database type facilities, then that is a plus but my system is much more than that. I have a number of features that I have never seen in any other language but like most other languages, it is the combination of features and flavor that matters most. I have made a number of systems in Visual FoxPro (database/language) but that is defunct now. I did design and program an Xbase interpreter/compiler and sold over 30,000 copies in 1987. It's demise is a history lesson in what not to do when developing and marketing software.

I totally believe that "Web Services" are the future but most of the previous attempts have failed for proprietary or other technical reasons. I have researched the documentation for Web Sockets and I think that might have a chance at integrating different systems. It is now a W3 standard for only 2 years but it is fast, bi-directional, available from a browser using Javascript and doesn't force any specific structure or overhead down your throat.

Science to me means "to study using formal means". Being able to create hypothesis, produce the code and have others duplicate your experiment also applies to programming. I call it CS when people study how to make programming better and how to design software systems to provide a better computer/human interface. I took a 3rd year course in Software Engineering,  24 years after I started in the software business. The professor had a Phd but the course and his ideas about software were "mickey mouse" and naive. I think I know what Engineering principles are but exactly how that works when designing software I am not sure. I know about Case programming and many other methods but if the future of design/programming is Computer Engineering, we haven't got there yet. -- DavidClarkd

''That is a not uncommon view among experienced mature students, who sometimes don't realise that what's "micky mouse" and naive to them is quite challenging and relatively sophisticated for the relatively fresh-out-of-school, relatively inexperienced students that surround them.  You weren't the intended audience for that 3rd year course.''

I agree with your point but this wasn't a first year course and I had never come across this way of programming, any more than the rest of the class. It was 13 years ago and not very memorable but I remember a lot of effort was put into trying to show that SE code could be "proved" to be correct. The syntax was also very Math like, so it obviously must be good, right? I know many university professors in CS are working on exactly this (provable code) but I think it is not different from the seekers of perpetual motion. I think you ''can'' prove that some simple program is "correct" but it doesn't take much real world, to send the problem into the intractable. This self described Software Engineering "guru" had never actually had a "real programming" job and here he was trying to show us that everything we had already created was incorrect or second rate. Just another Math weenie! -- dc

''Provability is very important in areas like safety-critical software.  The academic probably had a particular interest in that area.  However, to treat the entirety of SoftwareEngineering as being about provability seems unusually short-sighted and narrow.''

I was just stating one aspect that I remembered from my SE course from 1999. I think your "unusually short-sighted and narrow" comment was over the top. Did you have a point to make or just hyperbole? --dc

''You wrote that "I remember a lot of effort was put into trying to show that SE code could be 'proved' to be correct", so unless your memory is faulty, the only thing "over the top" was your professor's overemphasis on provability.  There's a lot more to SoftwareEngineering than that, so I stand by my comment that for the lecturer to focus on provability at the expense of the rest of SoftwareEngineering '''is''' unusually short-sighted and narrow.''