Should semi-specialized services such as databases and GUI kits be generally separate services with language-specific adapters or be heavily integrated into application languages to better fit its specific idioms and conventions?

----

''Let's add to that: mathematical expressions, numbers, collections, logical operators, standard console IO, string manipulation and regexps, and so on. These are all semi-specialized services to the same level as databases. One could easily use a separate service.''

To some extent I agree and some could indeed be nicely treated as a separate service. But some tend to differ in that they largely don't require or build "complex structures". Services that have simple inputs, complex processing, and simple outputs are generally not at issue and could be internal or add-ons without being able to tell the difference or care. But, as soon as the need to manage and manipulate complex structures arises, then one generally has to pick between arrays, linked lists, objects, tables, etc. and decide if and how to integrate these with specific languages and their type systems (if they have one). It is difficult to make a "generic structure" that closely fits the style and feel of each different app language. -t


''Complex structure and complex processing are one and the same. You've argued elsewhere (with me in ViolentAgreement - i.e. same conclusions, different reasoning) that DataAndCodeAreTheSameThing. To suggest that mathematical expressions are any less of a 'complex structure' seems a bit naive, or perhaps depends on an assumption as to exactly which is occurring: do you ship code to the data, or do you ship the data to the code? Whichever one is 'static' seems simpler, but (for many reasons) neither should 'in general' be static: ship the smaller to the larger for bandwidth performance, ship the public to the private (to protect privacy), ship the fast-changing to the slow-changing (to allow greater indexing or compilation-based optimizations), ship both for load-balancing, redundancy, reliability, and utilization. To suggest arbitrary distinctions between 'language' and 'separate service' based on yet another arbitrary distinction between 'code structure' and 'data structure' only succeeds in being twice arbitrary.''

''You also seem to be arguing under the impression that, say, dedicated databases will necessarily be 'better' at their job than would be a language with database-like-features. However, this impression simply fails to account for the AccidentalComplexity and DiscontinuitySpike that such a separation introduces. Management of data lifetimes and GarbageCollection (i.e. volatility), visibility and scope (for security and safety), and so on will be hindered. Difficulty with type-translation is well-known, but far from the only significant challenge such artificial division introduces. The discontinuity cost is felt by every user of the tool, whereas the cost of database-like-features is felt heavily by the language developer and high-performance implementions - but then results in a savings for each user, and quite feasibly integrates with foreign utilities (like ODBC) better than ever before due to a reduced gap between them.'' 

''One might argue that, supposedly, the reliability and performance features of the database (i.e. persistence, consistency for transactions, ability to 'export' data into a human-readable and machine-parseable format, LDAP-style distribution, caching, load balancing, security) will somehow be 'better' than those of the language. But there is nothing inherently true in that claim. If one can query for ad-hoc data, one can back-up any persistent database. If one can modify arbitrary data, one can thrash any persistent database. Failure to support persistence, concurrency, distribution, load-balancing, and security within a language only results in it being reinvented repeatedly in a buggy, slow, ad-hoc manner.''

''As far as needing to 'pick' between arrays, linked-lists, objects, tables, etc. - well, the language designer does need to make some choices or distinctions, I agree. But one needn't always pick and choose. Arrays and linked-lists, for example, can easily be one and the same under the hood. I use ropes (a k-arity tree of arrays of values) to represent linked-lists in my language, getting both the purity of linked-lists and (nearly) the performance of arrays (same algorithmic performance for access after accounting for virtual memory, much better performance for appends, inserts, deletes). I support 'sets' with uniqueness and permutative identity, and those also get an optimization: sets of records (aka 'relations') get free binary k-space partitioning to support high-performance lookups and inserts (effectively, they're indexed on every attribute). Similarly, natural numbers are logically represented in unary (Nat = s(Nat)|zero), but physically represented in binary.'' 

''Some choice needs to be made for the abstraction and the interface, but it only takes a few "intrinsic functions" and "de-facto optimizations" to massively reduce the need for LanguageIdiomClutter.''

--------

''I'm curious as to how "language-specific adapter" is incompatible with "heavily integrated".''

Does the above answer this to your satisfaction?

''It did not. A "language-specific adapter", to my eyes, could easily involve a great deal of design to support composable abstractions when adapting to a common class of services. Further, I note that many such adaptations can easily become heavily integrated with the language (i.e. common to its standard libraries).''

-----

Working abbreviations used in this document:

* AL - Application Language - The programming language used for domain software
* KS - Kit/Service - The kit or service being sought after. This may include but are not limited to:

** Database or collection-oriented services
** UI's and GUI's
** Report generators
** Graphs and charts (bar, line, scatter-plots, stacked, etc.)
** Publication layouts (Example tool: LaTex)
** Text/document search

-------

Moved from PersistentLanguage


''One thing we have to consider is '''standards'''.''

Standards are languages.

* ''Not necessarily application languages.''
* How is such a distinction useful in this context?

''It's not practical to re-invent things like DBs and GUI engines for each and every app language.''

