Bondage And Discipline Language

A language is B&D to the extent that its defenders exhibit AuthoritarianPersonality symptoms.


Note that this page has been the battleground for more than one WikiWarrior.

Authors of BondageAndDisciplineLanguages believe their concepts of the Higher Principles of Computer Science should apply to how you say "Hello World".

extreme, uncontestworthy examples: Hypercard, Lotus Notes, http://www2.latech.edu/~acm/helloworld/Intercal.html C-INTERCAL (home of ComeFrom), ADA, or a functional language containing only lambdas expressed by either an apostrophe or the letter L.

Clarification: BondageAndDiscipline is externally imposed, even if you're the one that begged for it to happen. Some of the discussion below still assumes "discipline" means "self-discipline", which confuses things.

 Bondage == "I'm not allowed to..." (restraint of behavior)
 Discipline = "I am forced to..." (forced behavior)
 Self-Discipline == "I better be careful to..." (abandon all hope, ye who enter here)
I'm sure many WikiZens will be able to think of languages that tie you up and beat you much worse than the ones listed below.

What about a WikiWeightedVote? 9 = completely BnD, 0 = not BnD at all. Of course, you don't need to vote if you don't know the language in question.

Ballot box emptiers, please note: If you empty the ballot box, you must record both the average and the number of votes -- otherwise you will not be able to recompute a valid average when new votes come in.

I'm still wondering if it is OK to vote with negative numbers. Supposedly, the votes should be of type 'unsigned int'.

What do you mean 'unsigned int'? Didn't you say the range was 0 to 9? The proper declaration is 'type Disciplined is range 0 .. 9.'

Then again, perhaps your favourite language doesn't have such constraining types...

I don't think it is. It defeats the purpose of a scale, and just leaves strange comparisons like the Perl vs. Scheme silliness above. So I changed them to 0's

From the ballots, BondageAndDisciplineLanguage seems to be strongly connected to the use of natural language keywords. Is this just a coincidence or is there more to it?

I think the Forth numbers are not so ridiculous. If you know forth then you should agree that it is 1 or 0


For comments supporting the above rankings, by language:

A lot of these don't seem like traits of bondage or discipline. For instance, how is it that having all arrays indexed from 1 is any more restrictive than having them all indexed from 0? How is it that not having a built-in threading library is any more constraining than not having a built-in quaternion library? Come on, people, not all negative traits qualify.

AdaLanguage

is Bondage and Discipline because... is Light & Freedom because... AssemblyLanguage

is Discipline / Bondage because... is Light & Freedom because... CobolLanguage

is Discipline / Bondage because... is Light & Freedom because... CommonLisp

is Discipline / Bondage because... is Light & Freedom because... CeePlusPlus

is Discipline / Bondage because...

is Light & Freedom because... DeeLanguage

is Discipline / Bondage because... is Light & Freedon because... DelphiLanguage

is Discipline / Bondage because... is Light & Freedom because... EiffelLanguage

is Discipline / Bondage because...
Ironically, of course, Eiffel proponents argue the opposite: that renaming members is simpler than the complicated aliasing and delegation other languages need, especially when it comes to solving accidental name clashes.
is Light & Freedom because.. FortranLanguage

is Discipline / Bondage because... is Light & Freedom because... HaskellLanguage

is Discipline / Bondage because... is Light & Freedom because... JavaLanguage

is Discipline / Bondage because... is Light & Freedom because... PascalLanguage

is Discipline / Bondage because... is Light & Freedom because... Interesting that all of the Light & Freedom stuff refers to Borland's bastardization of it.

PerlLanguage

is Discipline / Bondage because... is Light & Freedom because...
TIMTOWTDI in the PerlLanguage sense should put it firmly under PainfulLanguage, more than BondageAndDisciplineLanguage.
PythonLanguage

is Discipline / Bondage because... is Light & Freedom because... RubyLanguage

is Discipline / Bondage because... is Light & Freedom because... SchemeLanguage

is Discipline / Bondage because... is Light & Freedom because... SmalltalkLanguage

