> The main benefit of WHEN is the implicit PROGN it provides. The original > poster on this subthread said that WHEN is two characters more than IF, but > that's only if there's a single consequence form. More often, it's used > as:
Martin Rodgers wrote in message ... >In article <861zmckvka....@g.pet.cam.ac.uk>, gj...@dpmms.cam.ac.uk >says...
>> The fact that preprocessed C usually has lots of parens, >> to avoid precedence lossage, isn't very relevant.
>I've always used more parens in C than most other C programmers. That's >probably because I've always been uncomfortable with precedence. >Curiously, few editors and none of the dedicated C++ IDEs that I've used >support parens matching. I've even seen this mentioned in a Windows >developers magazine! So, at least _some_ C programmers miss this feature.
>Sometimes my image of programmers who choose to use C/C++ is of >masochists with hygiene problems. Instead of asking themselves why >they're banging nails into their flesh, they'll sharpen and perhaps wash >the nails, then call that a massive improvement!
>Any editor that does parens matching is a joy to use.
The reason C/C++ editors don't do parens matching is because it just isn't necessary. There rarely is a case when you have more than 2 parenthesis right next to each other. In Lisp it's a given that you need parenthesis matching, because that's how you read the language. Just like in C/C++ most editors support auto-indenting, because that's how you read C/C++ code. Putting parens matching in a C/C++ editor is like cracking a walnut with a sledgehammer.
In article <74heu0$qr...@uuneo.neosoft.com>, ztur...@elsitech.com says...
> Putting parens matching in a C/C++ editor is like cracking a walnut with a > sledgehammer.
What was I saying about hammering nails into flesh? -- Remove insect from address to email me | You can never browse enough will write code that writes code that writes code for food
In article <m267bo7wwu....@KludgeUnix.com>, Steve Gonedes
<jgone...@worldnet.att.net> wrote: >My point is that people are not intrinsically frightened of >parenthesis.
I'd have to disagree strongly on this one. Most programmers I know detest what they see as unnecessary parens in lisp. The point they miss, is that the parens are necessary because they (and the syntax they represent) give you the ability to treat code as data (i.e., lists) easily. Since they're not used to having this ability, they don't miss it, and don't see why they should put up with an ugly syntax for what they (incorrectly) see as no additional functionality.
> > Lispyness appears to have at least one meaning: syntax represented > > only using parenthesis, and if you use even more than needed, so > > much the better. All I can say is the evidence is overwhelming: > > for the majority of programmers this is one reason they don't like Lisp. > > Go ahead and just tell these > > people they are "stupid" and should come join the enlightened smarter > > people who don't care about syntax (yeah, right) and focus on semantics. > > This attitude/approach has not help lisp to expand its programmer ranks.
>... > My point is that terms like "excess" and "lispyiness" turn out to be > matters of personal style and that it is therefore difficult to have > rational discourse on a subject for which participants will not agree > on a meaning. No point being at each others throats when there are so > many others willing to do that for us!
I agree, and believe this reinforces my point: people who don't like the parens of LISP do so for perhaps personal, irrational or stylistic reasons -- and therefore telling them they should like it, or educating them on why they should like it, is just arrogant and ineffective. I'm certainly being arrogant and ineffective telling this community to use a different syntax, right? It goes both ways..
>><jgone...@worldnet.att.net> wrote: >>My point is that people are not intrinsically frightened of >>parenthesis. >I'd have to disagree strongly on this one. Most programmers I know >detest >what they see as unnecessary parens in lisp. The point they miss, is >that >the parens are necessary because they (and the syntax they represent) >give >you the ability to treat code as data (i.e., lists) easily. >Since they're >not used to having this ability, they don't miss it, and don't see why >they should put up with an ugly syntax for what they (incorrectly) see >as no additional functionality.
The good news is one can have both a less-parenthesis syntax, and at the same time still represent the code internally as lists. Such is what I've tried to achieve using LOOP, IF*, and my LET "bastard": (let a = 10 b = 20 do ...)
Let me say finally that people can and do learn to deal with all sorts of strangeness when they need to. Programmers in particular have a high level of "contortionist" by the very nature of our job, at least if you're good at it. So clearly people would learn whatever weird syntax if doing so got them something else of value, and over time, would associate that weirdness with the positive parts of the experience -- just like some people like being tied-up and whipped... or the taste of coffee..or beer.
Which means people would be switching over to Lisp if it had enough value to warrant getting over their initial distaste for the syntax. As Richard Gabriel said at the 40th conference, right now Lisp is perceived as the gateway to hell, while Java is the gateway to the internet. We must change the perception of what the gateway leads to, that is the educational part of our job. Just changing the syntax isn't going to change what the gateway leads to, but why have an obstacle?
Sorry for raising the ruckus, I'll go back to work now.
On Mon, 7 Dec 1998 06:28:17 +1300, "Chris Double" <ch...@cnd.co.nz> claimed or asked:
% Try as I might though I have huge difficulties in getting my head around % UNLESS. I know what it does, and it should be simple, but I look at an % UNLESS form and it takes me ten times as long to think about what happens. I % think my brain is broken in that area <g>.
I'm sure you find unless more appealing than when-not. In perl, there is the bizzar construct like this:
statement unless cond; statement if cond;
The statement gets executed if cond is the appropriate value for the given key word. I found to to be quite weird initially, but it grew on me. unless is the same way. If some condition is not met, I want to execute a block of code.
In article <74heu0$qr...@uuneo.neosoft.com> , "Zachary Turner"
<ztur...@elsitech.com> wrote: >The reason C/C++ editors don't do parens matching is because it just isn't >necessary. There rarely is a case when you have more than 2 parenthesis >right next to each other. In Lisp it's a given that you need parenthesis >matching, because that's how you read the language. Just like in C/C++ most >editors support auto-indenting, because that's how you read C/C++ code.
No, no, no, no, NO!
This ground has been covered again and again in this forum, but it bears repeating once more just to set the record straight.
Lisp programmers -- as a general rule -- neither count nor match parens explicitly. Editors that automatically indent Lisp code have been around for a long, long time. Emacs does it, of course. As do the editors in the IDEs of all of the PC and Macintosh hosted Lisp systems I've ever seen (freeware, shareware and commercial)...
The same editors typically provide keyboard navigation functions to move the cursor by various syntactic units, which is of course a useful thing to do in Lisp because all of the syntax is consistent.
* raff...@mediaone.net (Raffael Cavallaro) | Most programmers I know detest what they see as unnecessary parens in | lisp.
my take on this is that parens are necessary in lesser languages only when the operator precedence no longer make sense, and thus signal that something is more "complex" than it would have been without parentheses, and perhaps adding parentheses is something the programmer does only after hours of debugging, reinforcing the pain factor. further, any C or C++ programmer knows that parens are actually dangerous in that they can mean any one of about 4711 different things depending on context you can't possibly squeeze into a single screen, no matter how big. thus the parenthophobia would come from exposure badly designed languages. one way to test this hypothesis is to see if people who are not exposed to badly designed languages (C/C++/etc) are equally afraid of parentheses.
it's not exactly a scientifically valid argument, but I have never met a person who has seen Lisp in the important formative years who has this angst for parentheses, so I'll believe that the problem is that (some) people carry a lot of mental baggage from working with stupid languages.
it sometimes helps to explain to these people that parentheses in Lisp are on par with {} and ; in C, and agree with them that C's parentheses are badly designed and horrible, because no matter how smart they are in Lisp, they _are_ a f*cking pain in the b*tt in C/C++/etc.
#:Erik -- The Microsoft Dating Program -- where do you want to crash tonight?
* Kelly Murray <k...@IntelliMarket.Com> | I agree, and believe this reinforces my point: people who don't like | the parens of LISP do so for perhaps personal, irrational or stylistic | reasons -- and therefore telling them they should like it, or educating | them on why they should like it, is just arrogant and ineffective.
this is not my experience. telling people that their parenthophobia is misplaced in stupid languages is arrogant and ineffective because they have a reason to fear them. however, people also need to learn, pretty damn quick, that just because some two things look the same doesn't mean they are the same if they occur in two very different contexts. telling people that is perhaps arrogant, but it is effective, because it is true and those who stick to "once-and-for-all" learning aren't useful, anyway.
#:Erik -- The Microsoft Dating Program -- where do you want to crash tonight?
* Zachary Turner wrote: > The reason C/C++ editors don't do parens matching is because it just isn't > necessary. There rarely is a case when you have more than 2 parenthesis > right next to each other. In Lisp it's a given that you need parenthesis > matching, because that's how you read the language. Just like in C/C++ most > editors support auto-indenting, because that's how you read C/C++ code. > Putting parens matching in a C/C++ editor is like cracking a walnut with a > sledgehammer.
It isn't how you read the language! It's how *lisp* reads the language. You read the language by *ignoring* the parens and looking at how the words sit on the screen. That's why indentation is so important for Lisp (and why the rules are hairier than most `indent n spaces' languages), and also why you put all the closing parens on one line -- if you're not reading them there's no point in them eating space.
It's also why paren matching is so important in editors for Lisp -- if you're not keeping track of them, the editor had better.
"Zachary Turner" <ztur...@elsitech.com> writes: > The reason C/C++ editors don't do parens matching is because it just isn't > necessary.
my editor (emacs) does paratheses matching. i find it helpful for C/C++.
> There rarely is a case when you have more than 2 parenthesis > right next to each other.
i find that parentheses get nested quite frequently. i am doing number crunching oriented stuff so perhaps i get more than you. it may be just a matter of personal coding style.
> In Lisp it's a given that you need parenthesis > matching, because that's how you read the language.
not at all. when using a decent editor (emacs again), i just look at the indentation. the parens take care of themselves. especially closing parens. but then my editor helps me out.
there are many reasons to dislike lisp but the irrational fear of parentheses has to be the most inane. all it says is, i saw a lisp program and was afraid because i didn't immediately understand it. anyone who has used the language for longer than five minutes can come up with more relevant critism.
> Just like in C/C++ most > editors support auto-indenting, because that's how you read C/C++ code. > Putting parens matching in a C/C++ editor is like cracking a walnut with a > sledgehammer.
i like my sledgehammer thank you very much. emacs - the swiss army sledgehammer of editors.
David Cooper wrote in message <366AB2CB.8F89B...@genworks.com>... >Kelly Murray wrote:
>> My point is having ONLY the funny bastardized english-like IF >> would be better, because THEN code would be easier to understand
> A colleague of mine refuses to use WHEN (``IF is shorter to type,'' >he says, ``and has the same effect as WHEN if there is no ELSE >clause.'').
A wonderful thing about lisp [in general] is that you can program in the sytle you want to and lisp doesn't mind at all. Below is the lisp I fell in love with years ago, and the exact program that did it for me. I still find the goto's and all very readable, understandable, and pragmatic. Over the years I have collected all the "queens" programs in lisp I could find. I don't know if the later ones are any more readable or understandable then this old one. As the general programming paradigms move, lisp moves with them but [most of the time] doesn't force them on you. That is a good thing. Rusty
Place n queens on a board (graphical version) ; See Winston and Horn Ch. 11 ; ; Usage: ; (queens <n>) ; where <n> is an integer -- the size of the board - try (queens 4) ; ; I do not know who the original Author of this is but it was found with some ; XLISP example lisp programs. This has been slightly modified to run on ; PC-LISP V2.13. ; ; Peter Ashwood-Smith ; August 22nd, 1986
; Do two queens threaten each other ?
(defun threat (i j a b) (or (= i a) ;Same row (= j b) ;Same column (= (- i j) (- a b)) ;One diag. (= (+ i j) (+ a b)))) ;the other diagonal
; Is poistion (n,m) on the board safe for a queen ?
(defun conflict (n m board) (cond ((null board) nil) ((threat n m (caar board) (cadar board)) t) (t (conflict n m (cdr board)))))
; Place queens on a board of size SIZE
(defun queens (size) (prog (n m board soln) (setq soln 0) ;Solution # (setq board ()) (setq n 1) ;Try the first row loop-n (setq m 1) ;Column 1 loop-m (cond ((conflict n m board) (go un-do-m))) ;Check for conflict (setq board (cons (list n m) board)) ; Add queen to board (cond ((> (setq n (1+ n)) size) ; Placed N queens ? (print-board (reverse board) (setq soln (1+ soln))))) ; Print it (go loop-n) ; Next row which column? un-do-n (cond ((null board) (return 'Done))) ; Tried all possibilities (setq m (cadar board)) ; No, Undo last queen placed (setq n (caar board)) (setq board (cdr board)) un-do-m (cond ((> (setq m (1+ m)) size) ; Go try next column (go un-do-n)) (t (go loop-m)))))
In article <3122086205087...@naggum.no>, Erik Naggum <e...@naggum.no> wrote: > my take on this is that parens are necessary in lesser languages only > when the operator precedence no longer make sense, and thus signal that > something is more "complex" than it would have been without parentheses, > and perhaps adding parentheses is something the programmer does only > after hours of debugging, reinforcing the pain factor.
And these painful experiences have impressed upon them the importance of balancing parens. So they get one look at lisp code and say to themselves "Aaagh! I can't balance all those parens - I'll *never* understand this code," when of course nobody in their right mind tries to read lisp code by balancing parens (editors do that for you) but rather from indentation, and familiartiy with the indentation structure of common functions and macros.
Unfortunately, most programmers *are* exposed to c-like languages before they see lisp. The solution should be obvious to any enlightened school board - make lisp instruction a required part of the kindergarten curriculum ; )
On Mon, 7 Dec 1998 14:48:29 -0000, Zachary Turner <ztur...@elsitech.com> wrote: >Martin Rodgers wrote in message ... >>Any editor that does parens matching is a joy to use.
>The reason C/C++ editors don't do parens matching is because it just isn't >necessary. There rarely is a case when you have more than 2 parenthesis >right next to each other. In Lisp it's a given that you need parenthesis >matching, because that's how you read the language. Just like in C/C++ most >editors support auto-indenting, because that's how you read C/C++ code. >Putting parens matching in a C/C++ editor is like cracking a walnut with a >sledgehammer.
But having parens matching (with the various varieties; [], (), {}) is:
a) Easy to do, and
b) A natural component of an "electric mode" where code is automagically indented according to my favored policy.
I am going to step into this thread to share some thoughts. I have been programming in LISP for about 10 years. I had the opportunity to learn and use the language long after I had been exposed to FORTRAN. Fortunately, it was also long enough since I had used FORTRAN that I had forgotten most of the syntax, so the parentheses were not such a challenge.
Over the years, I have learned C++ and Java, out of necessity. I find that working in these languages with the requirement to balance {} and () and make sure that the ;s and ,s are in the right place is much more distracting than programming LISP using an EMACS editor ever could be.
I think the problem with LISP's reputation stems from introductory or survey courses that do not go into the depth of the language and provide accurate discussions of the purpose of the parenthesis. I also believe that students are not provided the opportunity to explore the power and expressiveness of LISP. People are exposed to LISP as an AI language with "Lots of Insipid Simple Parentheses" rather that a robust language that supports the development of elegant solutions in a very few lines of code and by-the-way, also supports AI work.
It appears to me that Java is a C/C++ programmers attempt to achieve the capabilities that LISP has displayed for 40 years in a syntax that is most familiar to C/C++ programmers.
> In article <3122086205087...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
> > my take on this is that parens are necessary in lesser languages only > > when the operator precedence no longer make sense, and thus signal that > > something is more "complex" than it would have been without parentheses, > > and perhaps adding parentheses is something the programmer does only > > after hours of debugging, reinforcing the pain factor.
> And these painful experiences have impressed upon them the importance of > balancing parens. So they get one look at lisp code and say to themselves > "Aaagh! I can't balance all those parens - I'll *never* understand this > code," when of course nobody in their right mind tries to read lisp code > by balancing parens (editors do that for you) but rather from indentation, > and familiartiy with the indentation structure of common functions and > macros.
> Unfortunately, most programmers *are* exposed to c-like languages before > they see lisp. The solution should be obvious to any enlightened school > board - make lisp instruction a required part of the kindergarten > curriculum ; )
In article <3671814D.7EA66...@mitre.org>, "Oscar A. Chappel"
<ochap...@mitre.org> wrote: >People are exposed to LISP as an AI language >with "Lots of Insipid Simple Parentheses" rather that a robust language
I think that's "Lots of Irritatingly Superfluous Parentheses" ; )
>It appears to me that Java is a C/C++ programmers attempt to achieve the >capabilities that LISP has displayed for 40 years in a syntax that is >most familiar to C/C++ programmers.
It might be more accurate to say java is an attempt to achieve the capabilities of Smalltalk in a syntax that C/C++ programmers (read, Sun's large cadre of unix c hackers) could understand. Of course Smalltalk was itself inspired by lisp, so... But seriously, the kind of capabilites found in lisp closures (or Smalltalk closures, for that matter) are only tacked on to Java as a poorly implemented afterthought.
