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...
- you must declare all variables.
- you must manage memory like a grown-up person.
- you must handle exceptions lest your program crash at the first violation of run-time checks.
- you must be a Software Engineer, not just a coder, to take advantage of the many, many features.
- you can say precisely, not vaguely, what you mean ("unsigned int" is vague, "range 0 .. 9" is precise.).
- you can hide (encapsulate) things.
- you cannot obfuscate your code.
- you can write "not overriding procedure P (T : in out Thing) is null;"
- you can write "type T is abstract tagged limited null record;"
- you must get the order of the keywords exactly right in the above declaration.
- all the Light & Freedom features below require you to Say What You Mean. Explicitly.
is Light & Freedom because...
- you don't have to declare your own types; make everything an Integer, Float or Boolean and you're back to C.
- you can access the hardware directly with representation clauses.
- you can access the hardware directly with machine code insertions.
- you can mess up memory all you like with address arithmetic and dangling pointers.
- corollary: you can reveal things (variables, subprograms etc.) that were previously hidden and break encapsulation.
- Built-in multitasking (not a library).
- Built-in generic programming.
- Built-in object-oriented programming.
- Operator overloading.
- Closures.
- Built-in framework for object serialization.
- Built-in interfaces to other languages (see Annex C: Interfaces to Other Languages).
- Built-in facilities for hard-real-time systems (see Annex D: Real-Time Systems).
- Built-in framework for distributed (multi-machine) programming (see Annex E: Distributed Systems).
- Built-in framework for mathematical computations with guarantees on precision (see Annex G: Numerics).
- Built-in support for certification of life-critical programs (see Annex H: High integrity Systems).
AssemblyLanguage
is Discipline / Bondage because...
- Discipline: Slip a pointer and the program crashes.
- Discipline: very verbose.
- Bondage: Only works for one particular CPU. (stuff written to take advantage of the Pentium probably won't work on a 486).
is Light & Freedom because...
- No type checking at compile time.
- There's nothing the library writers / OS writers can do that you can't do. If you can dream it (and are sufficiently skilled), you can do it.
- Macro language lets you dream up LittleLanguages.
- You can coerce any types you want. ...even if it's a very bad idea to do so sometimes.
- Any application that can be produced in any other language (speed, size, etc.) can (in theory) be done in AssemblyLanguage.
- You can repair brain-damaged core libraries sometimes.
CobolLanguage
is Discipline / Bondage because...
- It's easy to do those things that the language designers think you should do.
- No user defined types or dynamic memory management (in COBOL-85).
- "Area A" and "Area B" indentation.
- Recursion-challenged memory model.
is Light & Freedom because...
- You can program in sentences and paragraphs -- readable by pointy-haired managers.
- The magic "EXEC" command allows you to embed CICS, SQL, et al, even if most supported languages aren't much fun either.
- The "ALTER" statement that allows you to write self-modifying code.
CommonLisp
is Discipline / Bondage because...
- You need to remember all the accumulated naming inconsistencies which occur throughout the language
- It's biased towards lists.
- It is a Lisp-2 (Depending on context, you have to identify a function as such. Contrast with SingleNamespaceLisp.)
is Light & Freedom because...
- GarbageCollection.
- DynamicTyping.
- Source code and data are of the same structure, and you can define/redefine functions at run time.)
- LispMacros.
- You can create your own control structures, which are on equal terms with those which the language provides
- Multi-paradigm: You can write iterative, recursive, functional, and rule based styles.
- You can define new classes and types at run time
- If you don't like the way the object system works, you can change it via the MetaObjectProtocol
- Full spectrum of numeric types: integers, floats, rationals, complex numbers, BigNums.
- It is a Lisp-2 (Depending on context, you have to identify a function as such. Contrast with SingleNamespaceLisp.) :)
CeePlusPlus
is Discipline / Bondage because...
- Manual memory management.
- Try shared_ptr, now in TR1
- Discipline: Slip a pointer and the program crashes.
- Discipline: Strict type checking at compile time.
- But easily avoided with typecasts
- Has lots of insane syntax (the (*p)++ vs *(p++) issue)
- You can't invent your own control structures.
- It forces you to manage all those horrible include files
- It's not smart enough to disambiguate the same method in two separate superclasses
- Forces you to tell it the same stuff (class layout, function prototypes) again and again.
- Forces you to track which method calls are to be statically resolved and which are dynamically resolved, rather than handling this automatically.
- Huh? Just type virtual, that's it.
- That's his point: typing "virtual" means you have now specified that it's to be handled dynamically, not statically, and thus the choice is made manually, not automatically. (I'm unsure which favorite language of his does this automatically, but some of the ones with dynamic emphasis will optimize by choosing statically when possible.)
- Compiler difficulties on this issue eventually come down to the problem that PointerAliasing? is, in the worst case, unsolvable due to the HaltingProblem, so compilers are limited to solving it in the easier cases. This applies to Java and Smalltalk, too, but C++ pointers make this more difficult than some of the non-pointer languages.
- Icky Static/Dynamic member interface.
- Enforces const-ness and private/protected. (This might be a GoodThing, but it is still B&D.)
- Sublanguages (precompiler, templates).
- Neverending learning curve.
is Light & Freedom because...
- There's nothing the library writers / OS writers can do that you can't do. If you can dream it (and are sufficiently skilled), you can do it.
- I can say that about any language out there. If you want it to do something you need only to be skilled enough to do it.
- You can coerce any types you want. ...even if it's a very bad idea to do so sometimes.
- Pointers allow you to use "railroad switching" rather than long, painful conditional structures (nested if and case cascades).
- With templates and operator overloading you can build amazing parallel universes where C++ is clean, safe and simple.
DeeLanguage
is Discipline / Bondage because...
- Contracts
- Strict compile time type checking
- Slip a pointer and the program crashes
is Light & Freedon because...
- Garbage Collection
- You can escape the type system with a cast.
- Templates and compile-time evaluation on steroids.
DelphiLanguage
is Discipline / Bondage because...
- Very strict type checking at compile time.
- All objects have dynamic scope, lots of try finallys required
- no generic container classes, must create TObjectList descendents
- Published (visible at design time) is a scope, one looser than public, should be a directive instead, so you can have something protected at run time, but visible at design time
- Restricted to windows platform, unless you port it to Linux with KylixLanguage?
- Weird implementation of static, methods are declared "class", but fields are declared "const"
is Light & Freedom because...
- Delphi is written in Delphi, unlike say VisualBasic
- The IDE was, but the compiler is built with C/C++. FPC is however built with FPC.
- Good class library (compared to MFC), classes are consistent with each other
- Fast, often instantaneous, compilation, almost as good feedback as you get with interpreted languages
- Dynamic Arrays and open array parameters
- You can break the strict typing with variants and interfaces if you need to
- constructors are just like any other class method, can have multiple constructors, which can be VirtualConstructors?, making class factories much easier to implement than in say CeePlusPlus
- Properties rather than Get Set method pairs
- Really convenient when using CodeCompletion and the property editor in the IDE
- Meta classes, which can be virtual
- Really nice and easy to use built-in strings, unlike CeePlusPlus.
- If you do make a few mistakes, the compiler checks you. Humans do make mistakes. If you are a bit tired, at least your program will not compile, instead of crashing at run-time.
EiffelLanguage
is Discipline / Bondage because...
- Contracts.
- Strong typing, typed "templates" (i.e. classes like List[Foo])
- General tendency towards an Ada-like syntax may betray its intent (!)
- ObjectOrientedSoftwareConstruction (the "why?" book) advocates complicated language features (e.g. renaming) over simple coding conventions and patterns used in other OO languages.
-
- 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.
- It's an explicit design goal to only provide one way to do most things.
- You have to explicitly state which methods of a base class are redefined in a subclass in the 'inherits' clause as well as then redefining them in the body of the class.
is Light & Freedom because..
- You can learn the entire language in a couple of hours.
- The language is "transparent": you never have to fight the compiler to achieve some result and are never surprised that the compiler interprets your code in a different way than you expected.
- Multiple inheritance works: you never get name clash; you don't have to worry about diamond inheritance structures, you never have to use virtual inheritance near the root of the inheritance hierarchy because of the implementation of classes further down the inheritance hierarchy.
- Explicitly stating which methods of a base class are redefined by a derived class catches loads of stupid errors at compile time.
- "Anchored types" automatically redefine methods in derived classes to use more concrete type information.
- GarbageCollection
FortranLanguage
is Discipline / Bondage because...
- Bondage: No dynamic memory allocation. Often, procedures take as argument "work arrays" to overcome this problem. Yuck!
- You're thinking about Fortran77... allocatables and (almost)pointers do exist "now"!
- Discipline: Begin statement in column 7 or later and don't go beyond column 72 (in older Fortrans, anyway).
- What about free-form modern compilers allow? You're always thinking about that Fortran that was one of the older computer language!
is Light & Freedom because...
- Complex numbers are just there!
- Matrix/vectors manipulation is very easy and so they are operations over "arrays" (vectors) or slices of them
HaskellLanguage
is Discipline / Bondage because...
- Strongly, statically typed -- no way to coerce types or otherwise escape the type system
- Is biased toward lists and tuples, with generally poor support for arrays.
- Purely functional, making some obvious optimizations impossible and some algorithms difficult to implement in the most straightforward way (for example, an in-place Quicksort).
is Light & Freedom because...
- GarbageCollection
- LazyEvaluation.
- TypeInference means that you don't have to explicitly state types for all functions: the compiler infers them at compile time from their definition and usage.
- Extremely powerful generic type system, probably the best in any commonly used language.
- Purely functional, making possible some optimizations that are not safe in languages which permit side effects.
JavaLanguage
is Discipline / Bondage because...
- Strict type checking at compile time.
- Strict type checking at compile time in combination with non-generic containers. Corrected in version 1.5.
- Cannot redefine a method in derived classes to return a covariant type rguments of contravariant types! Corrected in version 1.5.
- Required to declare thrown exceptions. And to throw declared exceptions.
- Fine-grained standard library that requires you to remember the location of various functions (as opposed to the handful of standard library includes in C, for example).
- EnterpriseJavaBeans.
- Has no native support for ZeroTurnaround
is Light & Freedom because...
PascalLanguage
is Discipline / Bondage because...
- Very strict compile-time type checking.
-
- (See Also: BrianKernighan's hilarious "WhyPascalIsNotMyFavoriteProgrammingLanguage". This is very outdated and untrue nowadays, though.)
- Arrays have a fixed size. This wart alone ensures that you end up re-implementing linked lists again and again (and of course there's no generosity [presumably what is lacking is "genericity", but maybe Pascal is deficient in generosity as well...]). DelphiLanguage has dynamic arrays.
is Light & Freedom because...
Interesting that all of the Light & Freedom stuff refers to Borland's bastardization of it.
PerlLanguage
is Discipline / Bondage because...
- Insistence on use of characters $ % @ in variable names, like simple "first-generation" scripting languages but like few other true high-level languages.
- Discipline: Ever look at someone else's Perl code? BadCodeCanBeWrittenInAnyLanguage
- I/O is mostly line-oriented [What? I do very powerful binary I/O with Perl!]
- no easy way to do nested lists (yes I know about references)
is Light & Freedom because...
-
- TIMTOWTDI in the PerlLanguage sense should put it firmly under PainfulLanguage, more than BondageAndDisciplineLanguage.
- It'll do what you hope for and expect, with little effort.
- 2 mins and 5 lines of Perl == 30 mins and 50 lines of C++ or other.
- RegularExpressions on steroids
PythonLanguage
is Discipline / Bondage because...
- Everything's an object
- SyntacticallySignificantWhitespace (You cannot be sloppy or creative with indentation, you cannot rely much on automatic reformatting, and you can't embed Python inside a template language with the {%%} escapers like all other LAMP languages use!)
- Meager supply of familiar control structures and operators
- Statement oriented. if x = foo() does not work because "someone once caused a bug doing that"
- The standard libraries, and extensions, do not allow you to turn off the "SamuraiPrinciple". int('whatever') will throw an error. The programmer must always work extra to bypass these false conveniences, instead of simply chosing between statements that throw and statements that return a sentinel.
- lambdas have only one line
- the self.language permits self.expressions self.that self.are as clear and self.readable as self.English
is Light & Freedom because...
- Emulation of any operator interaction with an object via __methods__()
- List comprehensions, generator expressions and the lambda, the ultimate control structure.
- Module-oriented standard library allows wholesale namespace import, selective import or encapsulation, your choice.
- Everything's an object
- Freedom to choose between a OOP, functional or procedural approach to you program
- Easy to throw together programs.
- Mostly simple and orthogonal semantics
- Freedom from the block. (begin/end of pascal; {...} of C/C++)
- Dynamically typed
- Interactive usage, both as standalone and inside editors such as Emacs
- IntroSpection?
- Predictable GarbageCollection
- Allows to modify program behaviour at run-time (reload, exec)
- Great implementation of namespaces (so you don't have to worry about name conflicts)
- You can actually read someone else's code with its SyntacticallySignificantWhitespace.
- Dangling semicolon problems eliminated (in languages that derive their syntax from ALGOL/Simula [e.g. C, C++, Perl] a semicolon [;] terminates statements - causing hard to locate bugs if left out; in Python the statement terminator is newline - eliminating this whole class of errors).
RubyLanguage
is Discipline / Bondage because...
- you are never a stray introspective call away from turning that polished factory floor of perfectly tuned duck typing into a sea of bit-damaged mud.
- Everything's an object
is Light & Freedom because...
- Everything's an object
- Dynamically typed
- You can ignore the fact that everything's an object if you want to.
- If you don't like the way an object or class works, you can change it -- even standard ones
- It has most of KeyLanguageFeatures (and some more)
- Reflection.
- It's really easy to learn.
- RegularExpression matching is built in.
SchemeLanguage
is Discipline / Bondage because...
- No standard module system. Keep your NameSpace tidy!
- R5RS standard procedures have "unspecified" behaviour when called with invalid arguments. So depending on the situation, you might to have to check all arguments before calling a procedure, rather than just be prepared to handle an exception.
- R5RS macro system is more restrictive than Common Lisp's macro system.
is Light & Freedom because...
SmalltalkLanguage
is Discipline / Bondage because...
- Single inheritance.
- EverythingIsan object.
- Polluted global namespace means avoiding class name collisions is YOUR job. No modules/namespaces [As far as I know GnuSmalltalk has namespaces].
is Light & Freedom because...
StructuredQueryLanguage
is Discipline / Bondage because...
- Everything must conform a verbose standard, which is by convention in CAPS. SELECT docu_sec FROM docu WHERE ...
- SQL does not force you to use caps. It's just a convention. If you can suggest a better convention, please do at SqlCodingStyle.
- What is an example of it being verbose? Sometimes it is verbose, but it depends on what you are doing and what else you use it with.
- Its companion PL/SQL is just BrainDead?.
VisualBasic
is Discipline / Bondage because...
is Light & Freedom because...
- 3rd party extensions.
- Lots of skilled developers available.
- Can throw together typical business applications (screens and database) very quickly.
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...
- I have to keep careful track of whitespace because it's meaningful.
- I have to keep track of case-sensitive variable names (and there isn't a standard of capitalization as in RubyLanguage or SmalltalkLanguage).
- I can't use 'case', 'unless', '++'/'--', '?:' like I can in C++.
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:
- Poor, inflexible type system--one which makes tasks that ought be trivial difficult or impossible (ie PascalLanguage), or one which requires a rats-nest of typecasts everywhere to get anything useful done (ie JavaLanguage, pre JavaFive?).
<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:
- An incompletely specified program, i.e. where you left a function only half-written, should still parse, compile, and execute unless that function is critical to the execution. This suggests:
- The syntax or code-layout must be designed such that syntactic errors are localized (do not corrupt the rest of the program).
- If the language is compiled, then the compiler will either intelligently handle an incomplete function - e.g. issue a warning then transform it into a routine that simply throws an exception - or at least will notice that a particular function is unused and so drop it rather than complain about it.
- Errors are noticed right away rather than lingering for a long time. This lets others play in your code and protects you from spooky action at a distance (a change here broke some code way over there) such that you can lay your superstitions and fears aside and have fun.
- Static language analysis techniques are useful here, including typing.
- A language-design for ZeroButtonTesting can also help here; it would be very nice if the IDE keeps you continuously informed about which edits broke which tests.
- Beyond UnitTests, avoiding spooky action-at-a-distance concerns requires integration testing also be auotmated.
- A malign program, written intentionally or otherwise, can be localized and controlled. This allows you to run other people's malign programs, and to mess up in a big way without getting feds on your trail or something similar.
- Information isn't lost. If you mess up, you can roll back the changes. Undo and Versioning utilities don't need to be part of the language syntax, but really should be part of the IDE. So should be automatic, distributed backups such that you have no fears that your code is going to break.
- Interactive. For example, a ReadEvalPrintLoop or LiveProgramming can go a long way towards the "play" aspect. OpenCroquet and SqueakSmalltalk are fine examples of LiveProgramming environments for general-purpose, but many more exist (especially for music, image, and video composition). (This aspect, more than others, tends to suggest 'dynamic', but there are other strategies to achieve this feature if the IDE cooperates and just 'parts' of programs can be discarded, rebuilt, and re-inserted.)
- No boiler-plate code. The need to write boiler-plate is the very essence of BondageAndDiscipline. Boiler-plate code tends to exist when the language is working with: FrameWorks, PolicyInjection, DependencyInjection, ErrorHandling, etc. Keeping a language light and free requires either abstracting these TuringTarpit problems as primitive language features (e.g. throwing/catching/resuming exceptions), or supporting macros and syntactic extensions and necessary generic semantics (e.g. CallWithCurrentContinuation) such that smart programmers can hide these repeated boiler-plate patterns behind a library-exported syntax.
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
Bondage And Discipline Language