Perl will permit you to use as many parentheses as you need, but to taper off to quite a low dosage as you prepare to re-enter society. Here at perlmonks, we have experimented with bareblock braces as a maintainance substitute for severe parenthesis addiction, but many feel that that is just replacing one problem with another.

I don't intend to be offensive, but your reply is a good demonstration of the main problem that occur in language wars. The problem is - take a small but visual feature of the language, and bash it to death, without knowing the language enough. It's what makes people barf at Lisp's parens, which after some experience actually prove to be quite natural and harmless.

It's also what makes people laugh at Perl - mainly the syntax, the punctuation and all our beloved $_, $', $$ variables.

You should just take a look what comp.lang.lisp mostly thinks about Perl. Gosh... such a load of crap, it aches my eyes to read some of those posts. And what do they focus on ? Mostly "ugly syntax", and mostly on Perl as a "imperfect glue". Looks like the people are still in the early 90-s, when Perl wasn't yet used for full-blown applications "on their own".

So, don't be quick to judge a language by its appearance. I assure you, the parens no more make Lisp bad than Perl's syntax makes Perl bad.

Oh, but I disagree. Kind of. I see no problem in judging a piece of art by its appearance. And that's pretty much what this aspect of the language wars is focusing on: aesthetics. What looks good, feels right. Even in perl, some people have balked at $', $$, and other such "non-sensical" variable names. Which is why we have the English module. To give these variables actual names.

"I may be fat, but you're ugly - and I can lose weight!" At least Perl's "ugliness" can be overcome. ;-)

And some of it is - in perl 6, $_ becomes even more optional than in perl 5. The English module will likely live on. Parens become more optional - but nothing says they can't still be used.

There are different ways of thinking, and different ways of expressing oneself. And different languages are different ways of expressing oneself - you need to find the language(s) that allow you to express yourself in the most reliable, maintainable, and flexible (to changing requirements) fashion. Sometimes that will be perl. Sometimes that may be lisp. Other times C, C++, C#, .Net, Java, shell scripting, or whatever. Probably not ForTran or COBOL, though.

Bottom line is that you need to be productive. That is, you need to produce something. To me, it's just like the editor wars. Most of my team has switched to FTE, partly because I'm a member of that project. But I stressed to each person that, at the end of the day, your choice of editor is immaterial, as long as you are productive in it. If you find vi is the most productive editor for you, use it! If it's emacs, fte, nedit, or "cat > foo.C", it doesn't bother me. However, we don't write editors in our group, so don't write your own. Just find one and use it. However, if it's not the same as me, there is some razzing to be taken. :-)

That's a bit like saying "X assembly language lets you use curly braces as much as you like so you'll have no trouble if you switch from C". It ignores the meaning of the curly braces and the extra levels of abstraction and power that comes with their meaning.

Sooner or later, what happens when a solution comes too mind that naturally expresses itself as a few lines of inlined (or worse) Lisp code. Will you be strong enough to resist?

Take anything for its applications rather than sheer love for it. Just think, what are the things, that you cannot accomplish because of hanging to lisp and you would have answered yourself for the detachment, if those other things, really have values in your life.

a lot of languages are similar, but there are something difference from each other. you learn another way of doing things or a better way to do things, and much more, which will benefit you in a long run. such as, I felt i first time get the idea of recursion when i did it in Lisp.

that's why a lot of people have 'learning another language each year' in their new year resolution.

not to mention, it's better not to stuck with one language and reluctant to learn new things, for career-wise at least.

I hope you understood my intention correctly...

I don't intend to "love only one language". I like several languages, each is good for its purpose. I like C++, it has its uses, I like Perl, I like Lisp (though mostly academically).

What I want to overcome is the constant feeling of "oh, I should write something in Lisp". Because maybe I shouldn't, maybe I'll be able to fill this need with Perl, and leave my liking of Lisp on the inspirational level.

Or maybe you should use the right tool for the job, no matter what the right tool is. I've never used Lisp, but I'm sure there are some things it can do better than other languages like C++ and Perl, so when those things come up, use Lisp.

    -Bryan

Get him, guys! He's one of them!!!

:-)

