Saying “garbage collection means you don’t have to think about memory management” is kinda like saying “Java/Perl/Python/Ruby doesn’t have pointers”.

Well put. Thank you. I will moderate my language on this topic in the future.

Depending on environment, #4 is also an issue (eg. in Perl 5, which uses refcounting, not a real garbage collector), but it’s distinct from the other two in that it’s a leaky abstraction rather than a fundamental issue. Both #2 and #3 are fundamental issues.

It’s not hard to imagine causes for #3: just scope your variables a little too loosely, and you’ll have to pay explicit attention to the values you keep around. Sometimes scopes cannot be tight, either; object pools and various forms of caches come to mind.

Garbage collection makes life easier by removing the need for one (and only one) of the “stakeholders” of an allocated object to be responsible for freeing it. But each of the stakeholders still needs to declare their non-interest in the allocated object in order for it to be picked up properly. Usually that is very implicit: if you scope variables tightly enough then the right thing will almost always happen by itself. But only almost.

Most of the time, as you said, the resulting memory leaks are only transient, not persistent. But even the transient ones can still trip up your code if they are bad enough; and persistent ones remain possible, though much rarer.

Saying “garbage collection means you don’t have to think about memory management” is kinda like saying “Java/Perl/Python/Ruby doesn’t have pointers”.

This smells very much like we are agreeing except that we are using a few ill-defined terms slightly differently. Let me make some statements and you can tell me if we really disagree.

1) Some resources have a lifetime.

Files are an obvious example of such a resource. You need to close your files to release the locks so other parts of your application can access them. This is true even with garbage collection.

Semaphores are another such resource.

A colleague told me about an early Swing bug where animated images were being stored in an object’s internal collection. They were not being tidied up when a window disappeared, and continued to consume CPU (and memory). So animations are another example of a resource with a lifetime.

You need to manage these resources, even with garbage collection. I don’t see this as a memory issue. (While I care that a file is closed, I don’t care if the I/O buffer associated with that file is deallocated or not.) I see this as a resource-management problem for the type of resources that have an explicit lifetime with associated semantics.

(I see a distinction here: The programmer must take care of resource management, but not memory management. However, I am rather tired and fear I may be making it too black and white, when the line is rather arbitrary. Is see the difference is that a resource intrinsically has a lifetime that the programmer wants to care about - i.e. this semaphore should be released now, rather than at the run-time’s earliest convenience. Heap memory (like stack memory and CPU cycles before it) has now been moved into the “don’t you worry your pretty little head about it” pile for the compiler/run-time environment/OS to take care of.)

2) You can still consume memory very inefficiently and cause your program to run slowly or to fail - even with garbage collection.

3) I have, on the cusp of my understanding, an idea that you could theoretically have your own data structures that you added objects to and never delete even though you have no intention of navigating to them again.

I guess could be seen as a memory leak if you squint. (Normally, I would consider it a memory leak if the lost memory is inaccessible, rather than merely being ignored.)

This idea seems odd to me; I can’t imagine a situation where I would accidentally end up in such a quandary, but - like I said before - I am tired and I guess it is theoretically possible. If you know of any real-life examples of this, I would like to hear.

4) Some garbage collectors can’t detect cycles, so that’s another form of legitimate memory leak.

The day is coming (or perhaps it is here?) where we won’t look in askance at a professional developer who is unfamiliar with hand-coded memory management.

That’s actually wrong. Garbage collectors cannot and do not relieve you from managing memory. All they do is remove the necessity of assigning responsibility for freeing heap objects; this removes some segfaults, but the rest are merely turned into memory leaks instead. This makes flawed code more robust, but not less flawed.

Even with a garbage collector, you still have to think about the lifecycles of allocated objects.

Lars starts by pointing out that it is hard to make both the compiler writers’ lives and the developers’ lives easy. While I am not touching the Einstein/sperm analogies, I agree, and I am arguing that we should swing towards making the developers lives easier over those of the compiler writer.

Lars then describes a form of Postel’s Law when it comes to using case, which is fine. However, he associates with it a pejorative term: “sloppy programmer”.

I think life for a programmer is hard enough already, and we should allow flexibility and “sloppiness” where we can get a machine to take care of it. I don’t care if I remember to turn off my headlights when I leave my car, because the cars I drive do it for me. I try not to be diligent about checking my blind-spot when turning. Not checking my blindspot would make me a sloppy driver; not switching off my headlights is irrelevant. Developers should have the same luxury of focusing on the important things, and ignoring the trivial computer-manageable issues.

We no longer call developers who can’t browse and tweak assembly code to be sloppy. The day is coming (or perhaps it is here?) where we won’t look in askance at a professional developer who is unfamiliar with hand-coded memory management. Similarly, we need to cast off the old idea that holding the shift key down in a consistent manner makes you a better programmer.

