"Sigh. (Programming language quality is usually inversely proportional to the number of special forms.)"
I tend to agree with this, and I'm not a lisp fanatic.
I'm turning into a Lisp snob
41–50 of 94 posts
Re: I'm turning into a Lisp snob
#42IMHO, he is not a snob. Realist would be a more
apropriate term.
Just my 2c.
-lisp guy
Re: I'm turning into a Lisp snob
#43"I could show these poor imperative programmers how their problems could be solved much easier in Lisp if I wanted to." That to me (as an outsider) seems to be the main message of these Lisp blogs. But at some point, nobody will believe you could do it, unless you actually do.
Yes, if Lisp is so powerful, where are all the super programs written in it? I'm only aware of EMACs and maybe at one point Autocad? And I guess PG wrote a couple webapps with it....
news.ycombinator.com is written in a new lisp dialect.
Re: I'm turning into a Lisp snob
#44Go just strikes me as profoundly boring.
"Uh, we do lots of C. Yeah, and lots of Python. Dude. Let's make a language that's like, uh ... C and Python! Yes! Awesome."
In a world where the only thing harder than Haskell is Google's interview questions, you'd think they would've come up with something more original.
Re: I'm turning into a Lisp snob
#45Earlier quoted context omitted.
You seem to be complaining that... Lisp doesn't exist? You seem to be saying his complaints are of the from "A hypothetical language I have in my head can do that better", but the complaint is of the form "This existing language does that all and better." Given that the only other "problem" in the post is a Hello World post, surely you aren't complaining that the author failed to include a "Hello World" lisp program?…
I'm curious, i rarely see any REAL[1] criticism of lisp, just the old "ughh, my eyes, all those parenthesis, aaa" type of nonsense. Why do you think its a wrong direction? [1] Im not talking about implementations, obviously, Common lisp, scheme and clojure have their problems, im talking about the general idea of lisp.
I think Lisp's philosophy, as explained by Paul Graham (perhaps you've heard of him :) ), is to enable the programmer to do anything they put their mind to. When choosing whether to do the powerful thing or the simpler thing, they will choose the thing that gives the programmers more power, and point out (not entirely incorrectly) that they can wrap up simpler versions for simpler cases with macros.
As a skilled developer, I certainly prefer this philosophy to the Java philosophy of "If the feature might be abused, leave it out." (Obviously, I simplify that, but there's a lot of truth there.) But I don't think it's the right way to think of languages as we go forth, and I don't think it can scale as we go forward.
Instead of seeing languages in terms of what they permit, I see them in terms of what they deny. In particular, what invariants do they maintain? Now, that might seem an odd way of looking at it, but what it is is support for the next question: What do languages build on top of this invariant?
All the languages that I am currently interested in, and all the ones that I think provide the way forward, maintain invariants that Lisp does not let you maintain, precisely because it gives the Lisp programmer too much power. One obvious example: You can't "mutable lisp" your way into a language that has immutable variables all the time. If the language provides for mutation, even if you program in a strictly immutable subset of the language, your libraries, including your very base libraries that make up the "runtime", are likely to be mutation-based. (Getting around this might be possible but hardly worth it.) Erlang builds a huge runtime around having such pervasive immutability, and while mutable Lisps can borrow large swathes of Erlang's libraries and capabilities, they are incapable of providing a guarantee at the language level that no function you ever call will mutate a value out from underneath you. Erlang is a great example of building on quite a few invariants (read "programmer limitations") and producing things that are harder and/or impossible without them.
Another example: Type system. Lisp certainly lets you layer type systems on top of your language, but without enforcement by the language, there's a barrier as to how much you can take advantage of it. What the ML family does with types is not something you can add to a Lisp and end up with the same thing you get with native language support. You can come close, but there's a final level of integration or loop-closing (don't have a clean word for this concept) that you can not get to.
Smaller example: Haskell's laziness. You can add laziness constructs to a strict language (see also: Python generators), but you can not macro your way to a fully-lazy language starting with a strict one, at least not in any reasonable manner. (This feature excites me much less, but it's another example of something you have to start with.)
When the entire philosophy is about empowerment, you close the doors to a lot of things that can only be obtained by carefully-selected disempowerment of the programmer, most of which are fringe right now, but which I think will become more important over the future. Truly ultimate power only comes from assembler; languages give you their power by restricting the assembler they can generate.
In the single programmer case, especially the mature single programmer case, "more power" may be a great thing, but I think it breaks down pretty quickly as you get more people involved, especially as you get less-than-experts involved, and I think a lot of Lisp's failures to take over the world come from this basic issue, and some second-order effects.
What I want to close with is something I already said: Certainly, if I had to choose between a conventional Java-style B&D language or Lisp, I'd take Lisp. But the interesting action is occurring in the fields dominated by constraining the programmer: parallel programming developments, STM, immutability and/or banning shared memory, and potentially other interesting things that all involve first taking things from programmers, then building on the resulting invariants that things like Lisp or Perl or Ruby make a big point of not constraining you with. (I'm interested in type-safe string manipulations to ban XSS at the type level, for instance.) There are Lisps doing those things, but notice precisely that they have to be built in at the language level; you can't just macro your way to Clojure's STM. (And if that does happen to be how it is implemented, I'd run screaming; STM isn't very useful unless it is a very strong guarantee. And any connection with other JVM libraries will be very hard, too.)
Re: I'm turning into a Lisp snob
#46Earlier quoted context omitted.
Yes, if Lisp is so powerful, where are all the super programs written in it? I'm only aware of EMACs and maybe at one point Autocad? And I guess PG wrote a couple webapps with it....
That's a logical fallacy. Something can be both great and unknown to you. Usually, you seek information about things you know you need/want, and can afford. If a topic does not interest you, you will forever remain oblivious to it, except maybe for some tangential news about it that reach you by accident. It's naive to think that just because you're a programmer you know everything there is to know about the software…
There should at least be one canonical example. I'm not claiming to know everything, I'm trying to fill in my knowledge. If lisp is so great, and so much more productive, and used by the greatest programmers on Earth, point me to some great code so I can become more informed.
Should I start reading EMACS source? Show me the code! If there's not at least one great open source project written in lisp, I'm not inclined to take your claims prima facie.
Re: I'm turning into a Lisp snob
#47Those guys, who designed it were not amateur. The main goal is easiness to code for average offshore programmer (hi, Java). Just name it 'C 2.0'.
Are you slamming the people of the island state of Java, or the programming language, or both?
Re: I'm turning into a Lisp snob
#48Earlier quoted context omitted.
I also feel that Lisp is a wrong direction. Its main problem is the lack of static typing. It is understandable that a language which has existed for so long with relatively little change would lack a static type system, but with as much progress as has been made in research on type systems since then, there is no good reason for a modern language to lack a powerful type system.
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 confusing dynamic with none at all.
Common Lisp has a powerful object system and dispatch scheme, but it isn't as powerful as Haskell's type system. Type classes provide compile-time multi-methods which can be every bit as dynamic as CLOS's when needed, but which are statically checked as much as is possible. In addition, type classes make it possible to dispatch not just on argument type but also on return type. How do you write a Common Lisp function which polymorphicly converts an integer to whatever type you need? This is admittedly a bit of a weak example, but polymorphic conversions like this can probably be useful(for example, you could use it to implement a somewhat inefficient heterogenous list).
In Haskell(I'm not very familiar with Haskell, but my testing indicates that this would work): class FromInt t where fromInt :: Integer -> t
Haskell also has parameterized types, which aren't as needed in dynamic type systems, but that relative lack of need is only because a dynamic type systems considers a program that calls a method which doesn't work on an object's type at runtime to be type-safe.
In a statically typed language with type classes and sufficiently powerful syntactic macros, it would be possible to conveniently defer to dynamic type checking in way that would type-check statically. The macros are only necessary for the convenience part. Otherwise, you'd have to create a lot of type classes for every type you wanted to use dynamically. 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.
Re: I'm turning into a Lisp snob
#49Earlier quoted context omitted.
That's a logical fallacy. Something can be both great and unknown to you. Usually, you seek information about things you know you need/want, and can afford. If a topic does not interest you, you will forever remain oblivious to it, except maybe for some tangential news about it that reach you by accident. It's naive to think that just because you're a programmer you know everything there is to know about the software…
There should at least be one canonical example. I'm not claiming to know everything, I'm trying to fill in my knowledge. If lisp is so great, and so much more productive, and used by the greatest programmers on Earth, point me to some great code so I can become more informed. Should I start reading EMACS source? Show me the code! If there's not at least one great open source project written in lisp, I'm not inclined…
Google "cliki" and "lisp success stories" in the future.
Re: I'm turning into a Lisp snob
#50"Ugh, look at all that syntax."
As a common lisp programmer it's sad to see somebody do to another language what people do to CL. One superficial glance at the syntax and write it off, without further criticism.
"Lisp has a lot of brackets, LOL"