What kind of "front-end" functionality are you imagining? Would something like Oracle Forms or Oracle Apex qualify?

Basically, because SQL is not as expressive as other paradigms. You can resolve the "object-relational impedance mismatch" by adopting other paradigms besides OO without just writing everything in SQL, and if you do stick with OO then the "impedance mismatch" is often an acceptable cost.

Of course, the other answer is that a lot of applications do use client-side SQL databases. For example, Google Chrome stores your history, cookies etc. in an SQLite database; SQLite is also used by the rpm and Nix package managers on the client-side.

@kaya3, I'm not sure if I've been unclear somehow, but you're not following my thinking. I'm not talking about client-side storage using an SQL database engine, and I'm not talking about the SQL language itself being used, but about some unspecified language which, although presumably not SQL, nevertheless aligns sufficiently with SQL concepts that there is no "impedance mismatch". As I say, the absence of a null value within the domain of every type, is something that GP languages seem to lack intrinsically.

@IMSoP, I don't know those applications first-hand, but from a brief read I suspect they did originally employ broadly the philosophy I'm talking about. But even they say they are now Java-based, and Java (to my knowledge) is not fully commensurate with SQL.

Ruby has only a single type (it is dynamically typed, so from a type-theoretic standpoint, it is "uni-typed"), and it has a nil value which is a member of that type. Therefore, it fulfills your criteria of a general purpose language, often used on the client-side, which has a null value within the domain of every type. Is that what you are looking for?

You might also be interested in some of the discussions on the Wiki, e.g., ObjectRelationalImpedanceMismatch and ObjectRelationalImpedanceMismatchDoesNotExist as well as the many discussions that branch off of those two.

@JörgWMittag, but SQL isn't "uni-typed". It actually has separate types, but with a null value in each. And it has a scalar/table distinction in its types. And type checking, and operators, etc. What you're describing about Ruby sounds much like VBA's Variant type. So VBA - which I mentioned - already fulfils the criteria as you're interpreting the criteria to be. I'm not sure you're following my thinking about the desirability of conceptual exact alignment with SQL in certain respects, including particularly it's type system in an exact way. (Not read the links yet btw).

@JörgWMittag, regarding the second link about the non-existence of the impedance mismatch, I think that's primarily argued from the perspective of OO programmers whining about the relational model. I'm actually coming the other way, as a programmer who uses the relational model whining about OO languages!

@Steve Well, as I said, there are lots of languages where there is no "object-relational impedance mismatch", as that is only a feature of OO languages. And SQL itself is a non-OO language which is used clientside.

@kaya3, as I say, I'm not sure you've followed my thinking. There's a difference between for example the type system of SQL and even old non-OO languages like C. I'm not sure why you're sustaining the point that SQL is used client-side, when I've already addressed your confusion in detail above.

There is no difference between the type system of SQL and the type system of SQL, though. What about SQL makes it not an answer to your question? Yes, clearly, I'm not understanding something about what you want to know, which is why you need to clarify. You are asking "about some unspecified language which, although presumably not SQL, nevertheless aligns sufficiently with SQL concepts that there is no "impedance mismatch"". If it's only presumably not SQL, then you haven't ruled out SQL as a possible answer. And I don't see anything else which rules out SQL.

@kaya3, no but there's a blatantly obvious difference between the context of use, and I've given more than enough detail in my question to allow a sensible person to perceive that aspect. If you think I can replace, say, VBA with SQL - using SQL in places I would usually use VBA to show screens and set UI fields and display message boxes and react to button-presses and so on - then (to say the least) there's a considerable scope for use of SQL which I have not been previously aware.

@Steve The only way for you to assert that you have given enough information for a sensible person to understand what you mean, is if you say everyone commenting or answering here is not sensible, because it seems nobody other than you understands what you are asking.

Nullable types are an extremely common feature of many languages, though implemented in many different ways; C# didn't belatedly add nullable types, it added non-nullable types (something which SQL also largely lacks). That's completely unrelated to the "object-relational impedance", and any other aspect of SQL.

@kaya3, so what role did you see the example of Access and VBA, and my specific reference to the absence of nullable types in VBA despite being married to an SQL engine, playing in my question?

