Live data from Hacker News

I'm turning into a Lisp snob

briancarper.net

91–94 of 94 posts

Re: I'm turning into a Lisp snob

#91
post #71
post #68

Earlier quoted context omitted.

I am very certain that almost all of them could be removed without reducing the theoretical power of Common Lisp. At worst, successive rewrites of the program could reduce it to using a different set of simpler forms.

Well yeah, you don't need all those special forms to keep the language Turing complete, but you do need them to provide a lot of what people regard as the "powerful" features of common lisp. I wouldn't care to program without flet, for example, but obviously one could remove flet without any loss of power in a certain sense.

No, I mean that you could create a Lisp which had fewer forms, but that provided these special forms - that you would program using - except that they would no longer be special, but rather synthesized out of baser forms.

Re: I'm turning into a Lisp snob

#92
post #91
post #71

Earlier quoted context omitted.

Well yeah, you don't need all those special forms to keep the language Turing complete, but you do need them to provide a lot of what people regard as the "powerful" features of common lisp. I wouldn't care to program without flet, for example, but obviously one could remove flet without any loss of power in a certain sense.

No, I mean that you could create a Lisp which had fewer forms, but that provided these special forms - that you would program using - except that they would no longer be special, but rather synthesized out of baser forms.

You don't need to guess. Here is the list of special operators:

http://www.lispworks.com/documentation/lw50/CLHS/Body/03_aba...

Just tell us which ones you would replace.

Re: I'm turning into a Lisp snob

#93
post #48

Earlier quoted context omitted.

There is value in static checking for some things, but it is also limiting. It requires that code be written such that those things are declarative, can be understood without running the program. There is also value in having those things to be programmable, dynamic. This is a "good reason" even if you prefer the alternative. In Clojure, the lack of static type checking was not done out of laziness. > there is no goo…

> There is value in static checking for some things, but it is also limiting. Other than type-safe heterogenous lists(which is only true if you hold static type systems to a much higher standard of type-safety than dynamic type systems), what sorts of things do a type system with type classes, algebraic data types, and higher order functions prevent doing? > Lisps can and do have powerful type systems - you're confus…

> How do you write a Common Lisp function which polymorphicly converts an integer to whatever type you need?

How does the callee know what the caller needs?

Suppose that one callee produces an int (as above), the first caller wants a string (decimal digits in ascii) and the second wants a byte array (little endian). Do you really think that the caller (or compiler) should be responsible for accomodating those conversions? Now let's add a caller that wants the index of the "high bit" - how are you going to accomodate that? (Of course, other callers want an int - I'm just mentioning the callers that require some sort of conversion.)

Neither the callee nor the compiler/system can automatically provide anything beyond the most trivial of conversions. That's why the right solution to the third caller, either an in-line shim or a wrapper, is the right solution to either the first or second caller.

> With macros, you could just include the creation of the appropriate classes in the form that defines a new type. In fact, it could be built into the language making even macros unnecessary.

Lisp macros can do many other things. (Consider the loop construct.)

Re: I'm turning into a Lisp snob

#94
post #57

I am (now) a lisp programmer and find myself boring many people to tears about it. But perhaps I am first a language guy, and like to see new solutions to problems. None give me the satisfaction that Lisp has (smalltalk was close, however). But I like to see new well-designed languages and how well, or not, they address the engineering challenges. For example, turbo pascal was written during the time that I was writi…

how can you say that C is challenged by Go? Go is built with C. This is true with python as well - in being a C abstraction. C is well suited for the UNIX-like programming, where you create efficient system libraries. With as little abstraction as possible I might add.
Post reply on HN