God Language

A language that attempts to be everything to everybody, or at least address frequently-reoccurring concerns such as concurrency, security, collection-handling, persistence, scaling, distributed programming, exception handling, etc.

For comparison, the opposite is generally separate services that attempt to be app-language neutral.
Top's term for his personal experience of BlubParadox. {And for any language that isn't ExBase or BrainfuckLanguage...}

Paul Graham's GodLanguage would probably be a new form of Lisp with lots of libraries. I don't entirely disagree with that, but doubt it fits in with developers' existing human nature well. And, I doubt he'd buy the view that heavy types and objects will save the universe.

I've told you a million times, stop exaggerating! "Save the universe," indeed! However, when the requirements dictate "heavy types" (whatever those are) and objects, it's nice to have them. A GodLanguage, as described at the top of this page, sounds great. So does a new form of Lisp with lots of libraries.

The "requirements"? And is exaggeration different than HandWaving? I can't keep your sin classification system strait.

Don't you mean "straight"? Exaggeration is different from HandWaving. Exaggeration is "objects will save the universe", i.e., gross hyperbole. HandWaving is "Paul Graham's GodLanguage would probably be a new form of Lisp with lots of libraries", i.e., idle speculation without evidence.

Yes, "requirements". Y'know, those things that users are asking for, i.e., the reasons we write software.

Usually, it's an implementation decision, not a fundamental requirement.

Implementation decisions may be arbitrary, but they shouldn't be. They should be based on requirements.

That's the million-dollar issue: how to turn software design from an art into a practical science. When there's too many variables involved, people tend to pick their favorite variables and HobbyHorse them.

Why can't it be both? Since every new application is a unique creation, software development is obviously a craft. Crafts -- which range from making ornate cutlery to constructing skyscrapers -- are equal parts art, engineering, and science.

The majority of the sky-scraper project has to be tested via the laws of physics. For the most part those are not a matter of opinion. (Disputes about the physics of buildings can usually be settled by using math and models. In some cases the economics of testing certain scenarios to their fullest may be an issue.) Different designs can be tested against the laws of physics in a fairly straight-forward way. Physics is the elephant in the room as far as dictating options. There's nothing of comparable size in software engineering. Machine performance is the closest, but it has gradually been shrinking over time such that the "art" side of things is larger and larger component percentage-wise. (Generally I see the mid 1970's as the break-even point where software issues appeared to pass hardware issues in importance. This is based on "software crisis" sort of articles that started popping up around that time.) Engineering doesn't have the type of great holy-wars and fad-cycles that software-engineering does. The variety of different solution paths appears far greater in software engineering than in physical engineering.

To be useful, software is ultimately constrained by functional and non-functional requirements, and perhaps aesthetics. This also applies to most craft objects. The variety of different solution paths for these is infinite, but frequently constrained in practice by tradition. The construction of skyscrapers owes as much to tradition as it does to physics.

As for HobbyHorsing, yes, I've noticed your inclination to view everything through TableOrientedProgramming glasses. [moved closer to reply]

Catoring to HobbyHorses is not necessarily a bad thing. Fitting the WetWare of the developer can result in productivity gains I contend. But I don't claim that my HH will fit every mind. I don't claim One True Language/Paradigm/Methodology. You, on the other hand, seem to imply a logically-discoverable Single Right Way. But your justification and demonstration is very round-about and devoid of examinable scenarios/tests. Related: TooManyVariablesForScience. You confuse me with someone else. I have, on occasion, countered ill-considered or poorly-defended (see HandWaving) criticism (mostly yours). I have, on occasion, expressed personal interest in ObjectOrientation, FunctionalProgramming, the RelationalModel and ExtendedSetTheory, but I neither promote nor deprecate any of these. As a scientist, I only promote rigour and deprecate imprecision.

I suggest you create a handle and PersonalPage so that I don't confuse you with bracket guy (if you are different than bracket guy....bracket guys?).

I have a PersonalPage, but I believe in an EgolessWiki. I suggest you address the text in front of you, within the discussion(s) in which it appears, rather than make sweeping statements about who you assume I am. AttackIdeasNotPeople. I am sometimes bracket guy, sometimes italics guy, sometimes plain text guy, and sometimes all on one page, solely as needed to disambiguate points within a thread.

There's implications of prior debates floating around. I'll try to point them out if they appear again.
High-End of Each Idiom

Those proposing a GodLanguage on this wiki generally seem to want to take the "best known" common idioms of computing, such as concurrency, security, collection-handling, persistence, scaling, distributed programming, exception handling, etc. For example, it will come built-in with the best (alleged) security techniques known.

I see at least two potential problems with this. First, it will give it a high learning curve. Even if one only wants the basics of one of the aspects for a given project, say basic concurrency, one has to learn how the top-of-the-line security system works. It's like being forced to learn how to use a tractor when a shovel would be sufficient.

The second is that a new "best known" idiom may come along, making existing code obsolete. Perhaps it may require a complete change of the language even to effectively use the newcomer.

The high-end chase puts a lot of faith in BigDesignUpFront. -t

I disagree. I don't need to know how top-of-the-line GarbageCollection works in order to add numbers in a language possessing a garbage collector, and I won't need to know how top-of-the-line security works to learn and use standard concurrency and concurrency-control idioms. Admittedly, someone probably needs to think about security properties when developing concurrency-control patterns (lest they introduce high risk of PriorityInversion or DeadLock as a DenialOfService attack), but that burden should be on the standard library or language designer rather than on individual users. And though a particular means of expressing concurrency or collection-handling might be considered 'idioms' and become obsolete, the concurrency and collection concepts will be around for as long as we have at least 2 CPUs in this world. Sure, if a language becomes obsolete, some people might need to learn new language skills - but they'll never need to relearn everything. Such is the nature of progress.

Also, language design isn't BigDesignUpFront. If it were truly BDUF, you'd never hear of something like "algol derived" languages, you would not be able to trace lineages of language. The only reasonable way to understand language design is as an iterative process, with versioning and forks and plenty of history and experimentation to study.

But the iterative path may be much larger for a language that attempts to integrate so many concepts.

Sure. Why is that a problem?


There is only one God language.

Well. That explains a few things....

{I classify Lisp as a meta-language, not a language. However, I'm sure we can LaynesLaw this up the wazoo.}

[Like many general-purpose programming languages, Lisp can be used to define sublanguages within its own environment. It shares this capability with FORTH, C/C++ with macro pre-processing, and many others. However, these are all regarded to be languages that have meta-language capability. None would be considered to be "a meta-language, not a language". In that category (assuming by "language" you mean "programming language") are specialists like BackusNaurForm. You seem to be emphasising Lisp's MetaLanguage capability to the point of excluding everything else it does. In typical practice, its MetaLanguage capability is of relatively minor importance.]

{One gets a different answer no matter which Lisp affectionado they ask.}

[Maybe, but the rest of my point holds true. Categorising Lisp as "a meta-language, not a language" is incorrect regardless which Lisp "affectionado" anyone asks.]

{As MentalMasturbation, I wonder, has anybody tried to make an app programming language based on BackusNaurForm? Naurtran? Back++?}

People have developed languages based on Knuth's AttributeGrammars.
See Also: CompilingVersusMetaDataAid
NovemberZeroNine

EditText of this page (last edited August 31, 2010) or FindPage with title or text search