Egoless Language Design

EgolessProgramming is one thing, but what do you suppose happens when one applies that approach to library & language design?

Something novel, that's what.

One would start with TakeOverTheWorld? mentality. This sounds counterproductive. It turns out that a language not designed to do everything other than kernel programming cannot be a good enough general purpose language to be generally useful. We know C++/CLR generally failed to find wide usage; however its TakeOverTheWorldMentality? was the only thing that in the end gave enough power to be the interop glue language it is now. Corollary: the language must be cross platform. Further Corollary: the language must be able to fix endian problems in input.

But one must then remember that this language is not going to actually TakeOverTheWorld?. This means the interop gateway must be sufficiently well featured and easy to use so that it can interop with thousands of existing languages. This also means able to start your runtime from any thread, and possibly the ability to host several copies of the runtime in the same memory space.

One would have to design the language to be multi-paradigm, with at least FunctionalProgramming, ObjectOrientedProgramming, and ProceduralProgramming.

The language's standard library would have to be written mostly in the language. As a modern language needs a large runtime library, it is not reasonable to assume the library will be bug free. This means, and this is the horrifying part, the application programmer must have the means of fixing library bugs w/o modifying the library as installed on the system.

The modern world has imposed another requirement: the language must be able to provide a sandboxed execution environment for untrusted code. You may think this conflicts with the above; however I have in hand a proof it does not.

Let us see how this fits for C++:

• Language designed to be able to do everything: Yes.
• Cross-platform: Yes, source.
• Endian aware coding possible: Mostly. Library function.
• Interop. Yes. C++ and predecessor C could interop to Fortran & system libraries. At the time of writing there were no other suitable candidates to interop to.
• Start runtime from any thread: Yes.
• Multi-paradigm: No. FunctionalProgramming in C++ is a nightmare.
• Application programmer able to modify runtime libraries: Sometimes. Depends on linker behavior as to whether or not it works.
• Sanboxed environment available: No.

And for Java:

• Language designed to be able to do everything: Yes.
• Cross-platform: Yes.
• Endian aware coding possible: Yes.
• Interop. No. All interop had to be done in nasty C modules.
• Start runtime from any thread: No. Java must have main().
• Multi-paradigm: No.
• Application programmer able to modify runtime libraries: No.
• Sanboxed environment available: Yes.

And for C#:

• Language designed to be able to do everything: Yes.
• Cross-platform: Yes.
• Endian aware coding possible: Painful.
• Interop. Yes.
• Start runtime from any thread: Yes.
• Multi-paradigm: Yes.
• Application programmer able to modify runtime libraries: No. Not even by linking to private versions.
• Sanboxed environment available: Yes.

How about SmallTalk. Somoebody please correct this if wrong:

• Language designed to be able to do everything: Almost. It didn't quite like unattended services.
• Cross-platform: Yes.
• Endian aware coding possible: Difficult.
• Interop. ?
• Start runtime from any thread: No.
• Multi-paradigm: Yes.
• Application programmer able to modify runtime libraries: Yes. Image based deployment.
• Sanboxed environment available: No.

Please somebody do a chart for CommonLisp.

Unless one of the many LispVariant?s qualifies than it is likely no language in existence qualifies under these constraints.

---

Oh, come on: One needs to have a pretty big ego to go off and design your own language. ;->

Quite. Making an egoless one must require disciplined effort to do so.

---

Oh, come on: One needs to have a pretty big ego to go off and design your own language. ;->

The low-ego variation is to create a language that makes very few permanent design decisions (i.e. keep everything - including semantics, support for GC, etc. - mutable by the application architect). I can think of several such projects. But I have a bad feeling about interop and reuse, even of regular libraries, in these languages.

Funny, I don't.

---

Examples? Could we see some examples?

With a mere search query in Google, one can discover far more examples than can be expressed here:

• http://www.google.com/search?q=ten+commandments+of+egoless+programming&rlz=1I7RNTN_en&ie=UTF-8&oe=UTF-8&sourceid=ie7

Exercising EgolessLanguageDesign is not about having a big ego. Confidence, ego and ambition are driving personality forces existing in people who accomplish things. It is about designing languages that are UsefulUsableUsed. If one were not egoless in their approach, they would design a PrivateLanguage, useful for their own personal requirements.

• The term 'egoless programming' was coined more than 30 years ago to describe a philosophy that advocates putting developer egos on hold in the interest of producing higher-quality, lower-defect software. Since then, the concept has found its way into various methodologies that involve formal peer code reviews, such as ExtremeProgramming.
  • from: http://www.techrepublic.com/downloads/ten-commandments-of-egoless-programming/173234

---

JanuaryEleven CategoryLanguageImplementation