[DanWeinreb]

Hello, my co-worker, whoever you are. Yes, Common Lisp should have dictionary literals. I don't know why there hasn't been a commonly-used reader macro for this. (Emacs Lisp mode and other tools would have to know about it, so it needs to be a widely-accepted convention.)

Common Lisp does have strong typing. What it does not have is static typing.

I am at the SPLASH conference, and the Dynamic Language Symposium is happening right now. There is controversy over whether we can find a way to have the benefits of both static and dynamic typing in the same language. The great advances in type inference make me hopeful. The keynote speaker, Allan Wirfs-Brock, replied to my question about this with more pessimism. It is not a simple question; for one thing, not everybody even agree about which factors are "pro" or "con" for either static or dynamic. I am not doing programming languages these days (I'm doing databases) but I continue to be hopeful.

[metageek]

Hello, my co-worker, whoever you are.

John Stracke. (I've been staying pseudonymous, but today I mentioned Adder, which is tied to my real identity.)

Common Lisp does have strong typing.

True. I need to remember to be more precise; "doesn't have strong typing" just means "doesn't have type feature Blub". Common Lisp has runtime type safety, and type hints for efficiency; what it does not have is the pervasive typing that I'm used to from C++, which has a separate set of benefits. The most obvious is that, in C++, I can change the interface to a class and be certain that the compiler will catch any caller that uses it incorrectly. (Although I suppose it may be possible to do something like that with CLOS. I haven't used much CLOS, since ITA avoids it.)

There is controversy over whether we can find a way to have the benefits of both static and dynamic typing in the same language.

I'd say that type inference already brings us nearly there: the convenience of dynamic typing, with the rigor of static typing.

I may be wrong, though; I've used ML and Haskell, but not enough to really feel where the pain points of type inference are.

[ohyes]

'True. I need to remember to be more precise; "doesn't have strong typing" just means "doesn't have type feature Blub". '

That might be less precise, but more correct :-P.

"Common Lisp has runtime type safety, and type hints for efficiency; what it does not have is the pervasive typing that I'm used to from C++, which has a separate set of benefits. "

The type declarations aren't just for efficiency (although they are frequently (ab)used for it).

"The most obvious is that, in C++, I can change the interface to a class and be certain that the compiler will catch any caller that uses it incorrectly."

I'm not sure what common lisp version you use, but wouldn't this be fixed by simply declaring types of everything? You can declare the types of on the slots of a struct, you can declare the types of arguments to functions, results of functions, variables, slots of objects, contents of sequences... (having trouble thinking of something you can't declare types on, maybe a hashtable? Although you could wrap the accessors in a function).

Then SBCL (at least) yells at you when you go to recompile the project.

[metageek]

wouldn't this be fixed by simply declaring types of everything?

Yes, but I'm not so sure about the "simply". It's only marginally easier in C++; but at least you know that haven't forgotten to declare anything.

[chaitanya]

> I haven't used much CLOS, since ITA avoids it.

Interesting. Is it for performance reasons?

[metageek]

...actually, I don't know. When I started, I was told we don't use it; I don't remember whether I was told a reason. If I was, it was performance; anything else would have been surprising enough to remember.

[sausagefeet]

I wonder if it's similar to why Jane St doesn't make a lot of usage of the O in Ocaml (from what I've gathered at least, I don't work there.....yet). Object systems can be nice but they tend to make understanding your code all the harder since you have all the dispatching. I don't know anything about CLOS but this is pointed out as a reason against using Java and the object system in Ocaml in the Caml Trading video.