Lars attributes bugginess in rockets to font-choice. That seems a bit far-fetched to me.

He takes an interesting approach to arguing against pretty-printing software: that the original developer has a mental picture of its structure, and that changing its formatting will confuse them. I am not convinced; code is written once and read many times. Preserving weird formatting to maintain short-term consistency seems unappealing to me.

Lars brings up a strawman against pretty-printing programs that alter the case of comments. I have never seen one do this without an explicit request, and it certainly isn’t the norm. Another false analogy to forging signatures doesn’t help his case. Lars then takes a side-track into security risks of filenames without extensions. This is irrelevant to the case discussion.

He promotes case-sensitivity as a method of “smartening up” sloppy programmers. I reject the notion, just as I would reject the notion that combing your hair makes you a better programmer. Lars helps me make this point by pointing out that Free Pascal programmers about both good programmers and sloppy with their case and indenting consistency. Lars claims this is rare; I disagree - I just think that the Free Pascal developers would benefit from a pretty-printing tool to hide the unnecessary inconsistency between developers.

Lars warns about the use of underscore to separate words, because double underscores are hard to distinguish from single ones. I could equally argue that it is difficult to distinguish xyziiiabc from xyziiiiabc, so I am arguing against the letter ‘i’ in variable names. Or perhaps, we could just avoid variables that only differ by indistinguishable changes. Wait, wasn’t that my argument from the beginning?

To be fair, Lars points out a coding style that uses double underscore to indicate a variable is private (presumably in a language that doesn’t support the concept directly). I agree that is a poor style.

Lars has unwittingly helped my argument with two trivial (or should I say “sloppy”?) errors in the naming of programming languages: He calls Free Pascal ‘freepascal’ and Ada ‘ADA’. For someone who rails against sloppy programming and the need for case-sensitivity, these should seem like important differences. Fortunately, it was clear what he was referring to, and we can forgive him these trivial linguistic blurrings. I am just asking my compiler to offer the same grace.

> QUOTE
> Signify internal variables by two underscores after the prefix. That
> is, when a symbol must (for technical reasons) reside in the global
> namespace despite not being part of a published interface, then use
> two underscores following the module prefix. For example:
>
> svn_fs_get_rev_prop () /* Part of published API. */
> svn_fs__parse_props () /* For internal use only. */
> END QUOTE

With some fonts, one would not be able to tell that svn_fs__parse_props is an internal function only, since some fonts don’t easily distinguish two underscores from one underscore. Instead of abusing underscores for these situations, the language should have a private implementation section or the word private or priv should be embedded into the function.

Most likely, the programmers above are abusing the underscore because their language does not allow private functions, only global or public ones - which leads to spaghetti code and one large global dangerous namespace that uses kludges to become more privatized and modular.. instead of the modularization and privatization features being built into a proper language with units or modules instead.

The simplest thing that could possibly work for the compiler developer would be to use case sensitivity so that he does not have to implement UPPERCASE() functions around each variable and declaration name.

Unfortunately there is no such thing as the simplest solution, and Einstein was basically over-generalizing in his quote. There is no such thing as “simple”, otherwise we wouldn’t have things like swimming sperms that bop their heads on eggs and turn into 6 feet monsters at the age of 19. Try to explain that simply. Einstein was not simple either. The simplest solution would be to kill all life so that there is no complexity of life. The simplicity statements and generalizations are essentially useless.

One can always tell a sloppy programmer from a more organized programmer:

1. If one works in a case insensitive language and he types consistent code with consistent case, then he is an organized programmer.

2. If one works in a case sensitive language and he takes advantage of the case sensitivity for having types like Char while having another char type, and having this_var along with this_Var, then he is a sloppy programmer. Possibly a clever programmer, but a sloppy and dangerous programmer that shouldn’t be doing what he is doing.

The language should be case insensitive, while strongly enforcing case to be preserved. For example, the compiler should give hints that you have declared ThisThong along with ThisThOng. In some fonts, a smaller o looks so close to a bigger O that it is hard to tell. oOoOoO. Some fonts, it is easier to tell. Should software be based around subtle differences in fonts? I think not. Should rockets be buggy because of subtle difference in fonts? I think not. Do developers user different fonts? I think so. Just because the o on your screen is different than O, it doesn’t mean so on his screen.

Case sensitivity shouldn’t affect the program when it is compiled, so it should be case insensitive, but one should be given a warning for being sloppy. Or the editor should mark it as a spelling mistake. This way, it prevents idiots and clever programmers from doing tricky things like thIs_vAr and tHis_vAr and readme and Readme. Preserving case but keeping the language case insensitive also makes the language safer, in case someone was working on programming a rocket ship and accidentally didn’t get a warning or didn’t get a notification that they have a Thisvar and a ThisVar in their program.

I am against those tools that “pretty up” a bunch of source code at once (i.e. the tools or IDE’s pretty up code on the fly are okay but I don’t use them personally as they get in my way).