Disagree. It is entirely practical to re-invent APIs to DB and GUI engines (and other features like MultiCaster, filesystem access, control of actuators) for every significant application language, then provide behind-the-scenes adapters to outside systems that match the reinvented API. 

* ''Please clarify. What "reinvented" API are you referring to?''
* I refer to APIs for DB and GUI engines among others, but that should have been clear. Any API is a language (ApiIsLanguage) that integrates a service. Everything past the API - such as whether the service is implemented inside the language or in some other process - is implementation-detail and does not deserve further continuation (though the API should be designed to support implementation). Consider that forcing programmers to use SQL strings directly is just one API among many - one rather specific to whichever database they're working with, and likely poorly adapted to the behavior language.

Your approach is to force programmers to use some third-party language explicitly from the application language. This introduces explicit translation efforts, which are repeated by every programmer for every project for the lifetime of the language. Not only is the application language tied pointlessly to lowest-common-denominator legacy systems, but the productivity cost for very large projects or across different projects probably is worse by at least an order of magnitude. 

* ''One needs to look at all the costs and benefits. I agree it's nice to fit the app languages (AL) like a glove, but it also means that one has to learn a different kit/service (KS) for each different app language. And it also means that implementations of the kit have to be largely repeated for each AL. If you have 100 AL's, this means approximately up to 100 times the effort to create and update the KS. This means effort is diverted to adapting to specific ALs instead of making the KS the best possible KS. That effort of wheel-reinvention is just not going to happen.''
* You make some illogical leaps about what fitting a language "also means". Consider:
** You need to learn a different syntax for each different language anyway; learning to do mathematical expressions, database operations, string manipulations, GUI construction, logical operators, console IO using that syntax is all just part of learning the syntax and semantics and ''how to use'' a language. 
*** ''Yes, but that's not a difference-maker. It's a cost that will be borne under either scenario. Learning the ins-and-outs of a GUI kit, on the other hand, can be simplified if there is a super-language GUI standard.''
*** Indeed. Similarly, learning to use mathematics, string manipulations, logical operations, and console IO are all aided by super-language standards. Thus, the argument you just supplied is the one that is not a difference-maker.
*** ''But app-specific GUIs and DBs tend to be heavily shaped by the language's idioms. They are not universal concepts, except maybe in a very general sense. Thus, it's not comparable to the field of mathematics. Math notation has been shaped and refined over hundreds of years of trial-and-error and academic consensus to create a standard. Maybe someday they will, but not now. -t''
*** Mathematical expression within any given programming language is just as heavily shaped and influenced by the language's idioms. There are significant differences in how languages express functions, sets, etc. for computations. And if you're saying: "GUIs and DBs belong in the language just as soon as they settle down", then I'd suggest that certain properties (dataflow and realtime views, persistence, concurrency, transactions) are already well-established as desirable and should be effectively supported by the language - i.e. enough to close ''most'' of the gap between languages and databases/GUIs, if not all the way. The choice of integrating 'relational' vs. 'navigational' database, or a declarative SceneGraph vs. procedural sketchpad based GUI, could still be a library/module level decision. 
*** ''I'm a bit skeptical, I'd like to examine such a critter.''
*** Your position seems to be: "persistence and transactions are database-like features! Those belongs in a database! keep your database-like-features out of my languages!". You have said '''nothing''' to justify this hard-line position. You have said that you feel people might take advantage of database-like features to (oh my gawd) implement a database within the language that is tightly integrated with the language. The only argument you've presented that this is a bad thing is that it is usually difficult to do (with such nonsensical whining as: but you can't do it for ''every'' "app-language", so you shouldn't do it for ''any'' of them).
*** ''My experience is that "database-like things" rarely happen in isolation such that you use transactions and only transactions and no other database-like feature. And the few times they do stay isolated are not know-able up-front. One only finds out after observing for a decade or so. If you start needing a few of these other idioms outside of your app's language, then you have to '''convert a lot''' of stuff over to DB-land. ''
*** ''As humans with limited brains, we need to DivideAndConquer our work-space to focus efforts, staff, goals, etc. Sometimes the divisions are arbitrary and sometimes they follow along semi-natural lines of related items. Database-idioms are not a perfect division of labor/focus, but they are a pretty good one. Thus, since we need divisions, we might as well go with natural ones (or at least true-and-tried ones). DB's are a pretty good UsefulLie. (I'd suggest using SQL or something close in the language for light-duty-tables so that you don't have to re-write much when you up-scale to a real RDBMS.)''
*** You seem to still be operating under the strange faith that persistence+transactions+concurrency is a database. I think you've got it backwards: persistence+transactions+concurrency(+distribution) are '''language features''' that database '''management systems''' had to integrate to deal with enterprise workloads. The 'database' itself is a service with an API and a contract for reliably storing and sharing data in an ad-hoc manner. So, to think about what you said from a ''slightly'' different perspective: ''if a DBMS starts needing a few of these reliability and safety properties that aren't initially in the app-language used to implement it, the DBMS becomes subject to GreenspunsTenthRuleOfProgramming and is forced to reimplement another language and virtual-machine under-the-hood.''  I think ''any'' service written in a language will need to support the same features in order to support enterprise workloads. Databases are merely one instance of a service that benefits from reliable persistence.
*** ''Of course if a given language does everything in the world, then you maybe don't need a database.'' 
*** Why not? If a given language did everything in the world, it is almost certainly the case that one of those things you'd want it to do is reliably store and share data, and you'd want it to support privacy and distinct ownership - i.e. you'd want it to include databases (plural). They'd be inside the language runtime, of course, but they'd still be databases: they'd still be services with contracts that match that of any database.
*** ''Get it built, test it the field, perfect it, then maybe I'll try it.''
*** Let me know of one 'perfect' database you've used so I can have your measure of perfection, and perhaps I'll consider that a reasonable request.
*** ''Even the imperfect ones are far superior to your massive repetitious reinvention plan. I don't even have to bother arguing against it because I'm sure most readers will agree you are an outlier on this.''
*** Keep attacking that "repetitious reinvention" straw-man and I wouldn't need to argue against you except to handle the less rational readers. The rational ones will see exactly what you're doing: making wild assumptions then attacking figments of your own imagination.
*** ''It's just you and your dog, bub.''

*** ''I don't find it practical to assume everyone is going to switch to the One True App Language anytime soon. There will be a hundred or so "common" app languages in use for the foreseeable future and they are not going to suddenly disappear, for good or bad. I will proceed with this assumption. Giving that, even if we entertain the far-off possibility that one app language does implement enough database-like features to never have to switch to a real DBMS to get a full set, what about the '''other 99 app languages?''' You solved only 1 percent of the problem. Then you put all those features into language B, with yet another million lines of code, and you then solved 2 percent of the problem. Then you put all those features into language C (ordinal, not "C" literally), with yet another million lines of code, and you then solved 3 percent of the problem. I am tempted to accuse you of not being grounded in reality in a snide way, but am resisting because I don't want to become like you. -t''
*** You've solved one major problem for users of a chosen app-language. Unless you're writing a DomainSpecificLanguage, other 99 are '''competition''': even if you acknowledge that they won't go away, you have little responsibility to support them beyond whatever level of support you normally provide for inter-service communication and integrating with the outside world (which you'll need to do for actuators, sensors, hardware, distribution protocols, etc.). Whereas your language gets some cool new features, they'll be stuck either interfacing to your language or talking to a less effectively integrated persistence system and paying the associated performance and explicit translation costs. Your users will have 'one less thing to worry about getting right' - at least if you did well. The way you talk, it's analogous to expecting the developers of Oracle to upgrade dBase and WebOntologyLanguage and so on for every new feature they suggest for SQL. 
*** Besides, even if you wanted to, BackwardsCompatibility and need to support existing modules and APIs restricts you from adding just any feature to just any language without effectively creating a new language. You can't simply add 'persistence' to the C language, for example, because that would break existing modules. Nor can you easily toss out the existing libraries (let's pretend POSIX never existed...). The only time one can perform unrestricted design on a language is BigDesignUpFront, which had better be informed from many other language designs because you'll get stuck with whatever the design is long before version 1.0 is released. Those 99 other languages ''and'' the one you designed for persistence and database-like-features will eventually become obsolete, being replaced by another 100 languages, a few of which (after accounting for both the kernel and the standard libs) are likely 'better' by every metric one would ever care to name.
*** ''Neither of the above paragraphs are clear to me. I don't know what you are mentally comparing to what, practical issues or your ideal environment. Please be more explicit.''
*** To be more explicit: I think you're an utter moron for believing it necessary to upgrade all 100 app languages. The first paragraph says why you're being stupid in marketing terms (app-languages '''compete'''; expecting developers to upgrade all app languages is analogous to expecting Oracle to upgrade all other DB languages for every change to SQL). The second one says why it's impossible technically and pointless to try (BackwardsCompatibility, the natural cycle of obsolescense). You've got this ludicrous idea in your head that all 100 app languages must be upgraded in lockstep.
*** ''The bottom line is that if you make a decent tool that is designed to be used by multiple languages then other languages can start using it with only minor wrappers being built. If instead you repeat the implementation of the tool for each app language, your total effort is much larger. This allows the tool builder(s) to focus on making a good tool instead of re-adapting it to umpteen languages.''
*** The bottom line fails. Why? Because you made three bad assumptions. The first is when you said: ''"other languages can start using it with only minor wrappers being built".'' Unless the tool's protocol and API is a close match for the language, that simply isn't true. Your ideal view of the database world is blinding you to its reality. The second bad assumption: ''"for each app language"'', which is already explained. The third bad assumption: you assume database language/protocol will necessarily make better "tools designed to be used by multiple languages" than APIs for another "app languages". ForeignFunctionInterface, AlternateHardAndSoftLayers, ScriptingLanguageAgnosticSystem and such allow otherwise. They won't be 'minor' wrappers unless the languages are a close match, of course, but neither would there be a 'minor' wrapper for a database tool.
*** ''Sticking something equivalent to Oracle's code base into 100 languages is just plain stupid.''
*** Yes. It is. Now ask yourself: who was the idiot who thought it necessary? That'd be TopMind, right?
*** ''One can get the power of Oracle by hooking up to an Oracle database. They don't have to wait until somebody puts an equivalent of it into their shop app language. How else is the power of Oracle going to get in there? I agree a C-based kit could simplify some of it for app language inclusion for languages based on C compilers, but it would still be a hell of a lot of work to adapt it closely to each language, and make the interpreter/compiler mighty large.''
*** Wrong. You can only get ''a small fraction'' of the power of Oracle by hooking up to an Oracle database. To get more power, you'll need to deeply integrate Oracle into every part of your development: IntegratedDevelopmentEnvironment and RefactoringBrowser, UnitTest, Typing, Debugging, ConfigurationManagement. From a 'hook up' to language L or a library written in L, you can also leverage a small fraction of the power of L much the same as Ruby code will call into CeeLanguage functions to get the performance advantage of C. From L, perhaps it is some other property - maybe performance, maybe persistence... or maybe distribution / load-balancing / dataflow / concurrency management / etc. 
*** Further, "hooking up to an Oracle database" '''is generally NOT a trivial task'''. To integrate an application with Oracle requires deep, non-local design considerations for startup, shutdown, configuration, connection maintenance, temporaries and GarbageCollection, translations, multi-user considerations and security, and modularity or PluginArchitecture. Access to the database often becomes explicit and pervasive. Just to point out your bad logic is also ''inconsistent'': what about this integration cost per application? Surely there are '''more than 100''' applications per programming language that might benefit from deeply integrated database-like-features, right? Your GreencoddsTenthRuleOfProgramming suggests as much, and that's even before adding plugins to the mix. So, when does the cost of hooking the Oracle database into 100 applications plus an IDE and debugger outweigh the cost of having had database-like-features in the language from the start?
*** 'Hook up' doesn't require foresight in design. When using external services to gain a feature, that is its primary advantage. It also doesn't introduce a cost (i.e. persistence) for applications that don't need to pay it, though that advantage is secondary and more questionable (especially when dealing with PluginArchitecture, the tendency to end up paying for VirtualMemory anyway, the potential for whole-program optimization to exclude verifiably unnecessary features, and so on). 'Hook up' still has an implementation burden that is at least as high as having integrated it in the first place: it involves greenspunning a whole damn virtual machine and framework to implement the feature. The DiscontinuitySpike and AccidentalComplexity and productivity cost of the "hook up" burden, plus cost for debugging, development, and unit-testing when 'hooking' into an external service, are all counting against that design - especially for what would ideally have been a language feature in the first place. (Just to be clear: outside of achieving what should have been language features, 'hook up' to external service is also used for services that live longer than an application instance - preceding it, surviving it: printer, monitor, keyboard, clock, domain name service, databases for 'data' as opposed to PersistenceLayer, and so on.)


*** ''Re: "but you can't do it for every "app-language", so you shouldn't do it for any of them" -- I'm not against that, but if you do that, you are not solving the bigger problem, but "fixing" only pockets. And knowledge of say GUI's from one app does not easily transfer to another GUI system. And, it's poor factoring of human effort. You have to agree that reinventing the wheel for each and every app language, or even families of languages, is not something to be happy about. OnceAndOnlyOnce is in general a good thing. It is not "nonsensical".''
*** Your logic is inconsistent, and non-sensical. If your goal is OnceAndOnlyOnce, then you need to achieve it for the app-language (one language to rule them). If you accept "many app-languages", then you've already kicked OnceAndOnlyOnce squarely in the groin and left it gasping on the floor. In such a case, whatever reasons you have to accept the existence of 'many app languages' will also apply to accepting 'many database implementations'.
*** ''One-True-Master-Language is not a realistic goal even if I wanted such, per above.''
*** Similarly, one-true-master-database is not a realistic goal even '''though''' you want such. As I said, the same logic applies. '''Every single reason you can give me why one-true-master-language is not a realistic goal will also, and equally, apply to the one-true-database.'''
*** ''We actually '''almost have it: SQL'''. True, that's not implementation singleness, but that's not the primary issue. At least there's fewer RDBMS than there are app languages. And one does not have learn an entirely new database language to switch between them (both learning-wise and code-conversion-wise). Similar situation with HTML: there are browser-vendor differences, but most of the HTML is (or can be) the same. Contrast this with what we have for desk-top GUI's: Java has something that's very different from Tk's which is very different from Microsoft's Win-forms (or whatever they call it this year), and so forth. Almost none of the GUI code can be cross transferred, both mentally and physically. That's ugly.''
*** You're only counting RDBMS's now, eh? Nice bunch of cherries you have picked, there, but perhaps you should include alternative databases (e.g. DHTs) in the mix, too, so long as they match the common concept of storing data, sharing data, and supporting queries on data. But, yes, I agree that 'databases' are a lot closer to being 'settled' (and therefore suitable for direct inclusion in the language, according to your earlier logic about mathematical operations) than is the GUI. The RelationalModel provides a fine, high-performance model for data management. So long as the language still supported dragging in data from external sources, it would be difficult to fault an 'app-language' for a decision to include standard, high quality support for RelationalModel and queries.
*** ''DHT's are not compatible with much. Why even concern ourselves with them in this topic?'' 
*** DHT's aren't compatible with much? Can you even name '''one''' app-language with which DHTs are incompatible but RDBMS is compatible? And I bring it up because you made an invalid generalization.
*** ''And, I am not against a lite-duty SQL-engine included with app languages. However, if I want more DB power/features, it's nice to be able to switch to a real DBMS without changing much of the code. An app-lang-specific flavor of query language cannot do this, at least not without an ugly translation layer.'' 
*** It isn't as though you're avoiding "an ugly translation layer". No, your code is simply "ugly" ''all'' the time. If I want more ''language'' power/features - including persistence and concurrency - I'd also like to get them without changing much code. I just don't expect miracles. It isn't as though your approach gives you a free lunch, either; there are some massive costs for your design, paid on a per-application basis.
*** ''Why are you so '''anti-external-service'''?'' 
*** I'm not "anti-external-service". Sensors and actuators certainly must be treated as external services. And I'm all for a 'live objects' layer in programming languages, making it easy to 'hook' into external systems whether they be sensors, actuators, or programmer defined. I am, however, pro-productivity, pro-performance, pro-safety, pro-security, pro-reliability, pro-modularity, and so on. Relying on external services, frameworks, or APIs to provide language features requires explicit interaction with said service, often in a non-local manner that must be distributed pervasively throughout the program code. That is MissingFeatureSmell, anti-productivity, and unreliable in the face of modularity. So, '''the ability to use frameworks, APIs, and external services must not be accompanied by a reliance upon them for pervasive language features'''. Using a 3rd party database to store and share data about the world or perform queries upon it is fine. Using it as a PersistenceLayer for application instances, however, is awful, and will require exactly the sort of anti-productive explicit weaving of database code throughout application operations that should be avoided. Reliability across power cycles and other disruptions is a desirable feature for ''programs in general'', not just databases, and so good support for persistence makes a useful language feature. It isn't a matter of being "anti-external-service", but rather of seeing a larger picture. 

** Many so-called 'app languages' are similar and will fit well with the same or similar toolkits and may share implementations. Only when there are differences in capabilities or a severe language mismatch that forces too many layers of translation and indirection is a new implementation needed. 
*** ''I agree there could be some sharing between similar languages, such as Python and Ruby, but that's merely something in-between the two positions being considered. It changes the granularity to app language families instead of languages.''
*** Oh? Are you sure that's a "mere" difference? Perhaps there is no significant difference, either, between arbitrary individual values and sets/collections, right?
*** ''Please clarify. What does this response have to do with language families?''
*** You don't see the categorical similarities between 'language vs. family of languages' and 'value vs. set of values'?
*** ''An API that depends heavily on multiple inheritance, for example, is going to be ugly on languages that don't directly support it. Some kind of compromised emulation will be required.''
*** Indeed. Similarly an API that depends on declarative logic queries is going to be ugly in a language that doesn't directly support them (such as procedural languages). Some kind of compromised emulation is required. You seem to be favoring such compromise. Compromise doesn't work; it's why DesignByCommittee languages tend to bloat up (CreepingFeaturitis) then fail.
*** ''Where did I promote only committee-built tools? HTML was designed by two guys, I would note. -t''
*** I didn't say you promoted committee-built tools. I very clearly said: "you seem to be favoring '''compromise'''." The mention of committees regards why compromise doesn't work. I feel frustrated now: it is my impression that you're off in your own little world reading words that I neither wrote nor implied, then blaming me for your confusion.
*** ''"Compromise" and "committee" are such weakly-related things that I was taken back by the dire implication ("bloat...fail"). '''Engineering itself is largely the art of compromise'''. It goes with the territory, not something that can be wished away. We weigh jillions of trade-offs whether working by ourselves or many others. (I suppose you may have an idealism tilt that doesn't see things that way. In that sense, our world views are so different that we'll probably never communicate smoothly.)''
*** Engineering involves compromise, I agree. Design, however, is the other half of the equation. Engineering is the technique of making compromises that achieve (without compromising) a design. Engineering without a design doesn't involve trade-offs; all decisions are equally pointless if there is no goal. Design is the art of making useful distinctions, and is very much subject to idealism. A good designer will ensure the distinctions are also feasible, such that they can be achieved without compromising the implementation. You distinguish between engineering and design all the time: you say that XYZ is an 'implementation detail', whereas ABC is 'part of how users interact with the system'. The same is true here. Compromises in engineering (i.e. trading space for performance 'implementation details') do not imply compromises in design.
*** ''Without specifics it's hard to agree or disagree. Implementation may affect user interface for various practical reasons. Thus, it's not always cut-and-dry. The boundary between engineering and design is also fuzzy.''
*** The two disciplines are 'coupled', but not very 'fuzzy'. To say two concepts are "fuzzy" is to suggest there is a continuum in which all lines or distinctions that might possibly be drawn between them are arbitrary and unjustifiable. You've been attempting to convince me of "fuzzy" distinctions this entire page, such as your position regarding 'app languages', code vs. data, simple vs. complex structures, etc. ''Coupled'' concepts may share elements (i.e. they overlap) but may still be distinct on the whole. Examples of coupled concepts include collections and individuals (overlapping for collections-of-one and individual-collections), imperative and declarative (the 'primitives' of imperative programming are declarative, but the means of composition is not - PrimitivesAndMeansOfComposition), and engineering vs. design which are coupled for 'feasibility' concerns - whether a design or engineering tradeoff can be achieved with given resources (including time, money, equipment). I am irked by your tendency to use the word 'fuzzy' even when it isn't appropriate according to, say, the definition of FuzzyLogic or the dictionary definitions (indistinct, blurred, incoherent). Similarly, you overuse the word 'relative', sometimes to mean 'fuzzy' and sometimes to mean 'subjective' and only rarely for the English meaning 'property must be judged in comparison to another system'. I'm certain your inconsistent use of vocabulary is one source of regular confusion between us. English is vague enough without your caprice.
*** ''"Coupled" is not a clear word either. Anyhow, I don't want to get into another definition debate. I'm hoping to explore case studies and examples to reduce the need to rely on English alone.''

''This implies that there will be a separation between such components and the app language.'' 

Even if your prior statement wasn't false, this separation isn't implied. Integration for any given app language is a much smaller effort than integration for "each and every app language".

''Ideally everything is fully integrated into our favorite app engine and we don't have to worry about the outside world.'' 

What a ridiculous statement. Ideally our favorite app engine is designed to effectively integrate with the outside world. What good is an application language that cannot do so?

''In practice, that's not going to happen due to the combinatorial explosion of integration effort. In my observation, the popularity of SQL and HTML is largely because they can be used with just about any app language.  -t''

Most integration efforts are incremental. 

A "combinatorial explosion of integration effort" will only exist if you did something horribly wrong, such as distinct ad-hoc adaptations to slightly different but largely similar systems, poorly composable designs using locks, using name-based references between project components (which require each component know how to map and use the name) instead of using objects, forcing programmers to explicitly translate types between systems at any place but the very edge of the system, overuse of opaque data structures like strings and binaries, or overly prolific use of HelpersInsteadOfWrappers - which forces programmers to know every detail of every system they integrate, and which also compose poorly because every part of the program needs to know how to use the helper instead of a more generic wrapper.

* ''It's not clear to me what you are comparing here. There can be formal wrappers and informal wrappers to external "services". The formal/informal decision is not part of this topic. But either kind is going to have some app-language-specific "conversion cost". That I won't dispute. I'm not saying that separate services are free of down-sides. I'm just saying the up-sides outweigh the downsides.''
* What's at issue is the question: is it the user of the language (or API) vs. the implementor of the language (or API) who suffers the 'cost' of integration? This has nothing to do with "formal vs. informal" wrappers, but it does have to do with "complete vs. details-exposed" wrappers, and with "deeply safe, high performance, and otherwise symmetric and interweaved vs. hacked atop the language with many gotchas" wrappers. Anyhow, I challenge you to defend your claim that "the up-sides outweigh the down-sides". Evidence?
* ''One thing at a time. The '''tools developer versus app-developer''' is certainly an interesting trade-off to investigate. It has come up before in another topic regarding how polymorphism allegedly helps the API builder versus API user (will link when re-found). But, they are '''related'''. There's only so much tool-builder programming time to go around. If they spend it all on custom variations per language, then they will not be able to spend it on making the best GUI system or best database or whatever tool. (And the learning curve for the app developer if the per-language kits are too different, which I'll let stay at another spot.) As far as "type safety" and all that, we already have topics on those. Your approach is a TechniqueWithManyPrerequisites, and I'm working on the assumption that the industry will not adopt those any time soon and thus am exploring the space-time path in which those prerequisites do not occur.''
* RE: ''"There's only so much tool-builder programming time to go around."'' - This is true in practice, I agree. Perhaps it is the problem that needs fixing. If we had a sufficiently "open" programming environment such that the distinction between 'tool developer' and 'tool user' was strongly diminished, the problems associated with that artificial distinction would be largely diminished. Something like an online WikiIde that supports cross-project refactoring and global multi-project unit tests and integration tests might be a solution (or part of one).
* RE: ''"If they spend it all on custom variations per language, then they will not be able to spend it on making the best GUI system or best database or whatever tool."'' - That does not logically follow. If one is trying to make a best language, making the best GUI system or best database or whatever tool will certainly be part of it. Further, while only a fraction of all languages will receive the royal treatment, other languages in the same family (i.e. procedural vs. declarative, or using the same JVM/CLR, or whatever) can readily take advantage of such systems via a ForeignFunctionInterface.
* RE: ''"Your approach is a TechniqueWithManyPrerequisites, and I'm working on the assumption that the industry will not adopt those any time soon and thus am exploring the space-time path in which those prerequisites do not occur."'' - My approach allows for integration with existing systems, but I agree that it does require more design effort up-front before performing such an integration (in order to ensure the integration composes smoothly within the language under wide variety of use-cases). You assume that such pre-requisites are unacceptable, but you also say you doing some development work in accordance with this assumption. What, exactly, are you "working on"? Any TableOrientedProgramming implementation coming soon? If you are expressing an opinion of how you think ''other'' people should design their languages, you need to be more logical, more convincing; saying that TopMind is convinced then requesting counter-examples is insufficient.
* ''I'm attempting to avoid a value judgment on your favorite techniques. Here, I'm merely pointing out that the industry is not likely to adopt your techniques any time soon, for good or bad, and that we need to find a palatable way to get better services/standards for things like GUI's. I'm looking for the nearest hill, not necessarily the nearest mountain.''
* That's fair. Nonetheless, the topic question (''"Should semi-specialized services such as databases and GUI kits be generally separate services with language-specific adapters or be heavily integrated into application languages to better fit its specific idioms and conventions?"'') is precisely about making a value-judgement. All questions of "should" and "ought" do so. It is reasonable to scope such a judgement to a given context (i.e. what should we do under conditions where we may only change one small element at a time and must then stabilize for a long period after each change?). As is, however, the OP question does not indicate such a context.
* ''That's technically true, -'' 
* Those are the only truths that matter in technology.
** ''Not it's not. If your boss/client doesn't buy into a good idea, then it's moot, for example. ''
** That's not a technology concern. When it comes to marketing and market success, a more realistic rule is: '''only perception and reputation matter'''. Truth is often unpopular (especially if it's a scary truth), and quality is an expensive, inefficient mechanism to achieve a perception better than that of the competitor.
** ''Those are real issues to us practitioners, whether we want them to be or not.''
** I never said they weren't issues. They just aren't relevant to truth in technology.
** ''But when considering how to "interact" with existing languages and the people who manage them, we must consider the "culture and environment" also. If you lived on a planet with only perfect clones of yourself, it may be a different matter. (I'd kill myself on the way down before landing on your clone planet.)''
** Culture and environment matter, yes. Environment is technical, and culture can shape and influence it.

* ''- but it doesn't scale. Otherwise we'd have a combinatorial explosion of topics like IdealGuiWhenTheWorldUnderstandsThatFpIsBest, IdealGuiWhenTheWorldUnderstandsThatOopIsBest, IdealGuiWhenTheWorldUnderstandsThatLogicalProgrammingIsBest, and so on.''
* Why do you suggest such topics do not exist? It seems 'GUI where FP is best' is well described in terms of DataflowProgramming and FunctionalReactiveProgramming. That 'GUI where OOP is best' is described well in terms of SceneGraph languages or the oft-repeated 'cirle/square inherit from figure' system. That 'GUI where Logical Programming is Best' is well described by DeclarativeGui. That 'GUI where procedural is best' is well described by PostScript and LogoLanguage styles. Methinks you are wearing a neat pair of blinders to ignore such obvious examples of the topics you name.
* ''Ignore? They prove my point: a bunch of fan-boys preaching to their own choirs.''
* Yes, you ignored them ("otherwise we'd have") whether you now think they prove your point or not. If your point was: "it doesn't scale because it breaks the system down into a bunch of fan-boys preaching to their own choirs", you should reword your philosophy as: "we need one language to rule all the fanboys, because nothing else will scale".

As an aside, your comment on SQL and HTML is irrational, illogical, and poorly reasoned. It's a bit like saying: "The reason TopMind is unpopular is because he's human" without accounting for the fact that not all humans are unpopular. Unless your 'observation' could say why all other PowerOfPlainText languages aren't, 'largely', '''equally''' popular with SQL and HTML, it's sunk. 

''It's difficult to "prove" population preference reasons unless you dissect thousands of neurons directly. We can only observe patterns and imperfect clues. Thus, there is no double-blind certified study for either side, so stop your whining and name-calling. That being said, PowerOfPlainText-based protocols have been more successful than the alternatives. HTML and SQL have proven popular (despite their flaws) and there are few if any AL-competitors that are as widespread. You are welcome to name some. -t''

We can do more than observe patterns. We can apply logic, which you failed to do. Your "side" seems to consist of making a few observations then pulling some bullshit out of your ass to explain it. Intelligent and reasonable people systematically process and refine your observations so they at least reasonably match your observations and imperfect clues. If you want people to stop calling you on your fallacy, then shape up or ship out. 

* ''That criticism is not specific enough for me to use. It looks like boiler-plate whining to me. If you find insufficient detail for point X, then politely ask for more details about X rather than spend a paragraph whining about there not being more details about X.''
* "Insufficient detail" was not the issue. Fallacy was. If I said "the sky is blue because I said so", then no amount of detail about why I said so will make that argument a valid one, and asking you to present evidence that the sky isn't blue would just be more proof that I'm a nut. Similarly, when you said "HTML and SQL are popular because they can be used with any app language", no amount of detail will save your argument, and you later asking me to name widespread competitors is further proof that you are a nut.  No amount of detail avoids the fallacy of cherry-picking: of ignoring all the unpopular languages that can be used with any app language. You simply made an irrational, illogical statement. Suggesting that I ask for more detail is equally illogical and irrational because details about your fictions won't help you or me. You are an illogical and irrational person, it seems. Your blatherings are barely better than those of the SchizoidGibberishWikiAuthor. 
** ''Projection. You just want to complain instead of clarify because you like complaining.''
** You are delusional.
** ''You are the idealistic Ted Nelson of types.''
** ''Let's back up and revisit this. Could you make in a simplified form a version of your interpretation of my argument that corresponds to your blue-sky analogy? I don't see a connection.''
** I'll make the comparisons more direct and one-to-one:
*** In the blue-sky analogy, I say: "the sky is blue '''because''' I said so". This implies: "My saying so determines the reality of whether the sky is blue". I then suggest: "you can present evidence that the sky isn't blue, if you disagree". This in turn indicates I'm an idiot who thinks any disagreement must be with my conclusion rather than with my fallacious reasoning. The reasoning is flawed because I don't account for obvious counter-evidence, such as books indicating the sky being blue long before I said so.
*** TopMind says: "the popularity of SQL and HTML is  '''largely because''' they can be used with just about any app language". This implies: "the ability to use a standard/language like SQL and HTML with any app language largely determines its popularity". TopMind then suggests: "It's difficult to "prove" population preference [...] there are few if any AL-competitors that are as widespread. You are welcome to name some." This, in turn, indicates TopMind is an idiot who thinks any disagreement must be with his conclusion (that HTML and SQL are popular) rather than with his fallacious reasoning. The reasoning is flawed because TopMind doesn't account for obvious counter-evidence, such as the less popular PowerOfPlainText languages.
*** ''You see, we are still at the evidence-collection and exploration stage of this topic. We are not at the formal net weighing stage. Thus, complaints about applying these to conclusions are generally premature or speculative at this stage. Let's investigate related sub-topics first. If my intro implied conclusions, I apologize. ''

As far as this "either side" business goes, that's another objective point against you. Pointing out fallacies in an argument for position X does not imply arguing for position 'not X' (or: ~argumentFor(X) does not imply argumentFor(~X)). There is no "either side" involved outside your own mind. Any reasonable opinion or explanation you have about the popularity of HTML or SQL ''must'' account for the lack of popularity of its competition. Some of its competition has been equally plain-text. Requesting that I name some successful alternatives has no logical bearing on this discussion whatsoever.

''I'm not saying popularity is the only metric to use or attempt to use. But it is one we can explore in isolation as one of many useful factors. So far it looks like there are more successful plain-text-based KS's than non-plain-text-based KS's. Sure, there are also plain-text failures. This indeed does seem to imply many plain-text-based one's can and do fail and that being plain-text KS by itself is not a guarantee of success.'''That I don't dispute.''' But almost all the successful cross-platform/cross-app-language KS's are based on plain-text. Successful "binary" KS are few and far-between. Taken by itself, this suggests that text-based KS's have more potential to be successful than non-text one's.''

{What about CORBA?  Isn't that arguably a popular and successful cross-platform, multi-language, API-based (except for the IDL) KS construction set?}

''It's fizzling despite lots of initial vendor support. Plus, it does not work well with non-OOP languages. I've never met anybody using it in at least 3 large organizations I've worked at, contracted at, or visited in the last 7 or so years. WebServices are taking over its niche.''

{Indeed, WebServices are taking over.  Curiously, these use a text-based protocol (SOAP) but almost invariably employ API-based interaction.}

''I don't see much SOAP, but anyhow, aren't those API's language-specific?''

The APIs being language-specific was part of the point being made.

''Are they heavy or "light"? I am not against light adapters, in fact expect them. -t''

{What do you mean by "heavy" or "light"?  Please be sure your distinguishers are unambiguous and measurable/identifiable.}
----
I am ''so'' feeling the love between you guys!  Tell you what:  With my super-secret super-powers, to whomever of you first coughs up something useful (i.e., some working code you've written, which both reflects and exemplifies your views), I shall grant world-domination.  Sound fair?

''Promise? ;)''

First we have to get our premise strait before our promise strait. -t
-----------------
See Also: GodLanguage
--------------
CategoryInfoPackaging