@IMSoP, maybe I should have been more specific and said nullable value types? At any rate, even the types it has now are not quite full-square with the concept of the null value in SQL.

@Steve No, nullable value types have been in C# from the beginning, as have implicitly nullable reference types; what's new is having a context where reference types can error if not explicitly nullable. Meanwhile just about every DBMS has a procedural language which builds on SQL, using the same type system as the main database (which may or may not match ANSI SQL). You really do need to be a bit clearer in the question about what you mean by "similar to SQL", and what a language needs to be able to do beyond that.

@IMSoP, from what I can see from reading now and vaguely recollect, the last time I used C# on any regular basis (around v5.0), the language was in a condition where nullable types were virtually unusable, because they were explicit containment structures for the base value type with a bolted-on null field, not additional values in the domain of the basic type. Strings were treated differently. And they were all inconsistent with DBNull, as used by many library facilities. I'd practically forgotten the depth of this mess that prevailed at the time! (1/2)

So in my view, this is not a point well-made that C# is a language whose type system aligned with SQL "from the beginning". I concede it has shaped up better in intervening years. There's at least a couple of reasons I'm discounting it though. First, C# as a system of programming has not been designed from the outset to align with SQL, and we're arguing here over a small and belated concession/easement, not showing full alignment. And second, the design does not proceed through to the front-end - for example, Winforms has no consistent built-in representation for nullable fields. (2/2)

@IMSoP, and just to make my question emphatic, it's not "why can't various languages be pressed reluctantly into interacting with database engines", it is to ask why no language (that I'm aware of) appears to have been designed in which the initial, central, overarching goal was to avoid any inconsistency with SQL conceptualisations, right through to the UI layer. I'm not talking about strict syntax alignment with SQL either. (1/2)

I'm talking about such things I mentioned in my question like table types, nullable types as they are in SQL, operators that handle nulls the same as SQL, and a reasonably suitable syntax reflecting the central design goal of conceptual alignment. The reason I think it's plausible to have expected such a thing by now, is the ubiquity of SQL engines, and the extent to which a great many bespoke applications fundamentally are client-server database applications. (2/2)

For what it's worth, I don't find the intent of this question that hard to discern, although I agree that the title & introduction probably don't get to its point enough (and I don't think the present answer is a fair response to the question). However, there are a number of programming languages tightly coupled with databases that seem like they could be counterexamples - are you including/excluding things like MUMPS, Visual FoxPro, many so-called fourth-generation languages? Is the full relational model of ANSI SQL in particular the key aspect? Are non-commercial research systems included?

Looked at another way, would the answer "these do exist, they just aren't popular" be a frame challenge to the question, or a direct answer to it?

@MichaelHomer, I would say integration with SQL is a key aspect, because SQL is the thing which is widespread. I've heard of MUMPS, but (iirc) it's a medical system of ancient design and not at all SQL-based. FoxPro covers similar ground to MS Access, and (I believe) relates to SQL in a similar (equally deficient) manner. I'd consider it an answer if something did exist, and there was some theory about why it was unpopular. I'd just emphasise/clarify again that I'm not necessarily looking for something which is syntactically identical or even similar to SQL. (1/2)

And I'm assuming there would be no significant query functionality in this client-side language. But there would have to be a native representation of tabular data sent from the server, the type system working the same so that every scalar value representable in SQL on the server side has a direct equivalent on the client (so that there is zero need for any translation code, or mental shift by the programmer), etc. (2/2)

These comments have drifted a long way from what they're intended for, which is helping to improve the question. So, here's some concrete suggestions for an edit (as in rewording the whole thing, not adding more sections on the end): 1) drop the term "client-side", because you're using it in a non-standard/un-common way; 2) come up with a clear list of criteria that a language would need to match your idea, so we don't have endless No True Scotsman debates; 3) ask about why none have succeeded, rather than "devised"

@IMSoP, (1) anyone familiar with a client-server database application will understand that term in context of the question, and you're not suggesting any better word; (2) I don't want to exhaustively define the criteria, instead I want you and others to get with the gist of question (or withdraw if your confusion is such that you cannot follow); (3) I'd be happy to know which had been devised but then failed - I've been believing that there hasn't been an attempt. Even allowing for my own muddled terminology, I'm shocked by the level of quarrelsomeness this question is provoking.