Why are the “pretty up” tools that format a bunch of source at once bad? While the programmer is creating his source code, he creates a picture of his code in his mind (for those that have photographic memories). He remembers how his code looks, and where those lines of code are that need some repairing or updating later. With this picture in his mind of his code, he knows where to find his code. The source code pretty tools screw up the picture … because it changes the code. Say you remember that there is this one line of code which you used ALL CAPS COMMENTS in order to remind yourself that it needs refactoring. So then the source code pretty tool goes over your comments and lowercases them for you in order to pretty up your source code. Uh oh.. there goes your big warning that you had to clean up that code… and you don’t even know that the big warning has been lowercased, because the “pretty up” tool did it behind your back!

You may never know that the pretty up tool went in there and removed your big emergency warning in CAPS because the summary it gives you when it is done might not be descriptive enough, nor will you actually go in and check to see every little change it made for you. Sometimes, the code isn’t changed drastically enough to change the picture enough or change your formatting enough.. but it is dangerous to have a tool reformat your code - it is similar to having someone else forge your signature because your were busy at the time and didn’t have time to write your signature neatly.

It is better for the programmer to use proper indentation himself while coding, and constantly correct his bad indentations than it is to write sloppy code and allow the source code “pretty up” tool to fix his errors.

Another thing” I have seen several people abuse the case sensitivity on UNIX, such as making a Readme file along with a README file in the same directory. This is ludicrous.

In addition to case sentivity issues, files without extensions, such as README files without a txt extension are also ludicrous. This can cause viruses to spread since a person unfamiliar with computers may click on that README file not knowing it has execute permissions (txt files should not be executed, even if their permission’s say they can be executed.. it is a basic security measure, and linux is supposed to be secure.. and if you are going to argue about this one, then I ask why files prefixed with a dots are hidden - why not make those visible if linux is so powerful, why hide those files from smart users - of course there should be a way to make them visible to advanced users, but that is besides the point).

Understand that I am not a Windows advocate nor am I biased, as I mainly use BSD and Linux as I am a systems administrator and web hacker for a living (although I use Windows on the desktop because most companies use it and I have to open Word files, etc.). Many programs that run in Linux are becoming more like Windows programs where one does not immediately see the file permissions, so even a readme.txt file could be executed (operating systems should prevent

I do enjoy the fact that case sensitivity makes sloppy programmers smarten up.. for example I hate the people that write end and END and End in modern pascal (I’m a modern pascal programmer). However, it should be a compiler warning or a spelling error in the editor. I can easily tell a sloppy programmer from a organized programmer by simply looking at his source code in case insensitive languages.. I can even tell if I have written a sloppy program - which is good, because I like to know if the program I wrote was an older one when I was sloppier, so I can fix it and review it closer. In case sensitive languages, it makes the code appear to be neat - but it doesn’t point out a sloppy programmer, because the sloppy programmer had to neaten up his code anyway in order to get it running (while he could have been sloppy in other areas which are harder to tell, such as overusing pointers when he doesn’t have to, or not allocating memory correctly, etc). At least if I see a SLoppy PRogram with horribly FormatteD slOppy Inconsistent source, I know to check for other sloppiness, such as bad memory allocations.

p.s. unfortunately the freepascal compiler writers are some of the sloppiest programmers.. they use Begin BEGIN and begin and End and end and END and their indentation is all over the place.. one space, two space, three space, no space.. with sometimes begin indented, other times begin not indented, etc. Some of the worst and sloppiest case code I’ve seen is the freepascal sources. However, the freepascal developers are a very rare case - they are sloppy with regards to case but they are good programmers. Usually, this is not the case though.

Looking back at some of my really old source files, I can easily find which code is bad code and which code is good - because when I began programming I was sloppy with case, and sloppy with indentation. By the way, if we should be enforcing case, shouldn’t we be enforcing indentation like Python does? I’m against that too because sometimes in rare cases you want to indent things without them being tied to a bondage tab.. i.e. large programs with long parameter lists.. long parameter lists need to be split up into separate lines and sometimes the enforced indentation can ruin special situations in large programs where custom indentation needs to be used.

Most human scripts actually have no notion of case – even Latin did not. The concept originated in Greek, was imported into the Romanic languages, and proceeded to spread to all of the Western world. But it does not exist anywhere else.

This doesn’t mean no other normalisations exist, of course; other scripts have their own forms – cf. Unicode NFC vs NFKC.

So do you bake a westernly assumption into a programming language? If not, do you avoid it by being inclusive and mandating other normalisations? If so, which? (After all, while they are normalisations, their semantics differ from monocasing, which you will have to understand and consider.)

I think the sensible non-parochial approach is follow Do The Simplest Thing That Could Possibly Work and just punt on any normalisation entirely. Baking assumptions into tools also makes more sense on this level.