• When I program in C, I laugh at those who foolishly squander CPU cycles with their "high level" language constructs.
• When I program in Fortran, I scoff at those languages who don't handle arrays and parallelism properly.
• When I program in Perl, I wonder how all those other languages live without regular expressions and CPAN and DWIM.
• When I program in Lisp, I dismiss anyone who doesn't think macros are like sliced bread.
• When I program in Scheme, I sneer at anyone who can't write a compiler for their language of choice.
• When I program in Haskell, I wonder how anyone could think static typing was anything other than the "Right Thing "
...and yet I somehow manage to use each of those languages in one way or another. Go figure.

Macros can provide cutesy solutions to some problems, and can provide a performance boost if you have an inferior compiler, but I challenge you to give a compelling example of what macros can do, that you couldn't also do (almost as succinctly) with higher order functions in perl. Here's a list of things that I probably won't find compelling...
1. Yet another implementation of Prolog
2. functions that don't evaluate their arguments (wrap 'em up in a sub{} closure
).
3. a 10% speed boost (Perl's too slow to worry much about speed.
4. custom made regular expression embedded language (already got it)

None of these, to me, a new Lisper, are what macros are about. Macros are about being amazingly lazy as a programmer. About finding those patterns of code that you write all the time, and making the system do the work for you in ways that are nearly impossible in other languages. It's not about speed, though certainly macros can be faster, especially if you look at things like the CL regex engine. The point is that I'm lazy, and I don't like typing things, and macros let me say it once, and more succinctly than other things. Lisp isn't the hammer for every problem, nor is Perl, nor is any tool. I don't trust a programmer who things his favorite hammer is the best hammer.

Whether you can do something with higher order functions or even simpler constructs isn't a great argument against having macros.

Recently I needed to do something for every string of length N or fewer. So I wrote a function that returned a closure that enumerated all strings until exhausting the string space. But I had to loop over the string space a few times in the program, and it got really cumbersome to write things like this:

(flet ((next-string (make-string-enumerator <num>)))
  (loop for str = (next-string) 
        until (null str)
        do <body>))
[download]

Once I'd written that twice, I realized that I was eventually going to make mistakes writing or rewriting expressions like that, so I wrote a macro that expanded into that expression. Once I had the macro, I could write the following instead of the above:

(dostrings (str <num>)
  <body>)
[download]

Now, maybe you're thinking "That's only a two-line savings in any place where you'd need to do what you're doing", but to me the win is that the macro lets me write only the important things (the <body>, the maximum string length <num>), and the macroexpander takes care of the tedious and error-prone code for me. This isn't just saving typing: I don't have to think up a variable name like next-string whenever I need to loop over all strings, and so I never have to track down bugs introduced by changing variable names when refactoring. If I don't use it outside the macro, I don't even need to remember the purpose or interface for make-string-enumerator, either.

Yeah, I could have written something analogous to the <body> form as a function of the string returned by the enumerator, and written the original loop like this:

(let ((next-string (make-string-enumerator <num>)))
  (labels ((looper (body enumerator)))
    (let ((str (funcall enumerator)))
      (when str
        (funcall body str)
        (looper body enumerator)))))
[download]

But I'm not sure that's easier to understand than either the original loop form or the dostrings macro, and anyhow it's still long enough that I think I'd want something like my dostrings macro to generate it if I had to write something like that more than once.

Functions (including higher order functions and closures) are one way of factoring code for maintainability; macros are another. They complement each other.

Well, I don't know whether these will be compelling or not, but you might want to check out:
• http://www.gigamonkeys.com/book/practical-building-a-unit-test-framework.html
• http://www.gigamonkeys.com/book/practical-parsing-binary-files.html
• http://www.gigamonkeys.com/book/practical-an-html-generation-library-the-compiler.html
-Peter

This means both looking at perl code that does things in cool ways and that does stuff that's just darn cool by itself. Obviously, this standard is going to be a bit of a personal judgement call, but I happen to think that solving this problem is a pretty cool thing to do. Of course, I'm biased since I happen to think that my solution is pretty cool. However, look over other expert-level quizzes in the (now sadly mostly defunct) perl qotw archives. Some of those will almost certainly be cool problems from your point of view.

And there's always the monastery's own Cool Uses for Perl.

In short, I think you can overcome your lisp addiction by changing your tastes away from "elegance over all" and to the (perhaps more low-brow) "find cool stuff".

--
@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
[download]