Hacker News new | past | comments | ask | show | jobs | submit login

Will it be too much to ask that the lispers build cool shit, and then brag about how lips made it easy? That would be more pleasant compared to this chest thumping.

The traits associated with lispers(lone wolves, nih syndrome, not interested in boring tasks viz. documentation) aren't unique to lipsers. Most of the good programmers, regardless of their language choice, suffer from this mentality, and a lot of good stuff comes out of it.

CLOS is cool - I get it. And extending the language by parse time code transformations is cool - I get that too. But does anyone seriously think that's the only thing that makes cool shit possible? There is a lot of great stuff out there which is written in languages which don't have macros, lot of stuff which was written by lone wolves, lot of stuff which existed but was re-written just because.

When someone is orgasming to perceived benefits of lisp(not all of it is real), why does he have to make it look like "look lisp is so powerful, so powerful it's harmful"? Can't you just leave it at lisp is powerful and it helped me build this thing super fast. Why is this pathetic excuse of "it's so powerful it's harmful" necessary?

And before you take out your pitch forks, please, you aren't the only one who programs lisp. I like Clojure, but mostly because of its nice seq abstractions, small core, interesting concurrency primitives, jvm. Macros are very low in my list of reasons to like Clojure. I tried liking Racket, and though I still like it, I would have preferred a higher level seq abstraction. I have skimmed through "Practical Common Lisp" and I fail to see the charm - there isn't anything which can't be conveniently and concisely coded in Ruby or Python. Lisp has its benefits, but they are overblown.




I’d tend to agree. The powerful metaprogramming features of Lisp are often unnecessary in day-to-day code, and definitely overhyped. It’s poor form to use a macro when something simpler will do. They’re just another tool, and when you need them it’s great to have them, but do all projects demand the most powerful language features? Hardly.

However, I’m also with the author in that there are obvious social issues arising from the existence of many implementations. If I write in C (or even C++) using standard libraries, then I can be reasonably assured that my code will compile anywhere. For obvious reasons, that’s not the case with Lisp dialects despite their superficial similarities, but I think that catches many neophytes off guard.

So even if such detrimental personality traits aren’t peculiar to Lispers, there is a strong apparent correlation because of the “fractured” community. Still, I think that has less to do with the power of the language and more to do with its simplicity and lack of BDFL. Anybody can make their own Lisp, their own object system, and no one will object—no pun intended.


> However, I’m also with the author in that there are obvious social issues arising from the existence of many implementations.

There are issues with competing implementations, but I would say that's not totally bad(options are good) and over time, some equals become more equals than others. Python has numerous web frameworks, attributed to the fact that it's easy to define your own, but a newbie is more likely going to stick with Django.

As I said, people re-implementing things "just because" isn't unique to lisp and might not be as bad. Look at Flask - it was an April Fool's joke by Armin which is now a proper micro framework. It isn't like Django wasn't the dominant and recommended framework when Flask came into being. It's good to have options and progress depends on people fooling around.

Look at async scene. You have twisted and you have gevent and you have diesel. Templates? Jinja2, Mako, Django, Cheetah etc.

Python or Lisp, most of the people are going to make their choices and stick with it. It's not like everyone who programs lisp starts writing their own CLOS, and not everyone who programs Python tries to write his own framework regardless of how easy it is.

> For obvious reasons, that’s not the case with Lisp dialects despite their superficial similarities, but I think that catches many neophytes off guard.

I don't know. Doesn't most of the programmers program to a particular scheme or lisp implementation(sbcl, racket, clozure, gambit, clojure)?

> So even if such detrimental personality traits aren’t peculiar to Lispers, there is a strong apparent correlation because of the “fractured” community.

I think more than the "fractured" community, it depends on the out of the box experience. If I am programming Racket, I won't try to build an object system of my own - the one it provides is good. If I am programming Clojure, though it doesn't provide a conventional object system, I agree with the choices and won't try to implement my own.


> > For obvious reasons, that’s not the case with Lisp dialects despite their superficial similarities, but I think that catches many neophytes off guard.

> I don't know. Doesn't most of the programmers program to a particular scheme or lisp implementation(sbcl, racket, clozure, gambit, clojure)?

Common Lisp libraries seem to be getting much more portable across implementations, so within the CL dialect the language implementation is becoming less of an issue I think. And QuickLisp is one counter point to the OP -- it has broad community support.


With the full disclosure that I used to work for muvee Technologies (muvee.com), I'd like to point out that muvee Reveal's "styles" are authored in a scheme dialect. Yes, that's a commercial consumer level fun product featuring scheme.

Incremental exploratory development of the DSL for authoring these "editing styles" was made pretty easy using macros and if you ask me to reimagine it, it won't be easy for me to think of another easier route.

For those saying "macros aren't useful for day to day code", please consider the possibility that you wouldn't have to write much of that "day to day code" if you had macros in your toolkit.

Impromptu, (fluxus) and DrScheme itself are some cool dudes where the productivity per person on those teams appears disproportionately high compared to other projects.


I agree. I can't see anything Lisp does that I can't do in Blub.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: