> Make no mistake: Java/C/C++/C#/Perl are much worse than OCaml! There appears to be just one good tool, with OCaml coming a distant second.
where "one good tool" links to http://www.podval.org/~sds/tool.html, an essay praising Common Lisp.
Devout ?x aficionados tend to be a little... opinionated.
I've met plenty of devout Prolog, C, C++, and Java aficionados, and yes, they're opinionated.
Also, you're more likely to notice opinions that differ from your own than ones you agree with, these are more likely to be held by groups you don't belong to, and you're less likely to belong to minority groups, such as Lisp programmers.
No you haven't.
It hasn't helped Lisp's cause that a majority of its promoters are heavily opinionated.
> If the prior probability assigned to a hypothesis is 0 or 1, then, by Bayes' theorem, the posterior probability (probability of the hypothesis, given the evidence) is forced to be 0 or 1 as well; no evidence, no matter how strong, could have any influence.
> (well, you cannot have garbage collection if you have pointers anyway)
what? Java and so on certainly have pointers. Was this written before anyone realized that was possible, or is he just defining "pointers" differently from how I am?
(This is why I love C. No other practical language can claim to be able to implement a full-fledged GC as a library.)
Not to rain on anyone's parade, but I don't think many people think of a conservative & non-compacting GC as "fully fledged".
(Don't get me wrong. It's probably useful, but y'know... let's call a spade a spade.)
Edit: to be clear, this is the classic difference between a reference (a value without arithmetic) vs a pointer.
C doesn't permit arbitrary pointer arithmetic. e.g. If you take a pointer to the first element of an array and decrement it, the behaviour is undefined. It's permissible for the GC to crash your program in that situation. You don't need to dereference it: just having that pointer, even ephemerally, is undefined behaviour.
If you deallocate an object, then all pointers to that object are, technically, rendered as-though uninitialized: it is undefined what happens if you even attempt to determine the address of a previously-deleted object. This permits implementations to set dangling pointers to NULL.
Finally, a pointer to e.g. an int can't be used to access e.g. a float at that location. It is valid to convert an int pointer to a float pointer, but the consequences of dereferencing it are undefined. An exception exists for characters: any pointer can be converted to a char pointer and used to read the bytes of the object.
The upshot is that every pointer in C always points at a valid object of a known type - or just-allocated memory which hasn't had a value put in it yet - or the GC is allowed to crash the program. Of course, most (all?) compilers don't actually generate code where it's always possible to find out what type of object a pointer is pointing at, or even whether the pointer has actually gone out of range.
The real issue in C - other than a lot of code depends on the above rules not being enforced - is that it's valid to convert a pointer to an integer, store it for long enough for an eager GC to remove the object, and then convert that integer back to a pointer. Now you have an invalid pointer, but the standard doesn't allow the pointer to become invalid. That means the only valid GC must assume any integer might be a pointer in disguise (unless it can prove it could never be converted into a pointer), and it can't move objects around either, because it can't just go modifying integers which might be pointers to those objects.
C, in theory, allows this restriction, since computing a pointer to another object and dereferencing it is undefined behavior, but most implementations seem to relax this restriction.
I mean, this isn't pointer arithmetic, this is constrained offset lookup implementing a subset of pointer arithmetic (only addition of numbers >= 0?). I'd argue they're still not pointers unless you can derefence an arbitrary integer.
To be clear, they would still be called pointers. But when people talk about the complications of pointers, they are referring to non-standard behavior which is necessary with today's C code (and pretty much all historic C code).