Yes, Martin, please give it a try. Only then can we know if the parenthesis is real issue or not. There is no point arguing about it. The only disadvantage is that, over time, people will forget that it is actually a list. But, hey, if it does not prevent us from writing efficient and correct code then why not forget it and leave the compiler to worry about that. If possible, I would also want to see a macro that allows me to write (x < y) instead of (< x y).
(+ x y) can be read literally as "add x to y" (square x) can be read literally as "squares x" (< x y) how do you read this literally left-to-right? Relational operators being so common in code, I think it abuse of notation is valid here. Thanks Ajay G. On Sun, Dec 20, 2009 at 12:40 AM, Sean Devlin <francoisdev...@gmail.com>wrote: > Give it a shot. Hack up a prototype. Let's see what happens. > > On Dec 20, 12:07 am, "Alex Osborne" <a...@meshy.org> wrote: > > Phil Hagelberg <p...@hagelb.org> writes: > > > "Alex Osborne" <a...@meshy.org> writes: > > >> But this is the same "great idea" that everyone who's ever used a lisp > > >> since the dawn of programming has come up with and despite numerous > > >> attempts, to my knowledge not a single one of them has ever taken off. > > > > > You're forgetting about Dylan! > > > > Gosh. So I am. It was created by Apple, no less. It even lets you use > > semicolons. Semicolons and Apple! That's got to be a recipe for > > success with the superficial masses. > > > > Seriously though, there's plenty of examples that show that popularity > > does not strongly depend on readable syntax (look at HTML, Ant, heck > > Perl). But from either side, an argument based on an appeal to > > popularity is sort of missing the point. I share the opinion of Mark > > Engelberg and others. I don't mind Lisp syntax because it has benefits, > > but it's definitely not as readable. The sweet expressions guy (David > > Wheeler) covers this pretty well: > > > > http://www.dwheeler.com/readable/retort-lisp-can-be-readable.html > > > > I'm not sure if sweet expressions are the answer. Or even if there is > > an answer. But for me editor support is key. I've overheard this > > conversation countlessly, about so many languages: > > > > "Oh, what's that you're coding in?" > > "Foobar. It's pretty awesome." > > "Yeah, it looks pretty nice." > > "See how you don't need to specify the blahs? The compiler just > > figures it out." > > "Nice! I might try it out. Does it work with Eclipse?" > > "Well, sort of, but ..." > > "Oh. Are there any other nice editors that work better with it? > > Netbeans maybe?" > > "Not really. There's an Emacs mode but ..." > > "Oh. Well. Nevermind then. Some other time, maybe." > > > > I know David Wheeler's retort to the suggestion of tools is: > > > > If you have to use tools to make parens less of a problem, perhaps > > you should use a better notation that removes extraneous characters > > in the first place. > > > > But I'm not sure I agree with him. I find code (in any syntax) harder > > to read without syntax highlighting. I also find it frustrating to > > write without at least basic auto-indentation. We're going to want > > tools anyway and Lisp's simple syntax and homoiconicity make it so much > > easier to write them. > > > > Funnily enough, I know people who claim Python and Ruby are horrifying. > > What do they prefer? XSLT. Yes, that XSLT. Yes, the W3C one. Really. > > > > > Why? Better editor support. Structural editing, on the fly validation, > > online previewing, XPath generation, backmapping, extensive > > auto-completion, profilers, debuggers, graph and table visualizations, > > WYSIWYG XSL-FO report generators, the list goes on and on. The language > > and syntax are quite frankly awful, but boy do they have some nice > > tools. > > > > The more I use paredit's structural editing the more I find I can't live > > without it either. The one annoyance I have with it is when I > > accidentally manage to insert a stray bracket and it gets confused. But > > maybe here there's something to be learned from the XSLT folks, even if > > their serialization format leaves a lot to be desired. Maybe paredit > > should be taken to its logical conclusion: just edit data structures > > directly, don't worry about the text. > > > > Let your editor display and edit infix math. Heck, let it show you > > complex math expressions with LaTeX formatting for the ultimate in > > readability. Let it show nesting just with indentation. > > > > When you save the file, what does your hypothetical editor do? It > > writes things out, properly indented, in that good-old relatively easy > > to parse (for both man and machine) syntax from time immemorial. > > > > Can we have our cake and eat it too? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com<clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