@Steve Evidently people did not interpret "client-side" how you intended. That doesn't make you wrong, or them idiots; but it does mean that you might get more satisfying answers if you can think of a different way to express it. My suggestion was made in good faith: if you want to reduce the confusion and debate on the question, try clarifying it; if you're not interested in clarifying it, don't expect everyone to suddenly understand it.

@IMSoP, the point of consulting a community of fellow experts is that they can get with it quickly and provide useful information, it's not supposed to be like confronting a gang of unruly philosophers. I admit "client-side" could be an ambiguous keyword on its own, but I'm less willing to admit that somebody who had read the full question could have attributed to it any meaning other than the one I intended. I'm not sure anyone was actually confused about that point. You commented in a way that suggested you understood my question. (1/2)

And Jorg and Kaya responded in ways which suggested they fully got the meaning of "client-side", since they both referred (in responses which were bizarre for other reasons) to the common use of the SQLite storage engine on the client-side. Michael and Jerry have managed without quibble on the point. So what other term to use? If I had mistakenly overlooked a common and more precise term, I could fix. But you have no better suggestion, despite claiming my usage was unconventional, so why raise the complaint? (2/2)

I've wondered about this issue for a long time too. (And understood it on the first read). Hope to see interesting answers

I'll lay my cards on the table: I have an idea what might be being asked, and have some thoughts on how to answer that interpretation. But since anything I spend effort writing seems likely to receive a reaction of "you're missing the point", or worse that I'll be labelled "bizarre", "idiotic", and so on, I'm not particularly motivated to bother.

I'm pretty sure I've seen something fitting the rough description built on XQuery, if you're willing to allow that much deviation from SQL (into general-purpose "query language" space).

@IMSoP, I'd certainly be interested to hear your perspective; I'm hoping curiosity causes me no further regrets today. I'm still digesting what all this trouble meant.

Computer science professor Ron van der Meyden summarized the various issues as: "The inconsistencies in the SQL standard mean that it is not possible to ascribe any intuitive logical semantics to the treatment of nulls in SQL."

@Yakk-AdamNevraumont, I've discussed these interesting points before with other people. Part of the problem is that the null value is not supposed to have one consistent intrinsic meaning, and it is in fact used for multiple different and unrelated purposes in SQL, for very good design reasons. The "treatment" reflects a well-balanced settlement of these different uses. Theoreticians and educators often don't like this complexity, but their objections to it are often naive.

@Steve It was used for multiple different and unrelated purposes because people writing SQL where just bashing things together and picked something that sort of made sense. Treating quirky language choices as "very good design reasons" is language-hubris! More importantly, because NULL has no coherent meaning, extending the meaning of NULL to more cases than the eclectic mix of features SQL has has no coherent solution. How should NULL be handled when passed to an operation SQL lacks? You get to make it up, like the designers of SQL did at the time, and you'll get quirks.

What "all this trouble" means is that sometimes communication isn't easy, and what seems straightforward and clear to you isn't necessarily as clear to other people, so sometimes you have to put in a bit of effort to choose different words or clear up distracting side points, so that people aren't talking past each other. Repeatedly telling people that they should understand, and are idiots if they don't, rarely helps.

Your question puts me in mind of data oriented design, which often takes the form of "table based" approach to programming. I don't know if there's a mainstream DOD-based programming language yet (akin to Java/Smalltalk for OOP), but I'd imagine someone is researching it.

@IMSoP, well one thing I've taken on board is that when I'm asking a question - as a computing expert with considerable general knowledge already - it is almost certain to be something highly obscure, whose implied details would probably be obvious only to others with comparably deep expertise, and I'm implicitly looking for someone who already knows more than me (including whatever I can already gain from research). It might not always be obvious to others how little they know. (1/2)

