Slashdot Mirror

"It is strongly, dynamically typed, which means that you can spend more effort on telling your program what to do rather than the nitpicky details of how to do it."

I'm not sure what the first part of this sentence has to do with the second. I like (good) static typing precisely because it saves me effort—I find out about my mistakes at compile time rather than runtime. See Nickle's type system for an example of what I like.

The sections of the GPL you quote do indeed establish that programs that make use of GPLed code fall under the GPL, and thus must follow its terms. But this: "...and the compulsion to provide source code to anyone who asks free of charge plus any reasonable copying and/or distribution fees..." just isn't true and isn't supported by the quoted material. The GPL does compel you to distribute the source code to anyone who receives the binary on which it is based. See the GPL FAQ for details.

"Nobody likes having their source code used as if it was simply public domain. How would you like to have your source code used by anyone in anyway they want without having to give you anything in return?" Uh, I've been giving my work on e.g. Nickle, XCB, and PSAS away for over 20 years. I actually like it pretty well.

"Have you actually read the GPL or any other OSI approved licenses?" Read them, taught them, talked them over with lawyers including FSF's Eben Moglen. Let me recommend Larry Rosen's Open Source Licensing: Software Freedom and Intellectual Property Law as a resource to you as you explore the world of open source licensing further.

Why does this topic bring the, uh, technically challenged out of the woodwork?

I'm a Ph.D. computer science professor with 20 years of experience in design and implementation of programming languages, and the co-author of a C-like programming language featuring static and dynamic typing and runtime operand checking. The parent poster is confused.

Static type checking involves automatically recognizing type-unsafe operations at compile time. In many programming languages, including C, if you write"s" - 1 the + operation is ill-defined, because the left-hand operand is of the wrong type: i.e., there is no string that is a legal operation to the - operator. The compiler can detect this at compile time and refuse to compile the program.

Dynamic type checking involves automatically recognizing type-unsafe operations at run time. In many programming languages, such as Python, if you write"s" - 1 inside a function definition, the compiler will not detect the problem, because the general problem of detecting this kind of error is unsolvable unless one restricts what programmers can write. Instead, the execution engine can detect the problem at runtime when the - is evaluated and refuse to continue executing the program.

Runtime operand checking involves automatically recognizing at runtime that an operation has an operand that, while of a type that might be legal for the operation being performed, is nonetheless illegal for that operation. In many languages, including Python, if you write 1 / 0 no error will be reported at compile time, because detecting such errors is in general impossible. Instead, the execution engine can detect the problem at runtime, and prevent execution from continuing.

(Of course, there also is such a thing as static operand checking, which bears the same relation to runtime operand checking that static type checking does to runtime type checking. This is a hot research topic right now.)

C's problem is that it (a) does not have a "safe" static type system, (b) does not have any dynamic type checking, and (c) has no operand checking. This combination of misfeatures is incredibly and obviously error-prone; offhand, I can think of no other popular language (not derived from C) that is broken in this fashion. Fixing (a) and/or (b) is not sufficient---(c) also needs to be fixed. Java, for example, has shown that this can be done in a C-like compiled language without noticeable loss of efficiency. (This was shown for PL/I more than 30 years ago, so it's no surprise.)

The parent post gives an example in which the index argument to an array dereference is of the correct type and has correct operands. If x[2] was evaluated, this would be an operand error, since the combination of arguments x and 2 is not a legal operand combination for the array dereference operator. With the statement as given in the parent post, I'm not sure what principle it was trying to illustrate. I think, though, that it doesn't much matter.

Note that Nickle will quite happily compute 10,000! (exactly) in a fraction of a second on a similar machine, through the miracle of Karatsuba multiplies. It also supports arbitrary-precision rationals and definable-precision floats (default 256b mantissa) with arbitrary exponent, and features a calculator-like interactive mode. I don't use much of anything else for numeric calculations anymore. (Of course, I co-wrote it.)

According to Nickle, 100/2.54 is the repeating decimal 39.{370078740157480314960629921259842519685039}. The approximation 39.3700787 ought to be close enough for most work :-). Heck, I'd think 39.37 would pretty much do it. As a point of comparison, the old UNIX "units" program gives 39.370079

1. The Boehm-Weiser (BW) collector is not as portable as we had hoped. There are a number of platforms we wanted to run on where it just doesn't run at all. Relatively small changes to the target runtime can create a need to port it all over again. OpenBSD, in particular, was an ongoing hassle until we abandoned BW. Hans, I hasten to add, was quite encouraging, but he simply doesn't have time to adequately support the collector.

2. The BW collector doesn't work in our application. OpenCM has a few very large objects. For reasons we don't really understand, this tends to cause a great deal of garbage retention when running the BW collector. Enough so that the OpenCM server crashed a lot when using it. Please note that this was NOT a bug involving falsely retained pointers, as later experience showed.

3. Conservative collectors are actually too conservative. If you are willing to make very modest changes in your source code as you design the app, there prove to be very natural places in the code for collection, and the resulting collector is quite efficient.

4. Independent of the collector, we also hacked together an exceptions package. This was also the right thing to do, but it's easy to trip over it in certain ways. The point of mentioning this is that once you do exceptions the pointer tracking becomes damned near hopeless and you essentially have to go to GC.

   I think the way to say this is: exceptions + GC reduces your error handling code by a lot. Instead of three lines of error check on every procedure call, the error checking is confined to logical recovery points in the program, and you don't have to mess around simulating multiple return values in order to return a result code in parallel with the actually intended return value.

5. To provide malloc pluggability, we implemented an explicit free operation. This lets us interoperate compatibly with other libraries and do leak detection. Turns out to be very handy in lots of ways.

6. Hybrid storage management works very well. For example, our diff routine explicitly frees some of its local storage (example) [Sorry -- this link will go stale within the next few weeks because the OpenCM web interface will change in a way that makes it obsolete. If the link doesn't work for you, try looking for the same file in .../DEV/opencm/...] This is actually quite wonderful, as it lets us build certain libraries to be GC compatible without being GC dependent. One of the challenges in using a GC'd runtime in a library is compatibility with an enclosing application that doesn't use GC. We haven't tried it yet, but it looks like our gcmalloc code will handle this.

Eventually, we gave up on the BW collector and wrote our own. Our collector is conceptually very similar to the collector that Keith Packard built for Nickle, though we've since built from there. A variant of the Nickle collector is also used as a debugging leak tracer for X11.

The OpenCM GC system is reasonably well standalone. We need to document it, but others might want to look at it when we cut our next release.

On the whole, I'ld say that GC for this app was definitely the right thing to do. Once you get into object caches it becomes very hard to locate all of the objects and decide when to free them. We were able to use a conservative approach with no real hassle, and heap size is fairly well bounded by the assisted GC approach we took.

On the other hand, I would not recommend a pure conservative collector for a pro

Want an "interesting mix of imperative and functional features" in a language any C/C++/Java programmer can start working with immediately? Try Nickle.

From his comments, Chromatic would like Nickle. But I'm the co-designer---I have to say that :-).

Nickle is an interesting approach. Strictly numeric, but with arbitrary-precision integers and rationals, settable-precision floating point, convenient numeric I/O, GC, and much more. Plus it's a first-rate desk calculator. It's intended for prototyping numeric algorithms, among other things.

Actually, they say they will test with inputs as large as ``a few megabytes''. Note that it is always legal to merely echo an input if you can't figure out how to optimize it...

Regardless of how we do in the competition, we're learning a lot about our programming language and its implementation, anyhow. The task isn't a perfect fit for our language, which is good, since it has tickled some of the dark corners already.

Two days to go!