3 ms·

> You could say "paragraphs and punctuation only guide your eyes, but to know what the text says you have to read it, there's no other way around" - ancient gre

> You could say "paragraphs and punctuation only guide your eyes, but to know what the text says you have to read it, there's no other way around" - ancient greek was written without word spaces, it barely introduces any ambiguity. I'm not sure to understand. But I fully endorsed your paragraph statement up to but not beyond the remark that a parenthesis is a punctuation. I was not suggesting we don't need some kind of punctuation or blank lines in code. I was pointing out Lisp dialects are proof you can basically code with just three signs of punctuations: newlines, left parenthesis and right parenthesis. Are we also clear on the fact every programmer knows how to program in Lisp, even if they didn't even program in it? It's just like function calls, except for the whole language. Really. There's no need to write Lisp code a lot. It is enough to take a few steps back, consider the whole picture and see it for what it is. Lisp is chainable action perimeters. And that's very easy because it is just like function calls in C, Java, Javascript or many other, more mainstream languages. If you know one of them - and I bet that's the case - then congrats, you can program in Lisp! Whether you choose to do so or not, you're the judge of course and either way is fine with me. But don't say reading or understanding Lisp is hard because for that you only have to learn the vocabulary, as is the case for every programming language. Anyway, thank you very much for the pointer to SRFI 49! I have searched a bit about indenting Lisp code but never found something that detailed. I'm sorry for the absurdly fine-grain of my stats. It's just that I have my own Lisp code parser for that and it includes inner comments and blank lines. So it's really that precise but I was silly to recopy these numbers without thinking about the issue. My point was to say they are consistently that low. And for some languages, it's clearly not the case. But from the few codes of Python I have read and given your own stats, it feels like Python is very consistent. And in my eyes that's definitely a very good thing. > "Ultimately "no, this language is more awesomer" gets nowhere, I think. You're clearly passionate about Lisp and think it is the best." I just read again my comment and it can so be read like that... I should have been more careful. I'm truly sorry to have almost versed into a flame debate. But to read my comment in the direction that Lisp is more awesome or simply the best is to amplify too much my claim which was relative to a precise issue: the needed amount of lines of code against the complexity of the problem. I really said nothing more than Lisp has an edge there and I think the examples give an idea of complex problems: parsing code to get a precise line count or to identify dependencies or to even execute automatically step-by-step the code, these are surely complex tasks. At least it is for me and I can't imagine coding it in other languages than Lisp. Because of their very syntax.

sago 12y ago
Thanks for the response. > I was pointing out Lisp dialects are proof you can basically code with just three signs of punctuations: newlines [I think you meant whitespace generally], left parenthesis and right parenthesis. I agree. In fact, with SRFI49, you can do it with just newlines and spaces. My point is that you can write prose with just spaces, periods and capital letters too (or less). But the use of parentheses, dashes, colons, semicolons, question and exclamation marks, quotation marks, and ellipses, is not a bug. See the metaphor I'm getting at? > Are we also clear on the fact every programmer knows how to program in Lisp Yes, if by 'program in Lisp' you mean 'program in a lisp-like syntax'. I tend to think that syntax is a rather superficial thing, compared to learning the model of computation and the runtime environment. Then Lisp is quite different from C, say. A C programmer doesn't already know Lisp. One problem I had with the OP was that: it seemed to suggest the syntax 'was' Lisp. I think Python in Lisp syntax would be more Python than Lisp, personally.
- thomaskrauss 12y ago
  Okay, I understand better your point. (I have also misunderstood SRFI49 so it didn't help!). The things you described are features, right? But what is OP? Opening paragraph? > compared to learning the model of computation and the runtime environment There is indeed more important things to learn than syntax. The thing is, for Lisp, chainable action perimeters not only covers the syntax, it also covers the model of computation itself. The basic one at least, without macros and any object system. Still, that basic one is quite broad. On that question you actually anticipate another article I wanted to share: shortcomings of instructions. It's only logical. If in Lisp dialects the atom is the chainable action perimeter, what other languages have? The answer is the instruction and well, I will keep that for next week but you can read it if you want. The URL is http://www.vagrant-coder.com/articles/english/Shortcomings-of-instructions.html http://www.vagrant-coder.com/articles/english/Shortcomings-o...
  - sago 12y ago
    > The things you described are features, right? Right, they provide additional structure that can in turn help someone express themselves. But you're right, the complexity can obscure some underlying simplicity. I suspect that the solution is to disentangle the two: to help programmers understand the computational model independent of the language. > it also covers the model of computation itself eval/apply is what I'd consider the model of Lisps, rather than chainable action perimeters. The two are linked, of course, former depending on the latter. I guess you probably mean roughly the same thing by it, so I'm not disagreeing, just saying what I was thinking of. I agree, the von Neumann model of computation is not necessarily useful if programmers believe it is the only model. But I think it is crucial for programmers to understand. OP = original post (i.e. the article on your site).

sago 12y ago

Thanks for the response. > I was pointing out Lisp dialects are proof you can basically code with just three signs of punctuations: newlines [I think you meant whitespace generally], left parenthesis and right parenthesis. I agree. In fact, with SRFI49, you can do it with just newlines and spaces. My point is that you can write prose with just spaces, periods and capital letters too (or less). But the use of parentheses, dashes, colons, semicolons, question and exclamation marks, quotation marks, and ellipses, is not a bug. See the metaphor I'm getting at? > Are we also clear on the fact every programmer knows how to program in Lisp Yes, if by 'program in Lisp' you mean 'program in a lisp-like syntax'. I tend to think that syntax is a rather superficial thing, compared to learning the model of computation and the runtime environment. Then Lisp is quite different from C, say. A C programmer doesn't already know Lisp. One problem I had with the OP was that: it seemed to suggest the syntax 'was' Lisp. I think Python in Lisp syntax would be more Python than Lisp, personally.

thomaskrauss 12y ago
Okay, I understand better your point. (I have also misunderstood SRFI49 so it didn't help!). The things you described are features, right? But what is OP? Opening paragraph? > compared to learning the model of computation and the runtime environment There is indeed more important things to learn than syntax. The thing is, for Lisp, chainable action perimeters not only covers the syntax, it also covers the model of computation itself. The basic one at least, without macros and any object system. Still, that basic one is quite broad. On that question you actually anticipate another article I wanted to share: shortcomings of instructions. It's only logical. If in Lisp dialects the atom is the chainable action perimeter, what other languages have? The answer is the instruction and well, I will keep that for next week but you can read it if you want. The URL is http://www.vagrant-coder.com/articles/english/Shortcomings-of-instructions.html http://www.vagrant-coder.com/articles/english/Shortcomings-o...
- sago 12y ago
  > The things you described are features, right? Right, they provide additional structure that can in turn help someone express themselves. But you're right, the complexity can obscure some underlying simplicity. I suspect that the solution is to disentangle the two: to help programmers understand the computational model independent of the language. > it also covers the model of computation itself eval/apply is what I'd consider the model of Lisps, rather than chainable action perimeters. The two are linked, of course, former depending on the latter. I guess you probably mean roughly the same thing by it, so I'm not disagreeing, just saying what I was thinking of. I agree, the von Neumann model of computation is not necessarily useful if programmers believe it is the only model. But I think it is crucial for programmers to understand. OP = original post (i.e. the article on your site).