They must be counting all the Marxism departments as Economics departments. It is evidently useless to ask economists anything as if they were a homogenous group.
Sorry about the poor formatting, but when I replaced the tabs by spaces I got caught by some ``lameness filter'' that told me to remove ``junk characters'' so I put the tabs back in...
I don't think Common Lisp's type system is less expressive than Haskell's. Can you define a Haskell type ``integer between 5 and 217''? In Lisp you can. The main difference is between static vs dynamic typing. To avoid runtime type errors and/or gain efficiency, you _can_ declare types, and smart compilers as CMUCL will do as much type inference as they can based on the information you give them. In my experience, when you get used to Common Lisp and it's type system, you don't get many runtime type errors anymore, or maybe none at all. Just as a Haskell newbie doesn't get any programs to compile at first because of all those type errors, but an experienced Haskell or ML programmer knows how to avoid those errors in the first place (just as in Lisp).
And no: Infix syntax is NOT ``very powerful''. Fine, you can change the precedence of infix operators in some languages, but you don't have to in Common Lisp because there is no precedence problem in the first place! If you want embedded languages, Common Lisp's macros are a very strong and unique tool. Why do you think OCaml has such a complicated and VERY hard to use tool as Camlp4? Only to emulate a small subset of what you can do with Common Lisp macros much easier. Common Lisp books sometimes warn about macros being ``complicated'', but they are laughably trivial to use and yet more powerful when compared to a monster like Camlp4.
When programming in ML or Haskell, I find myself most of the time thinking about how to outsmart the type checker again by defining more and more complicated union types; this is fun, actually, but only as long as you are playing around with it. When you want to get something done, the static type checker quickly becomes your main enemy, who keeps you from getting work done. Just look at the discussions about ``phantom types'' on the OCaml mailing list, or just try to define an Y-combinator in an ML like language. This is so hard (because of the type checker), that many ML programmers even think it can't be done! Writing the damn thing down in Common Lisp is trivial.
Slashdot Mirror
Nah, can't be. They wouldn't call it "genuine advantage" then, would they?
If I want PDF, I know where to find it...
They must be counting all the Marxism departments as Economics departments. It is evidently useless to ask economists anything as if they were a homogenous group.
Hah: Found it. Yes, it was Dahl, a story from 1952.
I remember reading a short story about this idea decades ago. I forgot by which author, perhaps Roald Dahl or somebody. Does anybody remember?
You, Sir, are an asshole ;-)
Most students probably didn't know what "confidentiality" means and played safe...
Sorry about the poor formatting, but when I replaced the tabs by spaces I got caught by some ``lameness filter'' that told me to remove ``junk characters'' so I put the tabs back in...
I sometimes use this for currying:
,func)
,@(mapcar #'list eargs args))
,x)
,f ,@eargs ,x)))))
:-)
(defmacro curry (func &rest args)
(let ((f (gensym))
(eargs (mapcar (lambda (arg)
(declare (ignore arg))
(gensym))
args))
(x (gensym)))
`(let* ((,f
(lambda (&rest
(apply
Looks a little weird, but works pretty nice
I don't think Common Lisp's type system is less expressive than Haskell's. Can you define a Haskell type ``integer between 5 and 217''? In Lisp you can. The main difference is between static vs dynamic typing. To avoid runtime type errors and/or gain efficiency, you _can_ declare types, and smart compilers as CMUCL will do as much type inference as they can based on the information you give them. In my experience, when you get used to Common Lisp and it's type system, you don't get many runtime type errors anymore, or maybe none at all. Just as a Haskell newbie doesn't get any programs to compile at first because of all those type errors, but an experienced Haskell or ML programmer knows how to avoid those errors in the first place (just as in Lisp).
And no: Infix syntax is NOT ``very powerful''. Fine, you can change the precedence of infix operators in some languages, but you don't have to in Common Lisp because there is no precedence problem in the first place! If you want embedded languages, Common Lisp's macros are a very strong and unique tool. Why do you think OCaml has such a complicated and VERY hard to use tool as Camlp4? Only to emulate a small subset of what you can do with Common Lisp macros much easier. Common Lisp books sometimes warn about macros being ``complicated'', but they are laughably trivial to use and yet more powerful when compared to a monster like Camlp4.
When programming in ML or Haskell, I find myself most of the time thinking about how to outsmart the type checker again by defining more and more complicated union types; this is fun, actually, but only as long as you are playing around with it. When you want to get something done, the static type checker quickly becomes your main enemy, who keeps you from getting work done. Just look at the discussions about ``phantom types'' on the OCaml mailing list, or just try to define an Y-combinator in an ML like language. This is so hard (because of the type checker), that many ML programmers even think it can't be done! Writing the damn thing down in Common Lisp is trivial.
Just my 0.02$.