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

If you can't say no, what do you say to the users who are begging you to say no because they like the language as it is? Every language design decision is a compromise, and a person empowered to make those decisions is going to make people unhappy. Just look at Perl and Python: Perl said no to people who demanded orthogonality, and Python said no to people who wanted a free-for-all TIMTOWTDI language. Java said no to deterministic finalizers. C++ said no to exceptions that could be restarted. All those languages are doing fine.

A better idea would be to never turn your back on any class of users -- ignoring their specific requests, perhaps, but always making sure they can solve their problem using their language. Even that strategy doesn't require language support for everything. CPython does just fine with the scientific computing community by punting to C bindings, for example.

The examples Yegge provides don't make any sense to me. The need to port Java code to Clojure is questionable, since Clojure provides good Java bindings. If you want a more Clojure-y version of a Java library, then a straight line-for-line port is not much of an improvement. As for the LOOP macro, you don't have to add everybody's little helper function into the standard library. I'm a big fan of languages adding helper functions to standard libraries if there's one obvious way to write them and the act of adding them will save everyone else from including their own version in all their projects, but a LOOP macro is absolutely NOT that.

(Unless it's just a straight-up reimplementation of Common Lisp's LOOP macro, which would do exactly one job, which is allowing Common Lisp programmers to be more comfortable in Clojure. Hey, guess what -- Common Lisp programmers already have one of the easiest paths to learning Clojure, since they know a Lisp already. Many non-Lisp programmers are tackling the learning curve and embracing Clojure, so CLers can't complain that it's too hard. Plus, many Common Lisp fans regard LOOP as an abomination and never use it anyway. Writing control structures in a complex DSL that few programmers bother to learn completely is not one of Common Lisp's best features. Saying "no" to a Common Lisp-style LOOP macro would be the right thing to do.)




a complex DSL that few programmers bother to learn

What? Plenty of CL programmers learn LOOP. It's unbelievably convenient; as far as I'm concerned it is a masterpiece of usability. An abomination? Perhaps. Crack is an abomination and it's a masterpiece of usability too. But I don't care. I'm not a purist, and LOOP makes my work easier and more fun.

Complex DSL? Complex to specify, perhaps. Complex to implement? Not that bad. I wrote a pretty big subset of it for Parenscript and it wasn't hard. Complex to use? Not at all.

The reason many Lispers dislike LOOP is that it's un-Lispy. It's a foreign body implanted in the Lisp organism. Interestingly, though, CL's immune system doesn't reject it, meaning that it interoperates fine with everything else. If there were an impedance mismatch, LOOP wouldn't have lasted.


I use loop for simple things, but iterate is more general. For example, you can put your collect forms inside other forms, not just at the loop "toplevel". Also, editing larger chunks in an iterate form is easier, and automatic indenting works better.


ITERATE is one of those tastefully designed macros, very intuitive to a LOOPer.


"what do you say to the users who are begging you to say no because they like the language as it is?"

Java had this problem with Generics. A sizeable portion of the Java community had a massive allergy to them because they'd previously been burned by C++ templates. Of course there was the typical language war response "you're just not smart enough", but no matter how many times the people railroading it in protested that Generics weren't templates the facts remained:

They looked like templates

They had lots of funny little side effects and gotchas (just like templates)

Nobody really understood them, and even if they did, nobody could explain them. See also:

Class Enum<E extends Enum<E>>

In other words, it looks like a duck, it quacks like a duck (etc).

It is entirely possible that with different syntax (not the C++ style angle brackets) and different keywords (extends in the above example is clearly different from the normal extends in an object context) there would have been less cognitive dissonance from the C++ refugees and less pushback.

But ultimately what it boiled down to was this: the JCP (java community process) was a massive failure because you couldn't vote against things. You could only vote yes, no was not even an option, and abstentions were ignored (and therefore useless). It is like Communism - they call it democracy, but there's only one party to vote for...


Yeah and the major problem with Java generics is they aren't more like C++ templates.

Today it is 100% clear that the naysayers were not only wrong about Java generics. They are wrong about generic programming in general. Unfortunately they managed to cripple Java before this realisation became obvious.


Actually, I despise Java generics and have a much higher tolerance for C++ templates. Just more proof that you can't please everybody :-)


I like Common Lisp's LOOP, personally.


It is an abomination until you learn how to use it, then it is completely awesome.


same with `format', they're easy to bad-mouth until you've used them a couple of times, then you don't want to contemplate programming without them


Everything is an abomination until you learn how to use it.

The difficulty with loop is it takes something trivial and makes it more complex than it needs to be. Simple things are not simple. Complex things are rare and loop doesn't simplify them enough.


That might be true. It is indeed complex if you look at the BNF in the hyper-spec. (http://www.lispworks.com/documentation/HyperSpec/Body/m_loop...)

If you ignore the hyperspec, however, and get a feel for it by looking at examples and writing code using it, it becomes quite simple. It is very useful when you are translating C or Java code.

(http://www.unixuser.org/~euske/doc/cl/loop.html)

I find it quite readable in comparison to many of common lisp alternatives for iteration. And I kind of disagree that simple things aren't simple.

For example: (loop for i from 0 below 10 do ...)

Is pretty much the simplest construct that you normally need. Granted, I would likely just use dotimes in that case... but lets say you are iterating between 5 and 15, dotimes becomes unwieldy, where the for loop is pretty much the same code with the numbers changed.

(loop for i from 5 below 15 do ....)

Now try incrementing by 2

(loop for i from 5 below 15 by 2 do ....)

compare to the similar do* code

(do* ((i 5 (+ i 2)))

    ((>= i 15))

  ....)
kind of a toss up to me.

Not that I don't understand your point... in fact, as little as a year ago, I felt that way too... but I have since changed my mind.

My current preference is to use do* if writing a macro that needs iteration, and to use loop when I am doing something similar to a list comprehension or array traversal.


I love Common Lisp's LOOP, it's very handy. For those who prefer something lispier, there's always ITERATE

http://common-lisp.net/project/iterate/

(common-lisp.net seems to be down)


ITERATE is an excellent gateway-drug to LOOP.

I sometimes joke my programming language is LOOP instead of CL: http://www.reddit.com/r/science/comments/bc91w/on_the_8th_da...


Loop and Format are only useful for getting work done, but they fall flat for waxing poetic on LISP beauty.




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

Search: