Things The Compiler Should Force Upon Us

Some think EncapsulationIsaWasteOfTime. Others might tweak that to say CompilerEnforcementOfEncapsulationIsaWasteOfTime?.

This is an interesting topic for me at the moment as I'm reading about a couple of different ObjectOriented languages right now and topping that off with a heavy dose of the book ObjectOrientedSoftwareConstruction. I believe that the language/compiler is a tool to make programming a machine more productive, and certain language features, compiler features, and even IDE features should be enforced in the name of teamwork and standards.

Here's my canonical example which you may or may not disagree with: In the VisualBasicIde?, certain spacings and formattings are enforced automatically as you move from line to line (e.g. "x=3" becomes "x = 3" AutoMagically; if you declare a variable as "Dim MyVar?", then whenever you type "myvar", it AutoMagically becomes "MyVar?"). Another IDE I use enforces the indentation of the code. In my opinion, these are good enforcements and I would like to see more of them in the future. However, from what I've heard of Python, whitespace is part of the language and missing a few spaces can change the meaning of your code. That, in my opinion, is a bad enforcement, though I haven't actually used Python yet, so it might be a non-issue in practice.

What about encapsulation? I think that like RubyLanguage, attributes should be encapsulated by default, and an easy language extension supplied to give a default get/set method so you don't have to manually type it out. However, I'm of the opinion that the compiler (or interpreter) enforcement of encapsulation is important because it can catch inappropriate tweaking.

Things I'm for:

Code formatting (without affecting the program semantics)
Encapsulation of attributes (with easy default get/set)
Catching undeclared variables/functions (such as 'x=5' without first declaring x)
Uniform client-access to features (e.g. always obj.feature(), regardless of whether accessing a method or an attribute; easily accomplished if all attributes are encapsulated)
Everything's an object rather than different ways to handle objects and primitives (with language features or extensions to allow things like operators and literals)

Against:

Static typing (but what about SoftTyping)
Pointer operations except possibly for native code

PleaseComment

See the book CodeComplete', and its section on the "Cobbler" development environment, for more of these sorts of ideas.

Have you ever tried to use Microsoft Word and have a constant battle in trying to get it to accept what you type and leave it alone? I don't have a lot of confidence in some great mastermind declaring the perfect way to format code and deciding the world should be forced to enter it that way.

I think this is an imperfect analogy. This page is about a compiler that enforces generally-accepted good programming practices, according to specific goals such as readability, without changing the semantic content. Word is trying to enforce arbitrary standards of spelling, punctuation, capitalization, etc., and these do change the semantic content. -- BrentNewhall

Reread the second sentence. Who is defining these "generally-accepted good programming practices?" I, for example, would strongly disagree with having Get/Set methods in a class. Should the editor force those on me or prevent you from adding them?

If you get it your way you got one of the BadEngineeringPropertiesOfOoLanguages. StaticTyping is a good thing, until proven contrary, and all kinds of assertions do not a proof make.

The only assertion that matters is: I am more productive without static typing.

Then it's your fault, and you should learn how to be productive with static typing.

Yeah, sure... and that does not a proof make either. Sheesh.

It looks like SmalltalkLanguage is exactly what you want (except maybe for the "Code formatting", whatever that means).

Indeed, one of the languages I'm learning about is SmalltalkLanguage. Haven't really put it to good use yet, but it has already (along with RubyLanguage) influenced my aesthetics of programming languages.

I like EiffelLanguage. It is:

clean
FULLY object oriented
and statically compiled

It also supports DesignByContract (which is excellent) and a limited form of generics, which is good enough in most cases, as long as you don't try to go functional. If you are a fan of programming languages, check it out. SmallEiffel / CppSucks? -- AluoNowu

I've also made a hobby out of trying to decide for myself what ThingsTheCompilerShouldForceUponUs, among other philosophical questions. Based on your list above, I think we share some of the same ideals, but I'm on the fence about StaticTypeSafety. Coding and refactoring do indeed go much faster in dynamically typed languages, but I'm willing to give up some implementation speed in order to turn my runtime bugs into compile-time errors. Preventing bugs is, after all, one of the principle reasons why we want the compiler to force things upon us, is it not? The question is, which costs more: maintaining type information in our statically typed source code, or hunting down the bugs that are unique to dynamically typed languages?