is Discipline / Bondage because... is Light & Freedom because... StructuredQueryLanguage is Discipline / Bondage because... VisualBasic

is Discipline / Bondage because... is Light & Freedom because...
Discussion

I love the title this page,, because so many languages feel like that. But I'm going to make an outrageous claim that I'm not sure I can defend, just to see where it leads. Tell me what you think of this: All languages tie you up and beat you. However, if an environment suits your particular kink, then it feels good to you. You may not even notice that there's anything kinky going on. It's only someone else's kinky languages that makes you say "do what?" -- WayneConrad ('Python suits my particular kink perfectly well -- WayneWerner')

Sure. There's nothing you can think of, however bizzare (or boring) it may seem to you, that isn't someone somewhere's idea of a thrill. Or maybe not: honestly, who has ever enjoyed COBOL?

I've enjoyed COBOL. It's really a pretty cool language; I think people object to it primarily because it's not a *fun* language, like C or LISP. COBOL is designed to help you do work - not the cool kind, like writing a fantastic new utility or application that will undoubtedly make you filthy rich, but the mind-numbingly boring kind where you have to add up lots of numbers and print a report. If you're looking for a hobby, that's one thing, but some of us have had jobs where we added up lots of numbers and printed reports all day long... which is precisely when COBOL is awfully nice to have.

Building robots to do the mind-numbingly boring kind of work is the fun kind of work, at least for a while. Once building robots becomes boring, build robots that build robots.


In sufficiently reflective and dynamic languages, you can implement another language inside of the first language that can interact with the first language's objects. Like Java and JScheme or JPython. Then, you've effectively escaped the bondage like Houdini with a keyboard. -- SunirShah

You can use any TuringComplete ProgrammingLanguage to emulate any other and thus escape its bonds. I'll even go out on a limb and say that in practice you can allow the emulated language to talk to some of the underlying language's objects. So I don't think this is very interesting. WayneConrad is right; bondage is a point of view.

Smalltalk is a bondage language because it tries to make everything an object. -- DaveHarris

To me Smalltalk is not bondage, since even if you can think of everything as an object, the language makes this rather natural, and if you prefer, Transcript show: 'Bye' is not an message sent to a class, it is rather Smalltalk syntax to say transcript_show('Bye') ... Indeed this can work for (almost?) every ObjectOrientedLanguages -- MauroPanigada

There's a difference between emulating another language and using that explicitly and using a separate language to manipulate the host language's objects. I would find it amazing to see a lambda inside ISO C++ that would close over even the primitive types seamlessly.

This would actually be quite easy to implement. The most difficult part is the unlimited extend of the lexical enclosing stack frames, for which you need GC. But since there are actually garbage collectors for C++, and since the ISO C++ standard is written in such a way that it is legal to have GC, this can be overcome.

If you read the comments re: GarbageCollection closely, they are related only to the heap and only to manage the heap data structure, not object management. This is because of the semantics of delete. Also, you can't close around variables declared on the stack or as globals without going outside ISO C++. Remember, you have to close around the primitive declarations too, not just some fancy SmartPointers.

Remember, there are different levels of emulation on a TuringMachine. In the extreme, the emulated machine is completely independent of the host. There are less extreme emulations that are integrated with the host machine. The latter here are more interesting for practical use. -- SunirShah


C++ Comments

It is surprising that C++ is being rated so highly. C++ is often criticized for not being truly object oriented. BjarneStroustrup is proud that it supports multiple paradigms. It seems that C++ does not insist on a certain way of programming, and should thus be rated lower for BnD.

It insists on every different supported way of programming with different nuisances.

C++ is a very powerful language, but there are styles of programming that it doesn't support at all well. It has no LexicalClosures, no GarbageCollection, no RealMacros (though templates go some of the way), no MultipleDispatch. Almost anything can be done in C++, but often only if you don't mind it being horribly verbose and rather inefficient.

I'd say C++ is very high Discipline -- you need it or your programs crash. But, in a sense, it's low Bondage -- you can do >anything you want< (if only you know how -- JeffGrigg)


A really long C++ comment