I noticed contemporaneously how quickly I was getting riled in the role of a questioner, compared to my relatively long patience in my usual role as an answerer. I think the root of this - besides my own towering arrogance - is that I'm not particularly well-known here and I obviously hadn't made my grade of expertise sufficiently clear, which perhaps would have produced more pause for thought before some of the less useful replies were plied. (2/2)

@R.M., yes it's a good point. What they're calling "data-oriented design" is basically just a return to the status quo ante before OOP, of structured programming, procedural code, and data separate from algorithms.

@K.A.Buhr, Haskell? Good heavens, the best cure since they gave electroshock to Hemingway.

I think you're looking for Informix-4GL, Natural/ADABAS, 4Js Genero, OpenEdgge ABL, OpenROAD, etc.

@user71659, yes I'd say (as a non-user who has quickly looked them up...) those are potentially languages meeting the criteria. Have you any insight to offer as to why they aren't as popular as SQL itself?

PowerBuilder is an SQL based language for building thick client front ends off an SQL database. I would not recommend - having to read it in order to port away is bad enough.

@Steve I suspect the issue is developers don't want to learn a language and build skills with a narrow application space, coupled with the fact that there's no clear winner and that ends up in a proprietary stack.

@user71659, that aligns with my suspicions.

@Steve "Have you any insight to offer as to why they aren't as popular as SQL itself? ". Mostly because while very well suited to doing SQL, they're not very well suited to doing anything else. I've worked a lot with Informix 4gl and Genero over the years, and they are not fun languages to work with, despite the many improvements Genero has made over its predecessor.

As a general rule, you can't hire developers who already know those languages... and if you ask the developers you do hire to work on them, they tend to resign because they'd rather work on something that's more fun and/or looks better on their CV.

@marcelm, at times I'm tempted to think I use too many words, but then the extremity of misunderstanding suggests I've used far too few. The purpose of certain sentences is to show what thinking has produced the question (such as about the well-adaptation of SQL, showing clearly that I regard it as the non-negotiable in the overall stack of languages) - I'm happy to sustain an explicit frame challenge, but I don't want people just talking at cross purposes to me, although they have anyway. Hopefully that explains why I regarded the opener of J Mini's answer as fighting talk, said playfully.

@Steve I disagree with the premise that more words correlates with more clarity. In fact, I find that often the opposite is true. The key is to ensure every word is important to the essence of your communication.

@marcelm, I agree, and I've explained that an example you adduced of fluff actually had a specifically intended purpose when I wrote it. I'm not immune to rambling and wordy sentences, but many of you appear to be just complaining that the question is not sufficiently simple or reducible to a pithy one-liner, when there is no reason it ought to be. As for lack of clarity, I'm not at all satisfied that those lodging complaints have first attempted reasonable interpretation. (1/2)

"It has various characteristics..." was used to introduce a list of relevant characteristics, and I recall that I first wrote that sentence without the parenthetical remark, then added the parenthesis to emphasise that I was listing an intentional selection. I could reword it to maybe achieve greater artfulness as a sentence, but I struggle to see how I could actually purge words from the overall count, or that it is particularly infelicitous (let alone so inept as to be worthy of your main focus). (2/2)

@steve You write, "I could reword it to maybe achieve greater artfulness as a sentence, but I struggle to see how I could actually purge words from the overall count, or that it is particularly infelicitous (let alone so inept as to be worthy of your main focus)." (244 chars) - I might say, "I could improve it, but I fail to see how to make it shorter, or that it even needs to be." (90 chars). That's the same message, in about a third of the characters and much clearer. Your wordiness makes it hard for me to parse out what you actually mean, and I suspect I'm not the only one.

@marcelm, nicely done, although it is less specific. I meant the available margin of improvement shows you to be a nit-picker whose attention is misdirected, and I didn't want that to be only implicit.

While the responses to this question seem to have gone irretrievably off-track, I do think that there is a useful core question something along the lines of "Why was the approach of the group of general-purpose 'fourth-generation languages' that were tightly coupled with SQL not more widely adopted?". The body would identify the aspects you're most interested in, which I think are particularly creating user interfaces and the relational data model, and the question wouldn't start from the premise that these never existed. This would be a separate, shorter question about design characteristics.

@MichaelHomer, I couldn't cope with another question!