Since I haven't found an answer to the above question, I'm especially intrigued by languages that find some middle ground between static and dynamic typing. CecilLanguage, for example, has optional static typing. If you choose to include type names in your source code, the compiler will use them to give you static type safety and performance improvements. If you're in a pure rapid development mode, you can leave the types off and the program will work fine. Another interesting trick is TypeInference, where the compiler extrapolates from limited type information to determine the types of variables and functions by analyzing their usage.

-- CurtisDuhn

In the VisualBasicIde?, certain spacings and formattings are enforced automatically

Your examples show that you want TechnologicalSolutions? to SocialProblems?. I have bad news for you: they don't work. If you have a programming convention, and a programmer doesn't follow it, try ParkingLotTherapy. But don't force your choices down into the compiler/IDE/whatever-tool where it hampers all other users of the language.

Remember: if you make something idiot-proof, only an idiot will want to use it.

I disagree, but I think this might be more of a misunderstanding than an actual disagreement. The kinds of things that I like to be enforced are tabbing, spacing, and simple formatting issues that do not affect the semantics of the code or the programming style of the individual.

For example, why should I have to manually hit tab to indent my code? Even text editors that auto-tab still can get out of synch if you do certain things (such as hitting Enter at the beginning of the line). Why even bother with this little detail? One of the tools I use automatically indents all code whenever it is recompiled. That might seem like a small thing, but I really noticed it. It removed one type of nuisance. Sure, it enforces only one indent depth (two spaces per level), but consider that everybody who uses this tool everywhere has the same indent style.

The important thing is that the tool doesn't force you to work in a particular way. Instead, it allows you to work how you like, take shortcuts and whatever, and then it fixes it up for you after. This is not a social problem, it's an AdminisTrivia? problem. The solution doesn't hamper anyone. Do you complain that WikiWiki ignores multiple line-breaks? No, because it makes pages easier to format for everybody.

[Years later...]

I've since started using IntellijIdea and it answers almost perfectly my wish-list for code formatting, not to mention nearly eliminating the burden of encapsulation in Java, among several other things. It's quite refreshing! Maybe we should rephrase it as ThingsTheIdeShouldEnableForUs?.

Programmers spend 90% of their time with a computer editing code (the machine may spend more than 10% of the time doing something else, but the programmer is having coffee somewhere, and isn't involved by then). The experience of editing code isn't usually perceived until something goes wrong. Happy programmers have arranged their editor so that nothing goes wrong with editing (at least, not often).

Enforcement of indentation style in the IDE causes major headaches. Just imagine what happens when two IDEs that manipulate code in the same language but have different, usually hardcoded, indentation schema are used to edit code in the same project. Imagine if these two IDEs are set up for different versions of the same language, so that the older cannot parse the newer's code, and imagine if the IDE does automagic formatting by parsing the code and then generating text from the parse tree. In severe cases, if one file is edited by both IDEs, it will be irretrievably and silently corrupted.

IDEs encourage every language to have its own editor, or assume that someone will extend a single editor to be able to understand every language you'll ever use (including all the domain-specific programming languages that you use as part of your projects, and code in other languages that might be contained inside your language, e.g. HTML strings or SQL queries embedded in C code).

In the worst (and also typical) case, the poor programmer has to learn a new editor for every new language, or must extend their editor to understand every new language. If you only have one language and one platform and the editor doesn't get in your way, you're all set.

If you're used to the pathetic capabilities of typical Windows or Mac editors (specifically: insert text, delete text, cut, paste, find strings, maybe replace strings, new, open, save, close, exit), then learning a new editor every week isn't a big deal; however, if you're used to emacs or vi, you expect your editor to actually help you write code (e.g. by reducing the amount of typing, verifying syntax or style on the fly, or just staying out of your way), and you've probably spent years training it with custom extensions, or you have a huge collection of extensions written by other people. You would probably have one right now that implements your current employer/client's formatting style.

If you've invested a lot of time in an editor, you'd sooner change jobs than change editors, because changing jobs just requires editing a couple of strings in a macro somewhere, while changing editors requires translating all of your editor extensions into a form some other editor can cope with... if it's possible to preserve the extensions at all.

Now there's nothing wrong with any of this overhead if you want to do it. Just don't go forcing it upon everyone else who has to work on the project with you.

Does the same go for CodingStandards? -- DevilsAdvocate