Richard B. Johnson concluded a discussion on the Linux Kernel mailing list, about whether or not to allow C++ in the Linux Kernel, with this message. Quoted from Kernel Traffic #66 (http://kt.linuxcare.com/kernel-traffic/kt20000507_66.epl):

It's interesting to observe the advocates of a specific computer language. Most often a discussion about a particular compiler of similar tool results from the failure of persons to understand the basic nature of any computer language.

Computers don't communicate very well, even with other computers. When humans try to communicate with them, they have to use certain tools. These tools may range from devices such as keyboards to software tools such as compilers and editors.

Since computers don't understand the human languages very well, although there is continual work in this area, humans have to learn computers' languages. Since the computers' internal languages do not interface well with human languages, we have created tools to translate. There are called assemblers, compilers, and interpreters.

Every one of these tools, and probably those to be created in the future, pose major communications and control limitations. It becomes necessary, for programmers using these tools, to provide work-arounds for the limitations of these tools.

An expert in a particular computer language is really an expert in the work-arounds necessary to use this language to perform useful work. An ideal computer language would do exactly what it was told simply from reading a specification. In the absence of a specification, it would ask enough questions to produce such a specification, then it would generate the code necessary to perform the specified functions.

So a programmer becomes a captive of the tools used to communicate with the computer. With experience, the programmer starts to identify with its captors and starts to believe that the language mastered, is in fact, the only true language. Once captured, the programmer becomes an advocate. Psychology teaches the name of this effect as the "Stockholm Syndrome". It was first recognized during the detention of World-Games competitors in Stockholm, Sweden. This effectively creates the CodeKing pattern.

You see this problem mostly with programmers who have mastered only one language. If you have been around computers since 4-bit nibbles on paper-tape, you have long ago abandoned the notion that there is only one true language. But the first language you truly mastered still seems to have been the best. The StockholmSyndrome? affects us all to some extent.

I advise to not get trapped into the notion of the "correct" tool for a particular use. Just because you have become expert in C++, don't presume that it is the "correct" language for the kernel.

Even C has its shortcomings which have to be handled with assembly language extensions. A Master Carpenter has many tools and is expert with most of them. If you only know how to use a hammer, every problem begins to look like a nail. Stay away from that trap. It bytes (sic).

Of course, this long and mildly condescending ramble doesn't say a single word about the possible advantages or disadvantages that C++ might have for kernel programming. The bias of the author is apparent in the last paragraph: "even C has its shortcomings". Better than your average newsgroup flame, but only in appearance.

I don't think that bias is intended. When the author says "even C...", he is referring to the fact that the Linux kernel (which is the kernel being discussed) is written in C, but that even C (as the chosen language of the Linux kernel) has its issues. Were the Linux kernel coded in Eiffel, then that language would have been used in the statement, rather than C.


I find it deliciously amusing that Eiffel has the highest average above, because I remember reading a section in EiffelTheLanguage? by Bertrand Meyer wherein he expresses shock that anyone could possibly apply the "B&D" label to Eiffel, when its philosophy is exactly the opposite. Boy, is it ever funny. -- GlennVanderburg

(By the way, don't ever type "Eiffel bondage domination" into Google ...)

Maybe the idea of Eiffel is enabling the programmer to impose his own taste of bondage and dominance on the code (and indirectly on himself)

Bertie probably wrote it after ... someone ... called Eiffel a B&D language on news:comp.object . I wonder who could have done such a thing! -- PhlIp

"Eiffel programmers can have fun, too, thank you. Of course, someone whose idea of fun is to spend his or her nights debugging will have less of it. But then such a person wouldn't need a chastity belt anyway." -- BertrandMeyer

from http://groups.google.com/groups?q=%22Eiffel+programmers+can+have+fun,+too,+%22&hl=en&lr=&ie=UTF-8&oe=UTF-8&simplewebscoff=1&safe=off&selm=166%40eiffel.UUCP&rnum=1


Authors of BnD languages believe their concepts of the Higher Principles of Computer Science should apply to how you say "Hello World".

It's not quite that, surely? Look at the high ranking languages: Pascal, Eiffel, certainly; COBOL...computer science!? Then again, Scheme is explicitly about one particular Principle of Computer Science and scores a resounding '0' (on 16 Aug '00). Smalltalk, too (currently riding low at 1+2/3) is all about a particular view of programming, but is seen as a flower-child amongst languages.

