Can Clojure be as readable as Python or Ruby ?
If so, how ? Thanks ! -- 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
Re: Can Clojure be as readable as Python or Ruby ?
An old thread: http://groups.google.com/group/clojure/browse_thread/thread/319a1c77ed718ba/3e4be7484b7cbe38?pli=1 Also, someone proposed instead of (f a b c) begin to use f(a, b, c) or something alike but I don't have the thread link now On Wed, Mar 7, 2012 at 2:39 PM, Leon Talbot wrote: > If so, how ? > > Thanks ! > > -- > 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 -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Maybe this proposal: http://grokbase.com/t/gg/clojure/11ctt573jq/list-syntax-sugar-f-x-notation On Wed, Mar 7, 2012 at 6:09 PM, Angel Java Lopez wrote: > An old thread: > > http://groups.google.com/group/clojure/browse_thread/thread/319a1c77ed718ba/3e4be7484b7cbe38?pli=1 > > > Also, someone proposed instead of > (f a b c) > begin to use > f(a, b, c) or something alike > > but I don't have the thread link now > > On Wed, Mar 7, 2012 at 2:39 PM, Leon Talbot wrote: > >> If so, how ? >> >> Thanks ! >> >> -- >> 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 > > > -- 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
Re: Can Clojure be as readable as Python or Ruby ?
>> If so, how ? >> I think Python may be easier for you, but it's not simpler than Clojure. Simplicity is the strength of Clojure. http://www.infoq.com/presentations/Simple-Made-Easy I can learn a new syntax almost overnight (last night I started writing Dart code for the first time after googling the syntax for 15 min), but the power of macros, immutable data, and laziness are what really makes Clojure stand out. Timothy -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Wed, Mar 7, 2012 at 12:39 PM, Leon Talbot wrote: > If so, how ? > > Thanks ! > Isn't it already? -- 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
Re: Can Clojure be as readable as Python or Ruby ?
I think readable is in the eye of the beholder. I've only moderate experience with Clojure, but the following example from Open Dylan made me realize I really do prefer a concise representation over what is considered easier to read. http://opendylan.org/documentation/intro-dylan/why-dylan.html#functional-languages define method shoe-size (person :: ) if (person = "Larry") 14 else 11 end if end method; Versus http://opendylan.org/documentation/intro-dylan/why-dylan.html#algebraic-infix-syntax (define (shoe-size person) (if (equal? person "Joe") 14 11)) Albeit my preference could be different over a different example. Silly humans 8) The thing is, if you just keep using Clojure or another Lisp for a little while, you'll probably get used to it and find it comfortable. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Hi, I have recently started working in python, I don't find python very readable at all compared to clojure. It is more about familiarity than anything else. On Thursday, March 8, 2012 4:39:08 AM UTC+11, Leon Talbot wrote: > > If so, how ? > > Thanks ! -- 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
Re: Can Clojure be as readable as Python or Ruby ?
If we're going to talk about readability at all, then we need to first define what attributes make up that which is readable. What commonly passes for readability is simply a variant of Easy, namely readable means "near to" your current body of knowledge. Is German less readable than English? I think that the real question that is: if you know Python and Clojure equally well, then which is easier to read? Alex -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Mar 7, 9:39 am, Leon Talbot wrote: > If so, how ? > > Thanks ! [Closed as: Not a real question] -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Wed, Mar 7, 2012 at 3:16 PM, Alex Baranosky < alexander.barano...@gmail.com> wrote: > I think that the real question that is: if you know Python and Clojure > equally well, then which is easier to read? > > Alex > > > I know both equally well (actually, I've logged more hours in my life coding in Lisp syntax than other syntaxes), and I still consider Python to be significantly easier to read. A few specific things that hinder Clojure's readability in my opinion: * prefix notation for arithmetic operators defies centuries of mathematical notation conventions and consequently any mathematical formula will be less readable. * introducing variables creates new indenting level, making code "creep to the right" * as code creeps to the right, you need to have a lot more newlines (for example, between each input to a function) to get it to fit on the page. This lengthens the code block making less fit on a page, and also makes the code look a lot different than the exact same code would look if it were appearing in a place that were less indented. * The convention of using hyphens to separate words is hard to read (since - looks like the minus operator) and also takes up more width than camel case, contributing to the problem that you quickly find lines getting too wide and needing to be broken up. * loop/recur is significantly less readable than either the corresponding looping constructs in Python or the named let that Scheme offers, *especially* when you have some sort of nested looping going on, which is extraordinarily difficult to read in Clojure. * cond branches are sometimes written with the test and the answer on the same line, or when the test gets too long you have to write it with the test and answer on subsequent lines; this inconsistent formatting can make it hard to know in long blocks whether you are looking at the test or the answer * Interweavings of cond and let (a common pattern) end up ridiculously indented and hard to read [Grand's flatter cond macro helps with this; I'd love to see this brought into Clojure core] * Decades worth of classic algorithms involving imperative manipulation of arrays look significantly uglier in Clojure, because Clojure intentionally makes imperative manipulation more difficult. I have, for fun, converted many Knuth algorithms to Clojure, and they invariably are far less scrutable than the original. * Expression-oriented syntax (along with the indenting cost of using let) encourages people to pack far too much into one line rather than giving names to intermediate results. * DSLs are supposed to bring customized readable notation to many tasks, but by the time you include namespace prefixes and colons for all the keywords, DSLs don't really look that good. I mean, compare Frinj to Frink. Frinj's integration into Clojure is cool, but is there anyone who considers it even half as readable as Frink? I certainly don't. * I feel really clever when I condense some complex loop into some sort of map/filter/reduce using anonymous functions. And it looks brilliant when I read my own code that does this. But when I read someone else's compact higher-order stuff, it's usually a nightmare to try to interpret what it is doing. Python's loops may be verbose, but I always know exactly what I'm looking at when I read someone else's code. * And the number 1 problem with all Lisps is that when you look at Lisp code, it's a sea of sameness. Function applications, Macros, Control constructs, bindings, data lookups, etc. all look exactly the same. You look at Python code, and you instantly see the control flow of the code, the assignments, the tests, the results, the loops, the data, the data lookups, the breaks. It's organized, but visually distinct. I write code in Clojure because I find the semantics appealing, and I feel I can get more done in less time than a language like Python. "Code as data" might be nice for writing macros, but the reality is that it forces programmers to code in an abstract syntax tree which is more computer friendly than human friendly. If I were given the option to *read* a sample program illustrating some concept in any language of my choice, I would choose Python over Clojure in a heartbeat. All one man's opinion, of course, but I wanted to bring it up because I am someone who has logged many years working in Clojure and related Lisp languages and I still have the opinion that Python is the most readable language I have encountered. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Mar 7, 6:39 pm, Leon Talbot wrote: > If so, how ? > > Thanks ! Please define "readable". Thanks! -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Wed, Mar 7, 2012 at 3:12 PM, Joachim De Beule wrote: > Please define "readable". > > Thanks! > > "Readable" is a measure of how readily apparent the meaning of a program is from looking at it. If you wanted to measure this objectively, one possible way to do this would be to time how long it takes a group of programmers to read and understand a well-crafted program to perform some complex algorithm. Let's assume that the programmers are all competent in the language being measured. There are other things you might also measure: you could quiz them to determine if they really understand it as well as they think they do, you could ask them to modify the code, you could ask them to self-rate their subjective sense of how easy it was to understand the program. Tim Daly has opined several times that it would be nice if researchers would do something like this for literate programming, for example. It would be useful to know for sure whether programs in literate form are more readable than ordinary "self-documenting" code. We tend to think of readability as a fairly subjective thing, and it is subjective to the extent that for most of us, the only measure that matters is how long we personally feel it takes us to understand code written in a given language, and how much effort we have to expend to gain that understanding. But certainly it is a quantifiable concept, and it is theoretically possible to compare languages, code coloring schemes, documentation styles, pop-up support, and all other aspects of code readability in an objective way. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Going back to the original poster's question, I think if I could make only one change to Clojure's syntax to improve readability, I'd take a page from other functional languages like F# and Racket and add a way to bind local variables that doesn't indent. So, for example, (let x 2) code would behave like the current: (let [x 2] code) -- 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
Re: Can Clojure be as readable as Python or Ruby ?
You might have a difficult time getting other Clojure coders to adopt the practice in their code, but would this be almost as good? (let [x 2] code) Achieving that would be as simple as hand-indenting it that way, or adjusting the auto-indenter of your favorite text editor to do it that way. A couple of minutes of perusing clojure-mode.el for emacs didn't make it obvious to me how to do that, but I suspect it wouldn't be difficult. Andy On Mar 7, 2012, at 10:22 PM, Mark Engelberg wrote: > Going back to the original poster's question, I think if I could make only > one change to Clojure's syntax to improve readability, I'd take a page from > other functional languages like F# and Racket and add a way to bind local > variables that doesn't indent. So, for example, > > (let x 2) > code > > would behave like the current: > (let [x 2] >code) > > -- > 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 -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Wed, Mar 7, 2012 at 10:43 PM, Andy Fingerhut wrote: > You might have a difficult time getting other Clojure coders to adopt the > practice in their code, but would this be almost as good? > > (let [x 2] > code) > > Achieving that would be as simple as hand-indenting it that way, or > adjusting the auto-indenter of your favorite text editor to do it that way. > A couple of minutes of perusing clojure-mode.el for emacs didn't make it > obvious to me how to do that, but I suspect it wouldn't be difficult. > > Andy > > It's an interesting question as to how much of my psychological objection to let is the added nesting versus the physical indenting. I agree it would be a worthwhile experiment to adjust the auto-indenter for a while and see how it feels. In the meantime, I *strongly urge* everyone to check out Grand's flatter cond macro: https://github.com/cgrand/parsley/blob/master/src/net/cgrand/parsley/util.clj It lets you insert lets in the middle of cond expressions (like you can currently do with for) like: (cond (pos? x) 2 :let [y (* x x)] (> y 20) 4)) This totally transformed my coding style and improved the readability of my code substantially. Highly recommended. Since it is backwards compatible, I very much wish it were part of the core, and see no reason that it couldn't be. --Mark -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Wed, Mar 7, 2012 at 5:10 PM, Mark Engelberg wrote: > * introducing variables creates new indenting level, making code "creep to > the right" Mitigated by breaking functions into sub-functions (which is good practice anyway). > * as code creeps to the right, you need to have a lot more newlines Then your code is too deeply nested and should be broken into sub-functions. That's standard best practice across all languages. > * The convention of using hyphens to separate words is hard to read I disagree. I find camelCase far harder to read than hyphenated-names. > * loop/recur is significantly less readable I don't think it's "significantly" less readable but I do agree that recur is a bit of a wart. > * cond branches are sometimes written with the test and the answer on the > same line, or when the test gets too long you have to write it with the test > and answer on subsequent lines; this inconsistent formatting can make it > hard to know in long blocks whether you are looking at the test or the > answer Don't write long blocks. Don't write complex conditions. Introduction more sub-functions. > * Interweavings of cond and let (a common pattern) end up ridiculously > indented and hard to read See above (and I don't agree it's a "common" pattern... perhaps an anti-pattern?). > * Decades worth of classic algorithms involving imperative manipulation of > arrays look significantly uglier in Clojure Yet many algorithms are significantly cleaner in a pure functional style... > * Expression-oriented syntax (along with the indenting cost of using let) > encourages people to pack far too much into one line rather than giving > names to intermediate results. Again, poor style. Break things into sub-functions. > * DSLs are supposed to bring customized readable notation to many tasks, but > by the time you include namespace prefixes and colons for all the keywords, > DSLs don't really look that good. Then those DSLs are not achieving their design goals. DSLs are a good use case for :use or :require/:refer. > * ... But when I read someone else's compact > higher-order stuff, it's usually a nightmare to try to interpret what it is > doing. Really? I find the compaction outweighs the effort involved - as long as the code is modular enough (see comments above). > * And the number 1 problem with all Lisps is that when you look at Lisp > code, it's a sea of sameness. Function applications, Macros, Control > constructs, bindings, data lookups, etc. all look exactly the same. I actually find that to be a plus - there's no distracting variance that artificially makes things "different" that don't need to be. Syntax is very subjective. It's really good to here your pro-Python thoughts tho'... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Sean, I agree that breaking things into smaller functions can potentially help. Often, though, I find that a function begins by unpacking and computing a large number of values that are all important for subsequent computations. Dispatching these computations to helper functions would mean passing an unwieldy number of variables. One option is to have the helper functions inside the main function, inside the scope of these bound variables so that they don't have to be passed explicitly. But this potentially means several levels of nesting to bind the variables to their appropriate values (possibly testing for nil and other such conditions before computing further values), and then yet another level of nesting to create the helper functions (possibly with letfn, which is poorly indented by most of the IDEs last I checked). In such scenarios, decomposing into inner helper functions might actually exacerbate the problem of deeply nested and therefore highly indented code. It would be interesting to run a scan of public Clojure code to get a sense for the average nesting level, indenting level, and the average line width. I'd be curious as to how far off the norm my own code is, and how Clojure compares to other languages. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
I’m not sure that just adding counter responses to almost all Mark points really help. Most counter arguments here resume to "you are doing it wrong" and "all clojure 'warts' are here to force you to better design". Indeed some kind of code is more readable when written in an imperative way than functional way. Like some kind of code is more readable when written in a functional way. This depend what kind of code you want/need to write and that a strong point for supporting both style in same language. Clojure try to avoid imperative code style... Honestly I’m not sure if avoiding all imperative code is a good idea or not... I need more experience in clojure and lisp like language to have a good opinion on that point. But anyway I enjoy clojure as it is today. Mark, I would say using a few well designed macros you can make clojure feel a lot more like you want to. That would be interesting to see and experiment on. Have a nice day, all! Nicolas. On 8 mar, 08:37, Sean Corfield wrote: > On Wed, Mar 7, 2012 at 5:10 PM, Mark Engelberg > wrote: > > * introducing variables creates new indenting level, making code "creep to > > the right" > > Mitigated by breaking functions into sub-functions (which is good > practice anyway). > > > * as code creeps to the right, you need to have a lot more newlines > > Then your code is too deeply nested and should be broken into > sub-functions. That's standard best practice across all languages. > > > * The convention of using hyphens to separate words is hard to read > > I disagree. I find camelCase far harder to read than hyphenated-names. > > > * loop/recur is significantly less readable > > I don't think it's "significantly" less readable but I do agree that > recur is a bit of a wart. > > > * cond branches are sometimes written with the test and the answer on the > > same line, or when the test gets too long you have to write it with the test > > and answer on subsequent lines; this inconsistent formatting can make it > > hard to know in long blocks whether you are looking at the test or the > > answer > > Don't write long blocks. Don't write complex conditions. Introduction > more sub-functions. > > > * Interweavings of cond and let (a common pattern) end up ridiculously > > indented and hard to read > > See above (and I don't agree it's a "common" pattern... perhaps an > anti-pattern?). > > > * Decades worth of classic algorithms involving imperative manipulation of > > arrays look significantly uglier in Clojure > > Yet many algorithms are significantly cleaner in a pure functional style... > > > * Expression-oriented syntax (along with the indenting cost of using let) > > encourages people to pack far too much into one line rather than giving > > names to intermediate results. > > Again, poor style. Break things into sub-functions. > > > * DSLs are supposed to bring customized readable notation to many tasks, but > > by the time you include namespace prefixes and colons for all the keywords, > > DSLs don't really look that good. > > Then those DSLs are not achieving their design goals. DSLs are a good > use case for :use or :require/:refer. > > > * ... But when I read someone else's compact > > higher-order stuff, it's usually a nightmare to try to interpret what it is > > doing. > > Really? I find the compaction outweighs the effort involved - as long > as the code is modular enough (see comments above). > > > * And the number 1 problem with all Lisps is that when you look at Lisp > > code, it's a sea of sameness. Function applications, Macros, Control > > constructs, bindings, data lookups, etc. all look exactly the same. > > I actually find that to be a plus - there's no distracting variance > that artificially makes things "different" that don't need to be. > > Syntax is very subjective. It's really good to here your pro-Python > thoughts tho'... > -- > Sean A Corfield -- (904) 302-SEAN > An Architect's View --http://corfield.org/ > World Singles, LLC. --http://worldsingles.com/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Wed, Mar 7, 2012 at 11:37 PM, Sean Corfield wrote: > I actually find that to be a plus - there's no distracting variance > that artificially makes things "different" that don't need to be. > > I just thought of an amusing analogy. To me, reading Lisp takes more mental effort in the same way that it takes more mental effort to follow someone who is speaking in monotone (precisely because there is "no distracting variance"). The main reason I spoke up was because of the comment in the thread suggesting that readability is purely a function of what kind of syntax you are most used to seeing. Many people tend to assume that if you don't like the way Lisp looks, you just haven't been using it long enough. I wanted to offer a counterexample, as someone who has spent over 20 years reading Lispy code. I prefer to *write* Clojure, but I prefer to *read* Python. If I can find a language that I enjoy reading as much as I enjoy writing, that would be nirvana. That's why the original post for this thread caught my eye, and struck me as worthy of discussion. I know Rich has mentioned that he admires Python's concision, so it seems reasonable to compare and contrast their readability. It is worth noting that Clojure does have several things that elevate it over other Scheme/Lisps in terms of readability. The use of [] for vectors and {} for maps is a huge help. The ability to add commas anywhere you want is nice. The removal of extra parens from let is nice (I'm less keen on the removal of extra parens from cond because of the awkwardness that results when the test and answer are too big to fit on the same line). Short names for most of the built-in functions are also nice. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Thu, Mar 8, 2012 at 2:45 AM, Nicolas wrote: > I’m not sure that just adding counter responses to almost all Mark > points really help. Most counter arguments here resume to "you are > doing it wrong" and "all clojure 'warts' are here to force you to > better design". > Looking back at my initial email, I can see that it probably came across as a bit of a rant, and probably not as constructive a response as I had intended it to be. I understand where Sean is coming from with his point-by-point. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
> Looking back at my initial email, I can see that it probably came across as a > bit of a rant, and probably not as constructive a response as I had intended > it to be. I understand where Sean is coming from with his point-by-point. I did not find it so, and enjoyed reading it, albeit while disagreeing on many points. :-) My Clojure/West talk will engage this issue. Stu Stuart Halloway Clojure/core http://clojure.com -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Another way to flatten nested lets and conds is to use a macro that lets you insert conditionals in your lets (vs. your suggestion of inserting lets in conds). I wrote a let? macro that does that: https://github.com/egamble/let-else - Evan On Mar 7, 10:51 pm, Mark Engelberg wrote: > In the meantime, I *strongly urge* everyone to check out Grand's flatter > cond > macro:https://github.com/cgrand/parsley/blob/master/src/net/cgrand/parsley/... > > It lets you insert lets in the middle of cond expressions (like you can > currently do with for) like: > (cond > (pos? x) 2 > :let [y (* x x)] > (> y 20) 4)) > > This totally transformed my coding style and improved the readability of my > code substantially. Highly recommended. Since it is backwards compatible, > I very much wish it were part of the core, and see no reason that it > couldn't be. > > --Mark -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Thu, Mar 8, 2012 at 2:54 AM, Mark Engelberg wrote: > Looking back at my initial email, I can see that it probably came across as > a bit of a rant, and probably not as constructive a response as I had > intended it to be. No, I thought it was an interesting set of observations but, like Stu, I disagree on many points. As noted, syntax is definitely subjective. Ruby makes my skin crawl but I can't really put my finger on why (it feels like punctuation has been used for cryptic semantics - but I don't react to some other languages against which I could level that criticism). If I was doing heavy numeric computations, I'd probably find the prefix syntax in Lisp annoying, so I suspect your problem domain has a lot to do with your feelings about a language too. > I understand where Sean is coming from with his > point-by-point. Most of my comments would be true of code in other languages (and Scala came to mind, specifically, as I was suggesting breaking code into smaller units to aid readability). I'm interested in hearing more about the sort of functions that begin "by unpacking and computing a large number of values that are all important for subsequent computations". I'm not seeing this in my code so I assume we're working on very different problem domains - could you elaborate? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: Can Clojure be as readable as Python or Ruby ?
You should probably both share gists of real code you're talking about, shouldn't you ? Your discussion made me think that editors may help further in this area, without having to change the syntax. Currently, the editors only try to give some "hints" by playing with colors, but there are some other ideas that could be followed: - playing with contrast by also using the ability to change the fonts - playing with contrast by slowly decreasing the font's opacity as the code gets deeper (but where the cursor is, this should probably go away to ensure good visibility) => could help see the overall structure without seeing to much of the details? - playing with "proximity" by adjusting the line sizes. For example, there could be extra space around the "true" and "false" clauses of an if, there could be extra space around "condition/then" clauses of a cond, etc. - playing with the background color of blocks, potentially minimizing (and to some extend -in a modal structural editor- almost removing from sight) the parens - since it's not the same thing to "write/edit" and to "read" code, there could be the possibility to have a "read" mode where the editor could represent totally differently the source code (think it could even present it in some sort of prefix-notation :-) ) 2012/3/8 Sean Corfield > On Thu, Mar 8, 2012 at 2:54 AM, Mark Engelberg > wrote: > > Looking back at my initial email, I can see that it probably came across > as > > a bit of a rant, and probably not as constructive a response as I had > > intended it to be. > > No, I thought it was an interesting set of observations but, like Stu, > I disagree on many points. As noted, syntax is definitely subjective. > Ruby makes my skin crawl but I can't really put my finger on why (it > feels like punctuation has been used for cryptic semantics - but I > don't react to some other languages against which I could level that > criticism). If I was doing heavy numeric computations, I'd probably > find the prefix syntax in Lisp annoying, so I suspect your problem > domain has a lot to do with your feelings about a language too. > > > I understand where Sean is coming from with his > > point-by-point. > > Most of my comments would be true of code in other languages (and > Scala came to mind, specifically, as I was suggesting breaking code > into smaller units to aid readability). I'm interested in hearing more > about the sort of functions that begin "by unpacking and computing a > large number of values that are all important for subsequent > computations". I'm not seeing this in my code so I assume we're > working on very different problem domains - could you elaborate? > -- > Sean A Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > World Singles, LLC. -- http://worldsingles.com/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) > > -- > 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 > -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Sean Corfield writes: > Most of my comments would be true of code in other languages (and > Scala came to mind, specifically, as I was suggesting breaking code > into smaller units to aid readability). I'm interested in hearing more > about the sort of functions that begin "by unpacking and computing a > large number of values that are all important for subsequent > computations". I'm not seeing this in my code so I assume we're > working on very different problem domains - could you elaborate? I see this every so often, but it's usually easy to solve with partial. (defn write-jar [project out-file filespecs] (let [manifest (make-manifest project)] (with-open [jar-os (-> out-file (FileOutputStream.) (BufferedOutputStream.) (JarOutputStream. manifest))] (doseq [filespec filespecs] [HUGE GLOB OF CODE THAT USES project AND out-file] The doseq call needed to be converted to a reduce so it could accumulate some state, but the big glob of code to be extracted needed access to the `project` and `out-file` locals. Reducing with a partially-applied function makes this work nicely: (defn write-jar [project out-file filespecs] (let [manifest (make-manifest project)] (with-open [jar-os (-> out-file (FileOutputStream.) (BufferedOutputStream.) (JarOutputStream. manifest))] (reduce (partial copy-to-jar project jar-os) #{} filespecs Just a thought. I can see where Mark is coming from, but I don't think the workaround is particularly difficult or onerous. -Phil -- 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
Re: Can Clojure be as readable as Python or Ruby ?
What I met by readable, is the capacity of reading someone's code. On 7 mar, 18:12, Joachim De Beule wrote: > On Mar 7, 6:39 pm, Leon Talbot wrote: > > > If so, how ? > > > Thanks ! > > Please define "readable". > > Thanks! -- 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
Re: Can Clojure be as readable as Python or Ruby ?
I think it's all down to pattern recognition. Once you've been developing in Clojure for a while you start to recognise patterns very easily, meaning reading other peoples code isn't really an issue. The same applies to languages like Haskell, when you're just starting out it might seem a little alien, but after a while you start to recognise things and "read" the code a lot quicker On Wednesday, March 7, 2012 5:39:08 PM UTC, Leon Talbot wrote: > > If so, how ? > > Thanks ! On Wednesday, March 7, 2012 5:39:08 PM UTC, Leon Talbot wrote: > > If so, how ? > > Thanks ! -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Thu, Mar 8, 2012 at 08:37, Sean Corfield wrote: >> * The convention of using hyphens to separate words is hard to read > > I disagree. I find camelCase far harder to read than hyphenated-names. I'm pretty sure there is an Emacs mode for displaying foo-bar-baz as fooBarBaz and reversed. -- Moritz Ulrich -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Moritz Ulrich writes: >>> * The convention of using hyphens to separate words is hard to read >> >> I disagree. I find camelCase far harder to read than >> hyphenated-names. > > I'm pretty sure there is an Emacs mode for displaying foo-bar-baz as > fooBarBaz and reversed. There's glasses-mode for displaying CamelCase as Camel_Case, Camel-Case, or whatever you like. Not sure if there's a mode that does the reverse. Bye, Tassilo -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Why not avoid all the keywords and create let-cond? (let-cond [a x b (* a 4)] (> b x) 1 :else 2) On Thursday, March 8, 2012 9:01:33 AM UTC-8, Evan Gamble wrote: > > Another way to flatten nested lets and conds is to use a macro that > lets you insert conditionals in your lets (vs. your suggestion of > inserting lets in conds). > > I wrote a let? macro that does that: https://github.com/egamble/let-else > > - Evan > > On Mar 7, 10:51 pm, Mark Engelberg wrote: > > > In the meantime, I *strongly urge* everyone to check out Grand's flatter > > cond macro: > https://github.com/cgrand/parsley/blob/master/src/net/cgrand/parsley/... > > > > It lets you insert lets in the middle of cond expressions (like you can > > currently do with for) like: > > (cond > >(pos? x) 2 > >:let [y (* x x)] > > (> y 20) 4)) > > > > This totally transformed my coding style and improved the readability of > my > > code substantially. Highly recommended. Since it is backwards > compatible, > > I very much wish it were part of the core, and see no reason that it > > couldn't be. > > > > --Mark -- 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
Re: Can Clojure be as readable as Python or Ruby ?
That would work for replacing a single cond surrounded by a single let, but I often find myself writing a series of nested lets, when- lets, if-lets, etc. to handle the exceptional cases in lets. A contrived example: (when-let [a foo] (let [b bar] (when (even? b) (let [c baz] (when (> b c) (let [d qux] (f a b c d))) becomes: (let? [a foo :else nil b bar :is even? c baz :when (> b c) d qux] (f a b c d)) On Mar 8, 1:24 pm, evandi wrote: > Why not avoid all the keywords and create let-cond? > > (let-cond [a x b (* a 4)] > (> b x) 1 > :else 2) > > > > > > > > On Thursday, March 8, 2012 9:01:33 AM UTC-8, Evan Gamble wrote: > > > Another way to flatten nested lets and conds is to use a macro that > > lets you insert conditionals in your lets (vs. your suggestion of > > inserting lets in conds). > > > I wrote a let? macro that does that:https://github.com/egamble/let-else > > > - Evan > > > On Mar 7, 10:51 pm, Mark Engelberg wrote: > > > > In the meantime, I *strongly urge* everyone to check out Grand's flatter > > > cond macro: > >https://github.com/cgrand/parsley/blob/master/src/net/cgrand/parsley/... > > > > It lets you insert lets in the middle of cond expressions (like you can > > > currently do with for) like: > > > (cond > > > (pos? x) 2 > > > :let [y (* x x)] > > > (> y 20) 4)) > > > > This totally transformed my coding style and improved the readability of > > my > > > code substantially. Highly recommended. Since it is backwards > > compatible, > > > I very much wish it were part of the core, and see no reason that it > > > couldn't be. > > > > --Mark -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Thu, Mar 8, 2012 at 6:04 PM, Evan Gamble wrote: > That would work for replacing a single cond surrounded by a single > let, but I often find myself writing a series of nested lets, when- > lets, if-lets, etc. to handle the exceptional cases in lets. A > contrived example: > > (when-let [a foo] > (let [b bar] >(when (even? b) > (let [c baz] > (when (> b c) >(let [d qux] > (f a b c d))) > > becomes: > > (let? [a foo :else nil > b bar :is even? > c baz :when (> b c) > d qux] > (f a b c d)) > > Right, I do run across this sort of nesting on a regular basis, and that's the kind of thing that that bothers me. With the cond macro, it would look like: (cond :when-let [a foo] :let [b bar] :when (even? b) :let [c baz] :when (> b z) :let [d gux] (f a b c d)) The cond is more faithful to the original structure and possibly more versatile, but yours is nicely compact for the common case that the interleaved statements are basically assertions on a given variable you want to ensure before moving on. I'm definitely going to give your let? a try and compare it. Thanks! -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Thu, Mar 8, 2012 at 9:44 AM, Laurent PETIT wrote: > You should probably both share gists of real code you're talking about, > shouldn't you ? > Most of the stuff I'm working on is closed-source. Offhand, I'm not sure what examples I can share, but I'll keep an eye out for that. In the meantime, just to get a feel for whether this is unique to my code or universal, I decided that I was going to carefully scrutinize the nesting level of the next public Clojure code I encountered. Completely randomly, the next Clojure code I encountered was this blog post: http://blog.japila.pl/2012/03/block-scanner-from-let-over-lambda-in-clojure Take a look at how indented the code is after merely 10 lines of code. We start to take this for granted in Clojure, but if you look at it with a fresh eye, it really is ridiculous. > Your discussion made me think that editors may help further in this area, > without having to change the syntax. > Currently, the editors only try to give some "hints" by playing with > colors, but there are some other ideas that could be followed: > - playing with contrast by also using the ability to change the fonts > - playing with contrast by slowly decreasing the font's opacity as the > code gets deeper (but where the cursor is, this should probably go away to > ensure good visibility) => could help see the overall structure without > seeing to much of the details? > - playing with "proximity" by adjusting the line sizes. For example, there > could be extra space around the "true" and "false" clauses of an if, there > could be extra space around "condition/then" clauses of a cond, etc. > - playing with the background color of blocks, potentially minimizing (and > to some extend -in a modal structural editor- almost removing from sight) > the parens > > - since it's not the same thing to "write/edit" and to "read" code, there > could be the possibility to have a "read" mode where the editor could > represent totally differently the source code (think it could even present > it in some sort of prefix-notation :-) ) > > I love these ideas. I think your final comment is especially insightful. I have no problem writing Clojure code, I just find it unnecessarily taxing to read it. The idea of separating the two, and possibly having a read-mode is an absolutely fascinating idea. In some sense, Marginalia is already a good positive step in this direction. The first time I ran Marginalia on my code I was astonished at how much more readable it was to have the comments in a separate column alongside the code, rather than interrupting the code itself. It makes me wonder how many other things could have such a positive, dramatic effect. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Thu, Mar 8, 2012 at 9:33 AM, Sean Corfield wrote: > I'm interested in hearing more > about the sort of functions that begin "by unpacking and computing a > large number of values that are all important for subsequent > computations". I'm not seeing this in my code so I assume we're > working on very different problem domains - could you elaborate? > > I can't show my closed-source code, but I'll try to elaborate to give you an idea where I'm coming from. I'm working with trees where the nodes can have a lot of attributes associated with them. I represent the nodes as maps like {:tag :data :children :attribute1 ___ :attribute2 ___} When working with a tree node, not only do I have to destructure/unpack a lot of these attributes, but often, there are several "measurements" I need, which are computationally intensive because computing those measurements generally involves walking the tree. Not all nodes have all the attributes, so there is a fair amount of testing as I'm destructuring and computing these measurements to make sure I'm doing the right thing. I use multimethods, dispatching on :tag, to handle certain types of context-sensitive behavior, but that alone doesn't handle all the dynamic combinations of attributes that can occur. If the helper function is external to the main function, that becomes a lot of stuff that needs to be passed along and immediately destructured at the other end. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Hi, Am Freitag, 9. März 2012 03:12:52 UTC+1 schrieb puzzler: > > > (cond > :when-let [a foo] > :let [b bar] > :when (even? b) > :let [c baz] > :when (> b z) > :let [d gux] > (f a b c d)) > > I wonder how long it will take until someone proposes monads. (domonad [a foo] [b bar] :when (even? b) [c baz] :when (> b z) [d guz] (f a b c d)) Combined with maybe the Maybe monad? Just a thought. Sincerely Meikel -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Mark Engelberg writes: Hi Mark, > In the meantime, just to get a feel for whether this is unique to my code > or universal, I decided that I was going to carefully scrutinize the > nesting level of the next public Clojure code I encountered. Completely > randomly, the next Clojure code I encountered was this blog post: > http://blog.japila.pl/2012/03/block-scanner-from-let-over-lambda-in-clojure > > Take a look at how indented the code is after merely 10 lines of code. We > start to take this for granted in Clojure, but if you look at it with a > fresh eye, it really is ridiculous. In some book (I think some Common Lisp book), I've read that code leaning to the right is a pretty good indicator for code written in a functional style. If it's straight top-down, then it's probably more imperative with one outer let and setf-ing of that let's variables. That said, of course there's nothing wrong with macros like the cond with :let or the let? in this thread. They look really useful, and I think I have some spots in my code where I could make use of them. Bye, Tassilo -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Thursday, March 8, 2012 9:33:04 PM UTC-5, puzzler wrote: > > I love these ideas. I think your final comment is especially insightful. > I have no problem writing Clojure code, I just find it unnecessarily taxing > to read it. The idea of separating the two, and possibly having a > read-mode is an absolutely fascinating idea. In some sense, Marginalia is > already a good positive step in this direction. The first time I ran > Marginalia on my code I was astonished at how much more readable it was to > have the comments in a separate column alongside the code, rather than > interrupting the code itself. It makes me wonder how many other things > could have such a positive, dramatic effect. > I think you struck it there, especially wrt marginalia. I've been wanting for a long time for some kind of code editor where ancillary things like comments/tests/contracts/examples may be displayed in a more appropriate manner, so that our code may be the star of our screen, while still being appropriately accompanied on demand by those comments/tests/contracts/examples. You're right that putting comments in a different column (which is scrolled synchronously) helps. Wouldn't be nice if that column could be replaced anytime with tests/contracts/examples/etc.? And with a larger monitor, multiple synced columns could be displayed. That said, to me, it's important that all of this is still editable at all times. I don't often read my own code in marginalia for this reason. Of course, you may just as well tell me that's what emacs allows with its buffers and swank-clojure & slime. But anyway, emacs' way of doing it is much more an *on demand* thing, and much less pervasive for now. I feel we could do quite a bit more with those tools. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
This has been a fascinating discussion, thanks to everyone involved. I do kind of feel like complaining about indentation in Clojure is like complaining that Ruby has too many parentheses ( shut up, they're optional!). I still feel like a big part of 'readability' comes down to personal preference. Python is often the canonical example of a readable language, but I find significant whitespace offensive, and other 'features' just terribly limiting. I spend most of my time coding in Ruby, which is very readable (for me), but I enjoy reading and writing Clojure equally well, if not more. One side-effect of Clojure's 'difficulty', for me at least, is being forced to think harder. This is a good thing. Homoiconicity was never a feature geared toward easiness, but rather power and simplicity. Anyhow, thanks for this discussion. I've enjoyed it. Jason On Mar 9, 2012 2:48 AM, "Tassilo Horn" wrote: > > Mark Engelberg writes: > > Hi Mark, > > > In the meantime, just to get a feel for whether this is unique to my code > > or universal, I decided that I was going to carefully scrutinize the > > nesting level of the next public Clojure code I encountered. Completely > > randomly, the next Clojure code I encountered was this blog post: > > http://blog.japila.pl/2012/03/block-scanner-from-let-over-lambda-in-clojure > > > > Take a look at how indented the code is after merely 10 lines of code. We > > start to take this for granted in Clojure, but if you look at it with a > > fresh eye, it really is ridiculous. > > In some book (I think some Common Lisp book), I've read that code > leaning to the right is a pretty good indicator for code written in a > functional style. If it's straight top-down, then it's probably more > imperative with one outer let and setf-ing of that let's variables. > > That said, of course there's nothing wrong with macros like the cond > with :let or the let? in this thread. They look really useful, and I > think I have some spots in my code where I could make use of them. > > Bye, > Tassilo > > -- > 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 -- 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
Re: Can Clojure be as readable as Python or Ruby ?
> This has been a fascinating discussion, thanks to everyone involved. So I've been lurking on this thread for some time, and thought I'd go and offer my two cents on the topic. While writing clojure-py, I've been in the unique situation of having to decide which language features will be implemented in Clojure and which will be implemented in Python. For example, deftype is not a compiler feature in clojure-py it is actually big macro that ends up calling the python internal functions to create types. My viewpoint is that, in general, Clojure and python are equal in their "readability" on a feature to feature basis. That is, define feature A in both Clojure and Python and you'll find that it will take you about the same amount of time to grasp what is being done in both implementations. The difference is that it normally takes 1/2 the number of lines of code to do something in Clojure than it does in Python. In other words, Clojure is more terse, and hence more dense than Python. So I think the question of readability I think it really comes down to the programmer making sure that he considers what future readers of his code will think. For example, this is perfectly valid Python, and something I see fairly often in other people's Python code: print [(x, y, x * y) for x in (0,1,2,3) for y in (0,1,2,3) if x < y] But personally I consider this sort of code unacceptable. Instead I tend to write Python code thusly: for x in (0,1,2,3): for y in (0,1,2,3): if x < y: print (x, y, x*y) It looks cleaner and is much easier to understand. In Clojure we have the power to reach the middle-ground: (print (for [x [0 1 2 3] y [0 1 2 3] :when (< x y)] [x y (*x y)])) Here we get the get the "expression" style of the first Python example, with the code structure of the second python example, and at the same time end up with less indents/linewidth than either Python example. This is the reason why the majority of clojure-py is written in clojure and not python. Timothy -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Evan Gamble writes: > (when-let [a foo] > (let [b bar] > (when (even? b) > (let [c baz] > (when (> b c) > (let [d qux] >(f a b c d))) > > becomes: > > (let? [a foo :else nil >b bar :is even? >c baz :when (> b c) >d qux] > (f a b c d)) For yet another take on this, consider using the maybe-m monad from clojure.algo.monads: (domonad maybe-m [a foo b bar :when (even? b) c baz :when (> b c) d qux] (f a b c d)) This is not 100% equivalent because any nil result in the binding list will terminate the whole expression and return nil. That's quite often the right thing to do. If not, there is a way to introduce bindings that are allowed to be nil: (domonad maybe-m [a foo b bar :when (even? b) c baz :when (> b c) :let [d qux]] (f a b c d)) Konrad. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Timothy Baldridge writes: > For example, this is perfectly valid Python, and something I see > fairly often in other people's Python code: > > print [(x, y, x * y) for x in (0,1,2,3) for y in (0,1,2,3) if x < y] > > But personally I consider this sort of code unacceptable. > > Instead I tend to write Python code thusly: > > for x in (0,1,2,3): > for y in (0,1,2,3): > if x < y: > print (x, y, x*y) How about this (my preferred version): print [(x, y, x * y) for x in (0,1,2,3) for y in (0,1,2,3) if x < y] I prefer this especially when the result is used in a computation, rather than printed. It removes the need to initialize some variable to an empty list and then appending to it. Konrad. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Evan Gamble writes: > (let? [a foo :else nil >b bar :is even? >c baz :when (> b c) >d qux] > (f a b c d)) Macros like that just make your code so much LESS readable. I now have to understand the semantics of a bunch of keywords specific to the macro, their order of operations within the macro, as well as recognizing the little ? on the end of the let as I'm scanning. I also have to see if that's a keyword or the start of another binding! :else nil? really? :is ... Geezus christ :when !?!?! Put down that nailgun, kid ;; This maintains the same logic (unless I fucked up transcoding) ;; and also the same err, complexity, in that forms are not exeuted if ;; they don't need to be, as your initial example, without nesting all ;; the way over to the side, or using some weird keyword language. (when-let [a foo] (let [b bar c (when (even? b) baz)] (when (and c (> b c)) (f a b c qux ;; or (when-let [a foo] (let [b bar c (when (even? b) baz) d (when (and c (> b c)) qux)] (when d (f a b c d Keep your constructs simple, and learn to love the nil. Also, people have been writing lisp for a real long time, and they haven't invented a chucklehead macro like let? yet, so prolly not really needed to improve the readability... -- Craig Brozefsky Premature reification is the root of all evil -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Craig Brozefsky writes: Hi Craig, > Also, people have been writing lisp for a real long time, and they > haven't invented a chucklehead macro like let? yet, so prolly not > really needed to improve the readability... They have invented `loop' and `format'. ;-) SCNR, Tassilo -- 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
Re: Can Clojure be as readable as Python or Ruby ?
I find let? useful and readable, as do others. There's a bit of brain- training necessary to read it, but not a lot. Probably no more than the keyword clauses of the "for" comprehension. The argument that decades of Lisp programmers haven't invented this particular "chucklehead" macro is a bit weak, since there have been many other similar macros. ...and I have learned to love nil, even the :else nil clause that repels you. - Evan On Mar 9, 9:26 am, Craig Brozefsky wrote: > Evan Gamble writes: > > (let? [a foo :else nil > > b bar :is even? > > c baz :when (> b c) > > d qux] > > (f a b c d)) > > Macros like that just make your code so much LESS readable. I now have > to understand the semantics of a bunch of keywords specific to the > macro, their order of operations within the macro, as well as > recognizing the little ? on the end of the let as I'm scanning. I also > have to see if that's a keyword or the start of another binding! > > :else nil? really? > > :is ... Geezus christ > > :when !?!?! Put down that nailgun, kid > > ;; This maintains the same logic (unless I fucked up transcoding) > ;; and also the same err, complexity, in that forms are not exeuted if > ;; they don't need to be, as your initial example, without nesting all > ;; the way over to the side, or using some weird keyword language. > > (when-let [a foo] > (let [b bar > c (when (even? b) baz)] > (when (and c (> b c)) > (f a b c qux > > ;; or > > (when-let [a foo] > (let [b bar > c (when (even? b) baz) > d (when (and c (> b c)) qux)] > (when d (f a b c d > > Keep your constructs simple, and learn to love the nil. > > Also, people have been writing lisp for a real long time, and they > haven't invented a chucklehead macro like let? yet, so prolly not really > needed to improve the readability... > > -- > Craig Brozefsky > Premature reification is the root of all evil -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Fri, 2012-03-09 at 10:04 -0800, Evan Gamble wrote: > I find let? useful and readable, as do others. There's a bit of brain- > training necessary to read it, but not a lot. Probably no more than > the keyword clauses of the "for" comprehension. The argument that > decades of Lisp programmers haven't invented this particular > "chucklehead" macro is a bit weak, since there have been many other > similar macros. > > ...and I have learned to love nil, even the :else nil clause that > repels you. There is a bit of brain-training necessary to read code with parens but not a lot. In fact, my editor can read paren code. The let? syntax breaks code walkers. The let? syntax breaks pretty printers. The let? syntax "complexes" read. See the loop package in Common Lisp. Some people swear by it, others swear at it. The idea isn't new. If you want "readable code" write a literate program. Literate programs communicate from person to person rather than having the person "decode" your idea from the code. If you understand the idea, any syntax is easy to read. Tim Daly -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Tassilo Horn writes: > Craig Brozefsky writes: > > Hi Craig, > >> Also, people have been writing lisp for a real long time, and they >> haven't invented a chucklehead macro like let? yet, so prolly not >> really needed to improve the readability... > > They have invented `loop' and `format'. ;-) Yah know, I was thinking of those as I wrote that, and I figured they actually would stand as supporting evidence for my quip 8^) -- Craig Brozefsky Premature reification is the root of all evil -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Well maybe the problem of the let? macro is that it is not standard. If you use standard constructs and I'am proeficient with clojure I'll understand your code fast. I'll concentrate on understanding your code relevant for your application and domain. But just adding a few new constructs specific to ypur libr can make code really complex to read, even to experimented clojurians. That the power of macros (or even functions). Abstract things away. But you also need to know the function/macro. And if it is not standard, we end up with many different version of let? depending of the library, author... By all means I'm not against let? macro or On 9 mar, 19:04, Evan Gamble wrote: > I find let? useful and readable, as do others. There's a bit of brain- > training necessary to read it, but not a lot. Probably no more than > the keyword clauses of the "for" comprehension. The argument that > decades of Lisp programmers haven't invented this particular > "chucklehead" macro is a bit weak, since there have been many other > similar macros. > > ...and I have learned to love nil, even the :else nil clause that > repels you. > > - Evan > > On Mar 9, 9:26 am, Craig Brozefsky wrote: > > > > > > > > > Evan Gamble writes: > > > (let? [a foo :else nil > > > b bar :is even? > > > c baz :when (> b c) > > > d qux] > > > (f a b c d)) > > > Macros like that just make your code so much LESS readable. I now have > > to understand the semantics of a bunch of keywords specific to the > > macro, their order of operations within the macro, as well as > > recognizing the little ? on the end of the let as I'm scanning. I also > > have to see if that's a keyword or the start of another binding! > > > :else nil? really? > > > :is ... Geezus christ > > > :when !?!?! Put down that nailgun, kid > > > ;; This maintains the same logic (unless I fucked up transcoding) > > ;; and also the same err, complexity, in that forms are not exeuted if > > ;; they don't need to be, as your initial example, without nesting all > > ;; the way over to the side, or using some weird keyword language. > > > (when-let [a foo] > > (let [b bar > > c (when (even? b) baz)] > > (when (and c (> b c)) > > (f a b c qux > > > ;; or > > > (when-let [a foo] > > (let [b bar > > c (when (even? b) baz) > > d (when (and c (> b c)) qux)] > > (when d (f a b c d > > > Keep your constructs simple, and learn to love the nil. > > > Also, people have been writing lisp for a real long time, and they > > haven't invented a chucklehead macro like let? yet, so prolly not really > > needed to improve the readability... > > > -- > > Craig Brozefsky > > Premature reification is the root of all evil -- 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
Re: Can Clojure be as readable as Python or Ruby ?
(Sorry for split post). So I'am not against let? macro of whatever you might need. That why we have a lisp here. But be sure you really need it/use it. And it is designed to be intuitive as possible. On 9 mar, 23:05, Nicolas wrote: > Well maybe the problem of the let? macro is that it is not standard. > If you use standard constructs and I'am proeficient with clojure I'll > understand your code fast. I'll concentrate on understanding your code > relevant for your application and domain. But just adding a few new > constructs specific to ypur libr can make code really complex to read, > even to experimented clojurians. > > That the power of macros (or even functions). Abstract things away. > But you also need to know the function/macro. And if it is not > standard, we end up with many different version of let? depending of > the library, author... > > By all means I'm not against let? macro or > > On 9 mar, 19:04, Evan Gamble wrote: > > > > > > > > > I find let? useful and readable, as do others. There's a bit of brain- > > training necessary to read it, but not a lot. Probably no more than > > the keyword clauses of the "for" comprehension. The argument that > > decades of Lisp programmers haven't invented this particular > > "chucklehead" macro is a bit weak, since there have been many other > > similar macros. > > > ...and I have learned to love nil, even the :else nil clause that > > repels you. > > > - Evan > > > On Mar 9, 9:26 am, Craig Brozefsky wrote: > > > > Evan Gamble writes: > > > > (let? [a foo :else nil > > > > b bar :is even? > > > > c baz :when (> b c) > > > > d qux] > > > > (f a b c d)) > > > > Macros like that just make your code so much LESS readable. I now have > > > to understand the semantics of a bunch of keywords specific to the > > > macro, their order of operations within the macro, as well as > > > recognizing the little ? on the end of the let as I'm scanning. I also > > > have to see if that's a keyword or the start of another binding! > > > > :else nil? really? > > > > :is ... Geezus christ > > > > :when !?!?! Put down that nailgun, kid > > > > ;; This maintains the same logic (unless I fucked up transcoding) > > > ;; and also the same err, complexity, in that forms are not exeuted if > > > ;; they don't need to be, as your initial example, without nesting all > > > ;; the way over to the side, or using some weird keyword language. > > > > (when-let [a foo] > > > (let [b bar > > > c (when (even? b) baz)] > > > (when (and c (> b c)) > > > (f a b c qux > > > > ;; or > > > > (when-let [a foo] > > > (let [b bar > > > c (when (even? b) baz) > > > d (when (and c (> b c)) qux)] > > > (when d (f a b c d > > > > Keep your constructs simple, and learn to love the nil. > > > > Also, people have been writing lisp for a real long time, and they > > > haven't invented a chucklehead macro like let? yet, so prolly not really > > > needed to improve the readability... > > > > -- > > > Craig Brozefsky > > > Premature reification is the root of all evil -- 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
Re: Can Clojure be as readable as Python or Ruby ?
The nice thing about Grand's cond macro is that it matches the syntax of using :let inside for comprehensions, so it looks just like other Clojure code. In fact, once you've tried it, it feels surprising that it's not already built into Clojure, specifically because it is so similar to binding with for comprehensions. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Evan Gamble writes: > I find let? useful and readable, as do others. There's a bit of brain- > training necessary to read it, but not a lot. Probably no more than > the keyword clauses of the "for" comprehension. The argument that > decades of Lisp programmers haven't invented this particular > "chucklehead" macro is a bit weak, since there have been many other > similar macros. Sure, you feel your defmacro, oats you write some ghetto macros with syntactically significant keywords, maybe stay up late a few nights expanding it into a some monstrosity and suddenly you have loop (I don't think CL's format is in the same realm actually). It works for you, you dig it, mazel tov. God knows I've written worse by far. > ...and I have learned to love nil, even the :else nil clause that > repels you. The idea of and explicit :else nil, in a situation where the negation of the logical operation is implicitely nil, just stinks in my nose. Seriously though, don't let my aesthetic griping stop you from rocking out whatever kinda clojure code tickles your brain. -- Craig Brozefsky Premature reification is the root of all evil -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Mar 9, 11:13 am, daly wrote: > There is a bit of brain-training necessary to read code with > parens but not a lot. In fact, my editor can read paren code. Hard to see what your point is there. I didn't write let? because I can't read code with parens. I've been writing Lisp since 1983, starting with Lisp Machines, before CL was designed. I have no difficulty reading highly parenthesized, nested code. I wrote let? to scratch a very specific itch. I often found myself writing what amounted to a series of let bindings, where some or all of the bindings had assertions associated with them that would stop further binding if the assertions failed. Conceptually, that pattern really feels like it should be a single let form, but in practice it has to be implemented with a bunch of nested lets, when-lets, if-lets, etc. So let? allowed me to write code for that pattern as the single let that it wanted to be. I wanted a single let form for that pattern for exactly the same reason that we have the convenient form: (let [a foo b bar] ...) instead of the less concise (let [a foo] (let [b bar] ...)) > > The let? syntax breaks code walkers. As does every other macro that the code walkers don't know about. Should that stop us from writing useful macros? If so, why do we have the macro facility? If every useful macro is already part of the language, should we even have defmacro? > The let? syntax breaks pretty printers. In emacs, you can make let? indent as let does by adding the following to your .emacs or .emacs.d/init.el: (define-clojure-indent (let? 1)) > The let? syntax "complexes" read. No idea what you mean by this. > > See the loop package in Common Lisp. > Some people swear by it, others swear at it. I've never liked the loop macro, because it felt like a crutch for people coming from imperative languages. > The idea isn't new. Not sure which idea you're referring to, but in any case I'm quite happy to admit that macros like let? have been written before. > > If you want "readable code" write a literate program. > Literate programs communicate from person to person rather > than having the person "decode" your idea from the code. > If you understand the idea, any syntax is easy to read. Love the preachy attitude. I find let? quite readable, and in fact it makes the specific pattern it's designed for clearer by making a single let form with clauses to handle the assertions and failure code. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On 03/08/2012 02:39 AM, Leon Talbot wrote: If so, how ? Syntax is a list of arbitrary rules made by a language designers. It's always possible to come up with a different (perhaps more compact, cleaner, more readable) syntax but: - that means creating a new incompatible language, - that would exactly zero new capabilities. Power of the language is defined by its semantics, not syntax. If I was going to design a new LISP language, I'd consider one of these two possibilities: 1. Getting rid of textual representation altogether and provide tools (editor, diff, patch etc) handling AST semi-graphically (think of the way spreadsheet editors handle 2D arrays). This breaks so many established conventions that it's unlikely at large scale. Yet, this is what LISP was originally supposed to be, and technical limitations that forced us to use textual representation are long gone. 2. Changing some of the arbitrary decisions LISP designers have made. Specifically, they have decided that a procedure application literal is simply a list: (proc arg1 arg2), which then forces us to use a constructor syntax for getting a list: (quote a b c) or '(a b c). This is a very clean and compact representation indeed but it makes it easy for the programmer to confuse a procedure application with a list. We could reverse this design decision and make the list literal denote a list: (a b c), and come up with an explicit literal form for an application. For example: .fun ; (apply fun) .fun (arg1 arg2 ...) ; (apply fun '(arg1 arg2 ...)) .fun arg ; (apply fun arg) (any use for that?) .fun {arg1 val1} ; (apply fun {arg1 val1}) (ditto) So instead of writing: (map + '(1 2 3) '(4 5 6)) we could have: .map (+ (1 2 3) (4 5 6)) A bit more complex example: (def fib-seq ((fn rfib [a b] (lazy-seq (cons a (rfib b (+ a b) 0 1)) could become: .def (fib-seq . .fn (rfib [a b] .lazy-seq (.cons (a .rfib (b .+ (a b) (0 1)) If we added one more "apply" literal: .(arg1 fun arg2) ; (apply fun '(arg1 arg2)) we could even write: .def (fib-seq . .fn (rfib [a b] .lazy-seq (.(a cons .rfib (b .(a + b) (0 1)) IMHO the result is both more explicit and more readable than the conventional LISP syntax (and yes, I'm using LISP long enough to be comfortable with its syntax). Is it worth implementing in an *existing* language? Nah..., maybe in some DSLs. Andrzej -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Mar 10, 12:19 am, Craig Brozefsky wrote: > Sure, you feel your defmacro, oats you write some ghetto macros with > syntactically significant keywords, maybe stay up late a few nights > expanding it into a some monstrosity and suddenly you have loop (I don't > think CL's format is in the same realm actually). It works for you, you > dig it, mazel tov. God knows I've written worse by far. let? is designed specifically to allow a series of let bindings with assertions to be combined into a single let form. I won't let it grow into a huge monstrosity, like loop. > > > ...and I have learned to love nil, even the :else nil clause that > > repels you. > > The idea of and explicit :else nil, in a situation where the negation of > the logical operation is implicitely nil, just stinks in my nose. In fact I'm not thrilled with the :else nil syntax, either, but I haven't thought of a simple alternative. Can't use a naked :else without the nil, because parsing would be ambiguous. > > Seriously though, don't let my aesthetic griping stop you from rocking > out whatever kinda clojure code tickles your brain. Rest assured, I won't. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
About item 1: The first Lisp I used was runing on a DEC-10 with 256k 36 bits words of physical memory (magnetic-core memory). It had a structural editor. We would change nodes, add/remove child nodes, ... Of course there were no WYSIWYG GUIs. The representation was all text base showing a tree shape view of your code. Navigation was a bit akward since it was 5 years before the mouse/windows concept came to market. I still wonder how it could fare compared to the text base approach we are used to these days. Maybe this is worth an attempt with the current processing power we have at hand and graphic aids that did not exists et the time. Item 2: >From what I recall, there were no such confusion in a structural editor. The >confusion could still be removed by using proper syntax highlights even in a text base editor. In any case, you would not want to change the underlying representation otherwise code that processes code would not work anymore or would become more complex to write. Luc P. > On 03/08/2012 02:39 AM, Leon Talbot wrote: > > If so, how ? > > Syntax is a list of arbitrary rules made by a language designers. It's > always possible to come up with a different (perhaps more compact, > cleaner, more readable) syntax but: > - that means creating a new incompatible language, > - that would exactly zero new capabilities. Power of the language is > defined by its semantics, not syntax. > > If I was going to design a new LISP language, I'd consider one of these > two possibilities: > > 1. Getting rid of textual representation altogether and provide tools > (editor, diff, patch etc) handling AST semi-graphically (think of the > way spreadsheet editors handle 2D arrays). This breaks so many > established conventions that it's unlikely at large scale. Yet, this is > what LISP was originally supposed to be, and technical limitations that > forced us to use textual representation are long gone. > > 2. Changing some of the arbitrary decisions LISP designers have made. > > Specifically, they have decided that a procedure application literal is > simply a list: (proc arg1 arg2), which then forces us to use a > constructor syntax for getting a list: (quote a b c) or '(a b c). This > is a very clean and compact representation indeed but it makes it easy > for the programmer to confuse a procedure application with a list. > > We could reverse this design decision and make the list literal denote a > list: (a b c), and come up with an explicit literal form for an > application. For example: > > .fun ; (apply fun) > .fun (arg1 arg2 ...) ; (apply fun '(arg1 arg2 ...)) > .fun arg ; (apply fun arg) (any use for that?) > .fun {arg1 val1} ; (apply fun {arg1 val1}) (ditto) > > So instead of writing: > > (map + '(1 2 3) '(4 5 6)) > > we could have: > > .map (+ (1 2 3) (4 5 6)) > > A bit more complex example: > > (def fib-seq >((fn rfib [a b] > (lazy-seq (cons a (rfib b (+ a b) > 0 1)) > > could become: > > .def >(fib-seq > . .fn (rfib [a b] >.lazy-seq (.cons (a .rfib (b .+ (a b) > (0 1)) > > If we added one more "apply" literal: > .(arg1 fun arg2) ; (apply fun '(arg1 arg2)) > we could even write: > > .def >(fib-seq > . .fn (rfib [a b] >.lazy-seq (.(a cons .rfib (b .(a + b) > (0 1)) > > IMHO the result is both more explicit and more readable than the > conventional LISP syntax (and yes, I'm using LISP long enough to be > comfortable with its syntax). Is it worth implementing in an *existing* > language? Nah..., maybe in some DSLs. > > Andrzej > > -- > 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 > -- Softaddicts sent by ibisMail! -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On 8 March 2012 16:23, Leon Talbot wrote: > What I met by readable, is the capacity of reading someone's code. I develop Ruby professionally, and write Clojure in my spare time. Off hand, I can think of several Ruby libraries I'd consider to have unreadable code, but no Clojure equivalents immediately spring to mind. Perhaps this is because there is a tendency for Ruby projects to become very "deep". The functionality for a single class is often scattered throughout several files of mixins and base classes. The New Relic Agent library (https://github.com/newrelic/rpm) is particularly bad in this regard. Clojure, on the other hand, tends to encourage libraries that are very shallow. Each namespace is contained in a single file, and holds a list of functions and values. You rarely get the sort of functionality spread that seems to occur in some large Ruby projects. So returning to your question: > Can Clojure be as readable as Python or Ruby? The answer is: probably, but why would we want to make Clojure less readable? - James -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Sun, Mar 11, 2012 at 2:56 AM, Softaddicts wrote: > About item 1: > > The first Lisp I used was runing on a DEC-10 with 256k 36 bits words of > physical > memory (magnetic-core memory). > It had a structural editor. We would change nodes, add/remove child nodes, ... Interesting. I thought it was only a planned feature, which has never got implemented. > I still wonder how it could fare compared to the text base approach we are > used > to these days. Maybe this is worth an attempt with the current processing > power > we have at hand and graphic aids that did not exists et the time. I think it could work rather well in an education-oriented environment or in DSLs. I don't think it would be interesting enough to flip mainstream software engineers on its side, unless it had an Apple badge on it. ;-) I'd rather like to see it working in practice - LISP is all about about using and manipulating ASTs, yet s-expressions are somewhat masking this feature (at least to newcomers, which tend to think of the LISP syntax as of a string of characters with some parentheses added to it). > Item 2: > > From what I recall, there were no such confusion in a structural editor. The > confusion > could still be removed by using proper syntax highlights even in a text base > editor. For a graphical/structural representation you'd likely need some sort of meta-data for annotating the source code (e.g. for layout and formatting). These data could then also be used for differentiating between procedure applications and list literals, even if their underlying structures were still the same. > In any case, you would not want to change the underlying representation > otherwise code that processes code would not work anymore or would become > more complex to write. Certainly not in an existing language, unless both representations were perfectly compatible, which is unlikely. As for the macros - that's a valid point. They would have to be redesigned to match against "(apply proc ...)" forms. I don't think that would have to be any more difficult than it is now, though. A new language would likely come with its own macro framework. Andrzej -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Mon, 2012-03-12 at 21:59 +0900, Andrzej wrote: > On Sun, Mar 11, 2012 at 2:56 AM, Softaddicts > wrote: > > About item 1: > > > > The first Lisp I used was runing on a DEC-10 with 256k 36 bits words of > > physical > > memory (magnetic-core memory). > > It had a structural editor. We would change nodes, add/remove child nodes, > > ... > > Interesting. I thought it was only a planned feature, which has never > got implemented. VMLisp on the IBM Mainframe also was a structure editor. (Mark Wegman, Martin Michaelson, Fred Blair) They were useful because the initial editors on small systems used sed-like commands to edit the text so you did "blind edits" (e.g. c/the/twe/ 200 lines changed). Think DOS edlin, TECO, etc. In my first 7 years of programming, the only way to see the text was to type it out but that was hugely wasteful of paper and something you rarely did so "editing" was done "in your head". Structure edits made sure that your edits were properly formed s-expressions. This helped a lot because you no longer had to keep a running count of parens in your head. > > > I still wonder how it could fare compared to the text base approach we are > > used > > to these days. Maybe this is worth an attempt with the current processing > > power > > we have at hand and graphic aids that did not exists et the time. Structure editors took up more memory. Since my big PDP 11/40 had 8k (including the OS), this was a trade-off. With a simple editor files could be up to 4k of text before the next char crashed the system. A more complex editor ate into the program size and caused an earlier crash due to memory being exhausted. > > I think it could work rather well in an education-oriented environment > or in DSLs. I don't think it would be interesting enough to flip > mainstream software engineers on its side, unless it had an Apple > badge on it. ;-) Emacs has paredit which allows s-expression level edits, see paredit-splice-sexp, paredit-forward-slurp-sexp, etc. The http://www.cliki.net/Editing%20Lisp%20Code%20with%20Emacs has examples. > > I'd rather like to see it working in practice - LISP is all about > about using and manipulating ASTs, yet s-expressions are somewhat > masking this feature (at least to newcomers, which tend to think of > the LISP syntax as of a string of characters with some parentheses > added to it). This leads to thinking about s-expressions as "wholes" where each s-expression at every level does something you could name. This tends to break down a bit as you get closer to the machine. However, at the DSL level structure edits are pretty clean. If you are at a level where you can think in "wholes" then a structure editor might be useful. The VMLisp editor tended to make you think on the syntax level and that is very distracting. You generally don't "see" the parens when writing code since lisp allows one to ignore all syntax issues. Other languages (e.g. C++) require random ';', '{', etc. which forces attention to syntax. Maybe that's why people like IDEs since they tend to provide auto-insertion of delimiters and motion by expression which is a kind of structure editing. Clojure brings back some syntax issues because binding contexts require [ ] pairs and other structured surface syntax protrudes into your attention. Would a Clojure structure editor tend to drift to an IDE? Wouldn't CCW qualify as a structure editor? I believe they have some of paredit's abilities: http://code.google.com/p/counterclockwise Tim Daly -- 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