What is it the BnD guys are looking for in a language? What are the programming equivalents of spike heels and riding crops?

PascalLanguage. You can't just jump to a label, you have to "declare" it first. This is not because the parser can't just find the labels, it's because "goto is bad". >ptch!<

Is it though? Pascal has a goto, Wirth can't have thought it was so evil. A lot of Pascal's oddities come from the original performance/space constraints on the compiler: it had to parse a source file in one pass. Hence Pascal programs tend to look upside down and inside out.

A lot of this is taste. For me, it comes down to this: when programming in a language, how constrained do I feel?

Actually, it is because the parser can't just find the labels. NiklausWirth's Pascal was designed so that it can be compiled in one pass, with one-symbol lookahead, with immediate notification of compile errors. This makes it an ideal language for a recursive descent compiler, and in fact one of Wirth's books (Data Structures + Algorithms = Program, I think...) features a recursive descent compiler for a tiny Pascal. Unfortunately, if you want gotos with one pass, one-symbol lookahead and immediate error messages, you have to declare your goto labels.

By the way, the compiler in Wirth's book used goto.

It's not really the parser, it's the one pass code generator. Given nested procedures, a goto statement that jumps from one nesting level to another has to unwind the stack to the target level before doing the jump. Without label declarations, you couldn't generate the stack-unwinding code in one pass.

LarryWall said "there's more than one way to do it". BertrandMeyer was probably thinking "It's my way or the highway." ... clearly explaining modern highway congestion.


Bondage == "I can't..." Discipline == "I have to..."

A translation of PythonLanguage's entry, for example, is:

PythonLanguage

is Discipline / Bondage because... Therefore, shall we agree that a language is a Bondage and Discipline Language if you find yourself saying "can't" or "have to" more often than in another language?

No, it's more like a language is a B&D language if the requirements of the language lead to a loss (rather than gain) of productivity. I doubt you'll find anyone proficient in Python that believes this to be the case with Python. -- AndyPierce Hey, just because some people *like* B&D, doesn't mean it isn't B&D.

Well, I picked PythonLanguage because its B&D list was so short. If I'd picked C++, I'd still be copying the list. Under that logic, why didn't you pick CommonLisp?


The MythicalManMonth's first chapter has a nice chart with four quadrants -- the ordinary program, the program product, the program system, and the program system product. FredBrooks wrote that a program product (which is like a program but includes enough documentation that anybody can use and extend it) is three times harder to produce than an ordinary program, a program system (which, IIRC, is designed to run under tight constraints and fit in with other programs in a system) is three times harder to produce than an ordinary program, and a program system product (which has both characteristics) is nine times harder to produce than an ordinary program.

Now, I think that modern BondageAndDisciplineLanguages are those that try to force you to write only program system products. I think this has become the trend in language design. What are objects if not little program system products? These languages try to force you to add all those additional characteristics, making it take much longer to write the program, but then making it fit into a system and making it possible for people to understand and modify it (think inheritance) without having to reverse-engineer the thing. At least in theory -- it's possible to flub all that extra stuff and write an ordinary program with extra garbage to shut up the compiler, but you still have to go to the extra effort of flubbing it.

Language designers are lured into doing this because program system products are much better than ordinary hacked-together programs. But the languages they design become almost incapable of producing the old-style ordinary program. It is surprising how often an ordinary program will do -- and yet we, the people annoyed by BondageAndDisciplineLanguages, find that we cannot write ordinary programs any more; it's as if it is not allowed...

-- EdwardKiser


Freedom in a language demands more discipline from programmers. Discipline is inversely proportional to bondage.

You're confusing discipline with self-discipline. The more something disciplines you, the less self-discipline you need -- but the more bondage you are under.

Unfortunately, no. Freedom does demand self-discipline, but too many languages require high self-discipline while giving back very little freedom.


Constraints on the writer are guarantees for the readers. Freedoms for the writer are uncertainties for the readers.

Are you sure? Try comparing Ocaml code to C++ code.


Anti-Pavlov Force Stronger than Pavlov Force

I have a theory based on MostHolyWarsTiedToPsychology. The larger the organization, the more that preventing problems is rewarded over finding solutions. One is "called to the floor" more often for things that go wrong than for things that go right. A BondageAndDisciplineLanguage caters to such corporate philosophy, for good or bad. For example, the kudos for being way ahead of schedule are less than the anti-kudoes for being way behind schedule.


None of these languages are very Safe, Sane or Consensual. Where are the damn Safe Words?


This page appears to have been victimized to the point of lacking useful information.

The vote counts above are obviously bogus.

Roughly half of the listed languages are diametric opposites of B&D.

I think this page could use a good scrubbing.

As a start, the following languages are simply not B&D:

There may be more, those are simply the languages I'm familiar with.

Nonsense. Python requires extremely disciplined tab indentation.

Most editors can auto-indent, just like most editors can balance parentheses.

But Python is different from C-based syntax because it actually uses the indentation you give it to determine nesting. It cannot be calculated by analyzing something equivalent to curly braces. An editor cannot read minds.

An editor follows your instructions and facilitates code composition. Without certain editor features certain languages become more difficult to compose. I wouldn't want to write SQL without a swap case command, for example. I wouldn't want to write Lisp without parenthesis matching.

Writing python in an editor that cannot massively indent or unindent selected blocks of text, or that won't display whitespace, is very difficult. This should not be confused with the difficulty of writing python itself. It would make as much sense to decry case sensitivity.

I simply hate Python for that; if you lose white spaces (e.g. when posting in places that "tend" to eat spaces), your program won't work; it would be nice if Python's author would add a more "visible" way of identifying blocks of code. -- MauroPanigada


Agreed. People seem to confuse "bondage and discipline" with "bad" in a generic sense (not saying the above are good or bad)--any language that is disliked by anyone is proposed as a BDL. A true B&DL is, in my mind, one where the language forces you to jump through numerous hoops to get everything done. Of course, everything is relative (proponents of languages with dynamic typing or type inference may claim that any language which requires type annotations is a B&DL), others may disagree.

Some features that a B&D language might have are:

<others>?


Well, first you write "People seem to confuse bondage and discipline with bad in a generic sense" and then "Some features that a B&D language might have are: Poor, inflexible type system ...". To me it looks like the same confusion or inability to explain without a valuation.

Well, as long as the meaning of B&D is not really explained on this page the whole discussion about the languages is meaningless. It's like color blinds trying to separate the world into red and green objects.

As long as you can read about a single language: "it's light and freedom because it has pointers" and "it's bound and discipline because your program will crash if you use pointer the wrong way", this page missed the whole point.


I think of B&D languages as systems that impede productivity through constraints that made sense in 1960, but are less useful in a world of fast systems, large storage and memory, HPC clusters, and an ever spiraling complexity (due to disparate and changing information repositories, convergent networks, and demanding users). B&D languages don't lend themselves to a changing environment - and tend to lead to long overbudget projects when attempting to address modern problems. In this regard B&D languages are synonymous with CardWalloperLanguages. -- MalcolmCampbell


If you are stuck with unmotivated, sloppy, and unskilled developers; then B&D languages prevent fools from doing too much damage. However, they also impede productivity of those who want to move forward and have a good-but-lean system. Larger businesses are risk-aversive and would rather be safe and slow than lean and fast but risky, such as depending on a select few coders. There are ways to use productive languages in such environments, but the skills and processes to manage such projects properly are harder to come by and harder to keep.

[Safety can be achieved, and principles enforced, without resorting to BondageAndDiscipline. Features such as GarbageCollection, SoftwareTransactionalMemory, PersistentLanguage & language-provided serialization, TypeInference, structural typing (NominativeAndStructuralTyping) or static duck-typing, effect-typing (i.e. separating pure functions from IO procedures), ResumableException, ObjectCapabilityModel, ExplicitManagementOfImplicitContext, JustInTimeCompilation, modular solutions to the ExpressionProblem (like horizontal subclassing or open functions & datatypes), etc. don't much interfere with productivity (and often can aide it) while simultaneously increasing safety, performance, and security.]

[Not everything in LanguageDesign needs be a tradeoff unless we're already working with "ideal" systems (global maxima and minima for certain features) - which we, quite frankly, aren't anywhere close to doing.]

Well, I'm skeptical. Most systems end up with at least some organic-ness (LimpVersusDie) because otherwise all the potential contradictions in long-lost or poorly-documented business rules would end up making compile-time take forever as one plays whack-a-mole with all the reported exceptions. Your tool stack makes for a TechniqueWithManyPrerequisites such that a very-unlikely mass cultural overhaul is needed. Plus, it is poorly documented for those not familiar with your background material, and thus many will simply roll their eyes.

And, we keep having this debate. Let's factor it out somehow to a named topic. Otherwise, it looks as if you are just trying to troll-sell your favorite tool-set by re-listing them over and over. (Some accuse me of that also, I would note. I am not outright accusing you of consciously doing that, only saying it may appear that way.) -t

[How is "some organic-ness" a contradiction to anything I said? Many features I mentioned - JustInTimeCompilation, structural typing, TypeInference, GarbageCollection, ObjectCapabilityModel, EMIC, modular approaches to the ExpressionProblem - support a great deal of "organic-ness". HaskellLanguage and ObjectiveCaml and MlLanguage and MercuryLanguage - statically typed languages all - provide ReadEvalPrintLoops, powerful modularity constructs, etc. New languages push the envelope further; ScalaLanguage is a fine example that is seeing widespread use. PersistentLanguage is already seeing considerable use today, via frameworks that embed themselves into CLR or JVM. Indeed, all the features I name above are in use today if you include frameworks.]

[You're an idealist, TopMind. Your "ideal" - your simplified world-view - is that everything involves tradeoffs, everything is relative. In your ideal world, you have no need for logic, thought, and analysis as to whether a particular case involves tradeoffs or is relative. You above imply that 'organic-ness' must be a 'tradeoff' as justification for skepticism, but your claim assumes - without the slightest bit of analysis or consideration of the features I clearly listed - that the system I described mustn't possess organic features. I find that insulting and disrespectful since it means to me that you did not bother thinking about what I wrote before you attacked.]

I'm not dismissing logic, thought, and analysis; only saying they approach an asymptote such that managing trade-offs becomes a more productive use of time (investment) than trying to find the magic abstraction, tool, or formula. It can be really difficult to know up-front whether "heavy engineering" will result in a better result or an idealistic mess. (Related: IdealisticMessVersusLazyMess). -t


What is the opposite? LoneCowboyLanguage??

The opposite of BondageAndDiscipline is not SelfDiscipline, LoneCowboyLanguage?, TimTowTdi, or DynamicTyping. The opposite of BondageAndDiscipline is FreedomAndLight? (freedom minus eternal vigilance) - the ability to make changes, to try new things, to play, to perform ExploratoryProgramming with the knowledge that you're not going to accidentally shoot yourself in the foot or hang yourself later, and even freedom to let others join you without fearing they're going to break things in ways you won't notice.

The ExtremeProgramming methodology uses UnitTests to achieve some of this freedom. But it may also be achieved by language analysis techniques such as typing, or by carefully designed syntax that doesn't allow certain errors to be expressed (and allows the IDE to help user catch them with syntax highlighting), or by secure language designs like object-capability that allow sandboxes to be easy to build and impervious to breach, etc. TypeInference and flexible subtyping rules go a long way - i.e. favor lattice-subtypes rather than hierarchical-subtypes.

Features associated with freedom:

While it is undeniable that purely functional languages impose some B&D, the given example for Haskell is ridiculous: an in-place Quicksort. Functional language == no variable reassignment == no in-place anything.


See Also: BondageAndDisciplineVersionControl, SafetyGoldPlating, StaffingEconomicsVersusTheoreticalElegance

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