Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 8/6/2020 2:39 PM, Akkana Peck wrote: Christian Seberino writes: Python is my favorite language and the easiest to use in my opinion. Lisp has a far simpler grammar and syntax. A beginner I think could learn Lisp much faster than Python. Therefore, it seems like Lisp *should* be easier to work with and more readable. I don't feel like it is easier to use but I can't see *why* that is. First, everybody's brain is different so be cautious of sweeping statements. What's true for one person isn't necessarily true for another. That said, for me, Lisp's simpler syntax arises from the fact that there's basically one data structure: a list. In general, the one data structure is a tree*, skewed by being smashed into a linked list. Replaced 'list' with 'skewed tree' in what you say below, and I think you explain well the problem many have with thinking in Lisp. * One can think of a flat list of n items as being a one level n-ary tree with a head node and n leafs. A linked list is a skewed binary tree. To do anything in Lisp, you have to think in lists, map everything to lists (including the program's own structure), build up list-based data structures in your head. It's also functional and recursive, which means that as you're programming, you have to maintain a stack (which is also a list) in your head of all the lists that aren't yet closed. Of course, you can use tricks like let and setq to hold intermediate variables and mitigate that a little, but that isn't really Lispish. Trying to maintain that recursive list of unclosed lists in your brain is fun. It stretches the brain in interesting ways. I was way into Lisp at one point, including writing several Lisp interpreters (that simple structure makes Lisp very easy to implement). But I never found Lisp code very maintainable, because any time you read a program, you have to build up that list in your head every time just to follow the logic structure and figure out what the return value will be. I suspect most people find that more difficult than reading an inherently procedural language like Python. I know I do. Stephen Wolfram's Mathematica is also based on the idea that 'everything is a symbolic expression'. With a somewhat more standard syntax, it found a sufficiently substantial audience to be a commercial success. It obviously fit *his* brain well enough that he was able to do a hugh number of different computations for his 2002 book A New Kind of Science. It fits me less well. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 8/6/2020 11:13 AM, Christian Seberino wrote: Python is my favorite language and the easiest to use in my opinion. Lisp has a far simpler grammar and syntax. A beginner I think could learn Lisp much faster than Python. Therefore, it seems like Lisp *should* be easier to work with and more readable. I don't feel like it is easier to use but I can't see *why* that is. My best guess. Lisp pros: simpler syntax Lisp cons: prefix notation, lots more parentheses My hypothesis is that the cons slightly outweigh the pros of Lisp which is why Python is easier to work with and is more readable in the end? Here is why *I* prefer Python. 1. Python mostly separates computation of values (expressions) from flow control and name binding (statements). When the latter are mixed with the former, most people restrict the mixing to a line or two. 2. Lisp code is one dimensional (though I presume there are now formatting conventions). Python makes direct use of two dimensional structuring. 3. Forcing everything into linked lists is 'cute', but it introduces irrelevant asymmetries, differential nesting, and boilerplate that obscures the problem relevant structure. A list of equal status items: (1,2,3) versus (1 (2 (3 NIL))) A complete binary tree of depth 2: ((LL, LR), (RL, RR)) Left and right branches have same form. versus # ((LL, (LR, NIL)), ((RL, (RR, NIL)), NIL)) ((LL (LR NIL)) ((RL (RR NIL)) NIL)) Left and right branches have different forms. I think I got the Lisp version right, but I had to initially include commas to do so. Anyway, the Python version was much easier to write and is much easier to read. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Are instances of user-defined classes mutable?
On 8/6/20 8:53 PM, ZHAOWANCHENG wrote: > So instances of user-defined classes are immutable by default? No, they're clealry mutable. > Or the description of "if a tuple contains any mutable object either directly > or indirectly, it cannot be used as a key." in the document is not > completely correct? It's correct, but is not relevant to your case, as you're asking about an object different than a tuple. When defining a class, you get by default a hash that is consistent, no matter what you do to the contents of an instance, so instances are eligible to be used as dict keys. You can define the class in a way that instances cannot be used as keys, by ensuring there is no hash function. -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
> If "the Python way" seems simpler to you than "the Lisp way," > or iteration seems simpler to you than recursion, then so be it. Other > languages and other programmers are different. I think this is so true. I've had similar conversations with Lisp fans and it has confused me at times why they don't see the wonderfulness of Python like I do. As you said, everyone's brain isn't the same. Just have to remember that and accept it. cs -- https://mail.python.org/mailman/listinfo/python-list
Re: Are instances of user-defined classes mutable?
On 8/6/20 10:53 PM, ZHAOWANCHENG wrote:
> So instances of user-defined classes are immutable by default?
> Or the description of "if a tuple contains any mutable object either
> directly or indirectly, it cannot be used as a key." in the document
> is not completely correct?
> The description mentioned above comes from here:
> https://docs.python.org/3/tutorial/datastructures.html#dictionaries
My answer was pointing out in a very abstract sense, it is perhaps
tricky to define what is 'mutability' for a class as it affects its use
in a dictionary.
The key here is to ask what does using a class as a key (or part of a
key with a tuple) means.
You build the dictionary, use a key value, and then you can look up that
entry by passing an equal value key, and it will find the term.
So we need to look at what it means for class objects to be equal, and
the default for that checks for equality of the id(), not any of the
members.
This means that doing something like:
a = myclass(10)
b = myclass(10)
d = { a: 1}
trying to do a
d[b] will throw a KeyError exception, as there is no item in the dict
with that key.
and if we ask a == b we get false (even though all their values match)
This comes to the point that, for a class with the default equality
operator, so equality is identity, do changing a member of a class
object REALLY mutate the object as far as the dictionary is concerned?
Changing the member value does NOT change what the key represents.
Note also, once you define the equality testing function __eq__, then
python makes the class non-hashable (unless you also define a __hash__
function) so a class like that can't be used as a part of a key in a
dictionary, because it now has the ability to 'change' the value it
represents.
Going back to the original issue. A tuple can normally be used as a
dictionary key (but a list can not) because it can build its hash as a
combination of the hash for all its elements (as long as they are
hashable, and the 'immutable' objects are) and thus be usable as a key.
Since a list, unlike a tuple, allows you to mutate the sequence by
modifying the list, it can't provide the unchangable hash by the same
method.
When you put a class object into the tuple, as long as it still has it
__hash__ member, because you haven't defined a __eq__ member, is at
least to the tuple, immutable, as the only part of it that matters is
the value of id() which WILL be unchanging.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
> ChrisA You're definitely an expert programmer. -- https://mail.python.org/mailman/listinfo/python-list
Re: Explicit is better than Implicit
On Thu, Aug 06, 2020 at 07:46:25PM -0500, Python wrote: > On Thu, Aug 06, 2020 at 07:19:01PM -0500, Skip Montanaro wrote: > Python is *actually* easy to work with... most of the time. "If you > want more things for you buck there's no luck..." =8^) [And yes, I'm aware the line is "beats" not "things" but since Python usually doesn't have "beats" (though it can!) I paraphrased a bit...] -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Sat, Aug 8, 2020 at 1:06 AM Christian Seberino wrote: > > > > ChrisA > > You're definitely an expert programmer. > Uhh thank you? I think? I'm not sure if you're complimenting me or making some sort of joke relating to the code I posted, or if it's actually nothing to do with me at all. All you quoted - the only context we have - is my scribbled signature at the bottom of the post. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
> 1. Python mostly separates computation of values (expressions) from flow > control and name binding (statements). When the latter are mixed with > the former, most people restrict the mixing to a line or two. This is an interesting observation. I've heard people say the fact that Python has both expressions and statements is a negative. (Lisp only has expressions.) It isn't clear to me what special Python syntax or forms you are referring to that separates expressions from flow control and assignments. -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Fri, Aug 07, 2020 at 04:23:42PM +1000, Chris Angelico wrote: > On Fri, Aug 7, 2020 at 11:11 AM Python wrote: > > Pretty straightforward. Now try yourself to write the iterative > > version. > > It might look slightly better to a mathematician, but it's so > abysmally inefficient (unless you add extra layers of indirection) > that it's not really a good example. Yes, I did say more or less that... but efficiency was not the point. Understanding was the point. > The iterative version seeds the algorithm and lets it run: Sure Chris, I fully expected YOU to get this on the first try, but the average programmer tends not to. My team uses it as an interview question fairly often, and I'd venture a guess that upward of 80% of candidates get it wrong on their first try. The recursive version is typically much easier to understand intuitively, not just for mathemeticians, because it more or less restates in simple, straightforward code what the natural language definition of the Fibonacci sequence is, rather efficiently (not efficiency of execution, efficiency of converting natural language to code). The iterative version requires a bit more thought to make sure you're seeding the state poperly, and maintaining it properly as the loop executes. I'd imagine most folks who hang around in this forum would consider that you are not an average programmer. Your example was also a fine example. -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Sat, Aug 8, 2020 at 1:38 AM Python wrote:
>
> On Fri, Aug 07, 2020 at 04:23:42PM +1000, Chris Angelico wrote:
> > On Fri, Aug 7, 2020 at 11:11 AM Python wrote:
> > > Pretty straightforward. Now try yourself to write the iterative
> > > version.
> >
> > It might look slightly better to a mathematician, but it's so
> > abysmally inefficient (unless you add extra layers of indirection)
> > that it's not really a good example.
>
> Yes, I did say more or less that... but efficiency was not the point.
> Understanding was the point.
>
> > The iterative version seeds the algorithm and lets it run:
>
> Sure Chris, I fully expected YOU to get this on the first try, but the
> average programmer tends not to. My team uses it as an interview
> question fairly often, and I'd venture a guess that upward of 80% of
> candidates get it wrong on their first try. The recursive version
> is typically much easier to understand intuitively, not just for
> mathemeticians, because it more or less restates in simple,
> straightforward code what the natural language definition of the
> Fibonacci sequence is, rather efficiently (not efficiency of
> execution, efficiency of converting natural language to code).
>
My point is that doing Fibonacci recursively is arguably more elegant
while being materially worse at performance, but there are other
examples that are fundamentally recursive, are just as elegant (merge
sort: "fracture the array in half, sort each half, then merge them"),
and can't be done better iteratively. So IMO Fibonacci is a flawed
demonstration of what is a very valid point ("recursion can be really
elegant"), and other examples would serve the purpose better.
TBH most people won't get the recursive version right the first time
either. And that's not a problem. I actually didn't get the iterative
version perfect right away (had an off-by-one on the loop counter),
and tested it before posting. Every student I've worked with has had
the same thing - something doesn't work the first time, even with the
most brilliant students - so they test, they debug, and then they
refine their code. I'm not some sort of coding deity that gets things
right the first time; the medium of email lets me hide the
testing/debugging step and just post working code :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Fri, 7 Aug 2020 at 17:14, Christian Seberino wrote:
> This is an interesting observation. I've heard people say the fact that
> Python has both expressions and statements is a negative. (Lisp only
> has expressions.)
Commonly, in imperative languages like C, you can write
if (a = b) {...}
This is allowed in C, even if a = b is not an expression, but an
assignment statement. 99% of times you simply wrong and wanted:
if (a == b)
Python separates statements and expressions, so where you expect an
expression, you can't write a statement.
Maybe Lisp does not separate expressions and statements because it
supports both functional and imperative programming, while Python is
mainly an imperative language with some functional features. Not sure
about this, since I never used any Lisp dialect and I've not yet used
function programming in the real world.
PS: Recently there's an exception: if you *really* want an assignment
when an expression is expected, you can use the "walrus" := operator.
IMO it renders the code less readable and I'm not sure about it's
usefulness.
@Chris: note that "real" recursion in Python is not possible, since
there's no support for tail recursion. Maybe something similar can be
done using async functions.
--
https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
Am 06.08.20 um 17:13 schrieb Christian Seberino:
Python is my favorite language and the easiest to use in my opinion.
Lisp has a far simpler grammar and syntax. A beginner I think could
learn Lisp much faster than Python.
Therefore, it seems like Lisp *should* be easier to work with and more
readable. I don't feel like it is easier to use but I can't see *why* that is.
My best guess.
Lisp pros: simpler syntax
Lisp cons: prefix notation, lots more parentheses
My hypothesis is that the cons slightly outweigh the pros of Lisp
which is why Python is easier to work with and is more readable in
the end?
I concur with Chris Angelico there. The word "simple" is ambiguous.
"Simpler" for the human is not the same as "simpler" for the computer
In Lisp, the grammar is "simpler", meaining that the definition of the
grammar is shorter; this makes it simpler for the compiler to parse, and
to write a compiler for Lisp.
In Python, the grammar is very complicated, writing a compiler for
Python is a big task - still it is "simpler" to translate your ideas
into Python
It is related to the old saying "if all you have is hammer, then
everything looks like a nail". In Lisp, your hammer is the list. So you
are forced to map your problems onto list processing. For some things
that works well, for others not so well (infix math) .
In, say, Java, your tool is classes and inheritance. There are big books
on "design patterns" that teach you how to map your problem onto
inheritance. For some things, that works well, for others not so well
("abstract factory", "visitor pattern", )
In Python, you have an awfully complex of syntax, so your toolset
includes list processing, lambda, inheritance, string interpolation,
decorators
This makes it possible to use the tool which best matches the language
of your problem. Many problem domains have their own language, e.g.
matrix math for linear algebra, pipes for sequential stream processing
etc. The easier it is to translate the algorithm on paper into the
runnable version, the
Lisp is still impressive, because it is very good at metaprogramming. It
shows how far you can get with so little syntax.
Another point to consider is the ecosystem of your language. If you
install Python, then you get basic math, I/O, a GUI toolkit, network
libraries, ... In more "traditional" languages like C or Lisp, you get
math and I/O, period. For everything else you need to hunt down a
library. Therefore, solve the task "download the gimp installer from
github via https" requires 2,3 lines in Python and installing a
(possibly complex) library for the same task in Lisp or C.
Christian
--
https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
I wrote: > > > Trying to maintain that recursive list of unclosed lists in your > > > brain is fun. It stretches the brain in interesting ways. > > > [ ... ] But I never found Lisp code very maintainable, [ ... ] [email protected] writes: > "[R]ecursive list of unclosed lists"? Can you (whoever you are) expand > on that? Yes, if you eschew helper functions and local variables, then > you can end up with depply nested code, but that's true in any language. To pick a function that I know is readily available in lots of languages, let's look at a couple implementations of the Haversine function (from http://rosettacode.org/wiki/Haversine_formula). Comments to illustrate language differences are mine. Here's the Common Lisp version. (defparameter *earth-radius* 6372.8) (defparameter *rad-conv* (/ pi 180)) ;; Minor complication right off: assignment of variables or constants ;; is completely different depending on whether you're ;; defining something in general, like here, or only for ;; a subsequent clause, like the let* functions later on. (defun deg->rad (x) (* x *rad-conv*)) ;; Prefix notation for arithmatic is unfamiliar to most people ;; since that's not what we learn in school, so that's a first ;; hurdle for readability. (defun haversine (x) (expt (sin (/ x 2)) 2)) ;; To grok this function you need to have four levels of ;; parentheses simultaneously open in your head. (defun dist-rad (lat1 lng1 lat2 lng2) (let* ((hlat (haversine (- lat2 lat1))) ;; Then there's the let vs. let* issue, ;; no big deal for experienced programmers ;; but not entirely easy to explain to a beginner. ;; On the other hand, Python has its own confusing points on ;; that issue, like when you need to specify "global". (hlng (haversine (- lng2 lng1))) (root (sqrt (+ hlat (* (cos lat1) (cos lat2) hlng) ;; for that expression you need 7 levels of mental parens open (* 2 *earth-radius* (asin root (defun dist-deg (lat1 lng1 lat2 lng2) (dist-rad (deg->rad lat1) (deg->rad lng1) (deg->rad lat2) (deg->rad lng2))) ;; End Lisp example Seven levels of unclosed lists that you need to keep in your head in order to read and understand the program at its deepest point. Here's the same thing in Python: from math import radians, sin, cos, sqrt, asin def haversine(lat1, lon1, lat2, lon2): R = 6372.8 # Earth radius in kilometers dLat = radians(lat2 - lat1) dLon = radians(lon2 - lon1) lat1 = radians(lat1) lat2 = radians(lat2) a = sin(dLat / 2)**2 + cos(lat1) * cos(lat2) * sin(dLon / 2)**2 c = 2 * asin(sqrt(a)) return R * c # end Python example The equation is still the same equation, but it looks a lot more like the equation you'd see in a math textbook, or write on a homework assignment, modulo notational issues like ** instead of superscripts. The deepest level of parentheses you ever need to keep in your head is two, but the second level is just a very simple function call, sqrt(a). The indentation level (the program structure) never gets beyond one. On the other hand, your brain does need to keep track of more intermediate variables (dLat, dLon etc.) Perhaps some people might find that harder. And yes, you could write the Lisp to look more like the Python or vice versa. You're welcome to try that, but I predict you'll find that even if you use the same number of intermediate variables, Lisp will always require you to keep that larger mental stack of open parens. > Because of Lisp's simple syntax, text editors can nearly completely > relieve the programmer from the tedium of indenting and formatting, and > even closing parenthesis, which also highlights missing/extra/unbalanced > parentheses pretty quickly. I find that emacs mostly does a pretty good job of figuring out indentation, closing parentheses, highlighting syntax errors and similar boilerplate in Python. Maybe you need a smarter text editor? But my comment about levels of parens had nothing to do with editors. To understand the code, you need to build up that list/tree structure in your head, because that's what defines the program logic. Again, my point isn't that Python is a better or simpler language than Lisp. It's that it stretches the brain in different ways, and that I would guess (but it's just a guess) that most beginners will find the Python approach more intuitive and easier to learn, since it emphasizes things they've done before (simple declarative statements, equations written out in a familiar way) rather than new and unfamiliar concepts (prefix notation, deeply nested parentheses, tree structures). ...Akkana -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 2020-08-07 at 17:55:45 +0200,
Marco Sulla wrote:
> On Fri, 7 Aug 2020 at 17:14, Christian Seberino wrote:
> Commonly, in imperative languages like C, you can write
>
> if (a = b) {...}
>
> This is allowed in C, even if a = b is not an expression ...
In C, a = b *is* an expression. An assignment expression that uses the
assignment operator. See
.
> ... 99% of times you simply wrong and wanted:
> if (a == b)
Where did 99% come from?
> Python separates statements and expressions, so where you expect an
> expression, you can't write a statement.
Yes.
> Maybe Lisp does not separate expressions and statements because it
> supports both functional and imperative programming ...
It's not a matter of separating expressions from statements. Lisp
doesn't have statements. It only has expressions. If you choose to
write imperative code in Lisp, all you're really doing is using the
expressions for their side effects rather than their values.
> PS: Recently there's an exception: if you *really* want an assignment
> when an expression is expected, you can use the "walrus" := operator.
> IMO it renders the code less readable and I'm not sure about it's
> usefulness.
It makes some code more concise. Readability is in the eye of the
beholder.
> @Chris: note that "real" recursion in Python is not possible, since
> there's no support for tail recursion. Maybe something similar can be
> done using async functions.
Python has real recursion. Whether or not there's tail recursion on the
inside is an implementation detail.
--
https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 8/7/20 11:55 AM, Marco Sulla wrote:
> Commonly, in imperative languages like C, you can write
>
> if (a = b) {...}
>
> This is allowed in C, even if a = b is not an expression, but an
> assignment statement. 99% of times you simply wrong and wanted:
But in C (and related languages) it IS an expression, and C doesn't have
an 'assignment statement' but an 'expression statement', which is the
source of the issue. = is just another operator, which happens to modify
the value of its left operand.
Python makes assignment a full top level type of statement, so = can't
be misused in an expression thinking it means an equality test (and then
added recently the := operator, so that for the cases you actually want
to do assignments in the middle of an expression you can).
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 8/7/20 11:46 AM, Chris Angelico wrote:
> My point is that doing Fibonacci recursively is arguably more elegant
> while being materially worse at performance, but there are other
> examples that are fundamentally recursive, are just as elegant (merge
> sort: "fracture the array in half, sort each half, then merge them"),
> and can't be done better iteratively. So IMO Fibonacci is a flawed
> demonstration of what is a very valid point ("recursion can be really
> elegant"), and other examples would serve the purpose better.
I would say that doing the recursive Fibonacci version can be an
important step (near the end) of the recursion unit as a learning
experience on some of the dangers of recursion (like turning an O(N)
problem into O(2**N). It perhaps can lead to discussions on optimization
techniques (like caching results) that can alleviate some of the issues
(at other costs).
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Sat, Aug 8, 2020 at 2:21 AM <[email protected]> wrote: > > On 2020-08-07 at 17:55:45 +0200, > Marco Sulla wrote: > > @Chris: note that "real" recursion in Python is not possible, since > > there's no support for tail recursion. Maybe something similar can be > > done using async functions. > > Python has real recursion. Whether or not there's tail recursion on the > inside is an implementation detail. More specifically: Python has real recursion. Whether or not tail recursion is optimized away is an implementation detail. Tail call optimization (there's no reason to restrict it to recursion alone) is something a Python implementation could choose to do, but the trouble is that full optimization tends to destroy traceback information, so it's often not worth doing. And the cases where partial optimization is of value just aren't compelling enough for anyone to implement it into CPython, nor any other major implementation (to my knowledge). The biggest uses for TCO tend to be the situations where recursion is the wrong solution to the problem. But recursion? Recursion is definitely possible. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Sat, Aug 8, 2020 at 2:44 AM Richard Damon wrote:
>
> On 8/7/20 11:46 AM, Chris Angelico wrote:
> > My point is that doing Fibonacci recursively is arguably more elegant
> > while being materially worse at performance, but there are other
> > examples that are fundamentally recursive, are just as elegant (merge
> > sort: "fracture the array in half, sort each half, then merge them"),
> > and can't be done better iteratively. So IMO Fibonacci is a flawed
> > demonstration of what is a very valid point ("recursion can be really
> > elegant"), and other examples would serve the purpose better.
>
> I would say that doing the recursive Fibonacci version can be an
> important step (near the end) of the recursion unit as a learning
> experience on some of the dangers of recursion (like turning an O(N)
> problem into O(2**N). It perhaps can lead to discussions on optimization
> techniques (like caching results) that can alleviate some of the issues
> (at other costs).
Yes, I'd definitely agree. It's great to have some demonstrations of
the advantages and disadvantages of recursion, and Fibonacci offers
both in one tidy package :)
Here's another really great example: triangle numbers.
def tri(n):
if n < 1: return 0
return n + tri(n - 1)
def tri(n):
tot = n
for i in range(n):
tot += i
return tot
def tri(n):
return functools.reduce(operator.add, range(n + 1))
def tri(n):
return n * (n + 1) // 2
A great demo of different ways to think about the same problem, with a
nice O(1) reference at the end that you can validate them against :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
About statement vs expression: maybe you, Richard and 2QdxY4RzWzUUiLuE, are right, maybe not. This is hard to say, since the official C documentation is not public and you have to pay a small fee to obtain it. Anyway, I said "in C, the assignment is a statement that can be used in expression". You're saying "No, in C the assignment IS an expression". I don't see the difference. If the assignment is a statement that can be used as an expression, Python simply forbids that. If in C the assignment is an expression, Python on the contrary treats it as a statement. The only real difference is that Python not only clearly separated the concepts of statement and expression, but also _where_ you can use them, for practical reasons. -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Fri, 7 Aug 2020 at 18:48, Chris Angelico wrote: > Tail call optimization (there's no reason to restrict it to recursion > alone) is something a Python implementation could choose to do, but > the trouble is that full optimization tends to destroy traceback > information Indeed this is implemented in asyncio. -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
Your iterative fib(x) code and comment was quite nice. -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
> Another point to consider is the ecosystem of your language. If you > install Python, then you get basic math, I/O, a GUI toolkit, network > libraries, ... In more "traditional" languages like C or Lisp, you get > math and I/O, period. For everything else you need to hunt down a > library. Therefore, solve the task "download the gimp installer from > github via https" requires 2,3 lines in Python and installing a > (possibly complex) library for the same task in Lisp or C. > > Christian I like this post so much I printed it. It seems you're saying Python has lots of syntax forms or "mini-languages" in it and *that* is a big reason why you can typically find syntax that makes an arbitrary problem more readable in Python. On the other hand, Lisp tries to everything with less syntax forms (paradigms) and hence it is less readable. A Lisp person would probably say that they can create domain specific languages (DSLs) for whatever they wish. However, many people like that Python has so many standardized "DSLs" ready to go for you from the start. I think this is really significant point why more syntax does necessarily mean less readability. I would just add that Clojure finally solved the ecosystem problem with Lisp by giving it access to the Java libraries. cs -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 8/7/20 12:52 PM, Marco Sulla wrote: > About statement vs expression: maybe you, Richard and > 2QdxY4RzWzUUiLuE, are right, maybe not. This is hard to say, since the > official C documentation is not public and you have to pay a small fee > to obtain it. > > Anyway, I said "in C, the assignment is a statement that can be used > in expression". You're saying "No, in C the assignment IS an > expression". > I don't see the difference. If the assignment is a statement that can > be used as an expression, Python simply forbids that. If in C the > assignment is an expression, Python on the contrary treats it as a > statement. > > The only real difference is that Python not only clearly separated the > concepts of statement and expression, but also _where_ you can use > them, for practical reasons. The difference is that the two languages define 'expression' differently. In Python, the = operation is not part of the general expression syntax, but is specifically allowed only in specific locations. In C, the = operator is exactly like all the other operators in how it is parsed, it just has some restrictions on the type that can be on the left side, and that it changes that value (but then, so do a few other operators like ++) In C, there is NO 'statement' called an assignment statement, because assignments are just parts of expressions, so the statement type 'expression statement' handles both. In Python, because assignment is NOT just part of an expression, it needs a separate statement type to handle assignments, to allow them. (BTW, while the official C Standards are only available at a price, the draft standards prepared during the development of the final are all available for free and the last published draft standard is almost always virtually identical to the final released standard, so most people will just use those. People who really need the official versions can pay the price for it, and for them, that price isn't that high to them). I keep the free downloads of all the major version of the C and C++ language available on my computer. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 2020-08-07 at 10:00:25 -0600, Akkana Peck wrote: > I wrote: > > > > Trying to maintain that recursive list of unclosed lists in your > > > > brain is fun. It stretches the brain in interesting ways. > > > > [ ... ] But I never found Lisp code very maintainable, [ ... ] > > [email protected] writes: > > "[R]ecursive list of unclosed lists"? Can you (whoever you are) expand > > on that? Yes, if you eschew helper functions and local variables, then > > you can end up with depply nested code, but that's true in any language. > > To pick a function that I know is readily available in lots > of languages, let's look at a couple implementations of the > Haversine function (from http://rosettacode.org/wiki/Haversine_formula). > Comments to illustrate language differences are mine. > > Here's the Common Lisp version. > > (defparameter *earth-radius* 6372.8) > (defparameter *rad-conv* (/ pi 180)) > ;; Minor complication right off: assignment of variables or constants > ;; is completely different depending on whether you're > ;; defining something in general, like here, or only for > ;; a subsequent clause, like the let* functions later on. > > (defun deg->rad (x) > (* x *rad-conv*)) > ;; Prefix notation for arithmatic is unfamiliar to most people > ;; since that's not what we learn in school, so that's a first > ;; hurdle for readability. My first calculator was RPN, so prefix wasn't really a hurdle. ;-) > (defun haversine (x) > (expt (sin (/ x 2)) 2)) > ;; To grok this function you need to have four levels of > ;; parentheses simultaneously open in your head. > > (defun dist-rad (lat1 lng1 lat2 lng2) > (let* ((hlat (haversine (- lat2 lat1))) > ;; Then there's the let vs. let* issue, > ;; no big deal for experienced programmers > ;; but not entirely easy to explain to a beginner. > ;; On the other hand, Python has its own confusing points on > ;; that issue, like when you need to specify "global". > (hlng (haversine (- lng2 lng1))) > (root (sqrt (+ hlat (* (cos lat1) (cos lat2) hlng) >;; for that expression you need 7 levels of mental parens open > (* 2 *earth-radius* (asin root > > (defun dist-deg (lat1 lng1 lat2 lng2) > (dist-rad (deg->rad lat1) > (deg->rad lng1) > (deg->rad lat2) > (deg->rad lng2))) > > ;; End Lisp example > > Seven levels of unclosed lists that you need to keep in your head > in order to read and understand the program at its deepest point. Seven? Oh, there it is, inside the calculation of root in dist-rad. > Here's the same thing in Python: It's equivalent. It's not the same. (For example, in Lisp, the parameters are clearly marked as such by the form defparameter, but in Python, the parameters and the temporary variables are created with the same syntax. When I read the Python code, how can I tell that R is a parameter rather than a temporary variable? But that's not related to the question of open parentheses. Also, the Lisp example separates the conversion to radians into a helper function, but the Python version doesn't.) > from math import radians, sin, cos, sqrt, asin > > def haversine(lat1, lon1, lat2, lon2): > R = 6372.8 # Earth radius in kilometers > > dLat = radians(lat2 - lat1) > dLon = radians(lon2 - lon1) > lat1 = radians(lat1) > lat2 = radians(lat2) > > a = sin(dLat / 2)**2 + cos(lat1) * cos(lat2) * sin(dLon / 2)**2 > c = 2 * asin(sqrt(a)) > > return R * c > > # end Python example > > The equation is still the same equation, but it looks a lot more > like the equation you'd see in a math textbook, or write on a > homework assignment, modulo notational issues like ** instead of > superscripts. The deepest level of parentheses you ever need to > keep in your head is two, but the second level is just a very > simple function call, sqrt(a). The indentation level (the program > structure) never gets beyond one. > > On the other hand, your brain does need to keep track of more > intermediate variables (dLat, dLon etc.) Perhaps some people might > find that harder. On the other other hand, there's no confusing operator precedence rules in Lisp. We know the basic arithmetic operators from grade school, but who can remember whether & or and bind more tightly than or and | (sic)? Instead of memory, some programmers use *parentheses* to *clarify*. ;-) > And yes, you could write the Lisp to look more like the Python or > vice versa. You're welcome to try that, but I predict you'll find that > even if you use the same number of intermediate variables, Lisp will > always require you to keep that larger mental stack of open parens. A larger stack of *parentheses*, yes, but I don't think a larger stack. Python: def f(x): y = b + m * x return y Lisp:(defun f (x) (let ((y (+ b (* m x
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
> In Lisp, your hammer is the list. > In, say, Java, your tool is classes and inheritance. And yet if Lisp or Java programmers were here they would say their languages //are// multi-paradigm too. For example, Lisp has the Common Lisp Object System (CLOS) and Java has the Vector class and so on. Maybe Python somehow gives more paradigms //better// syntax support whereas in Lisp and Java they are somewhat "bolted on" and not done as well? cs -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
> It's also probably significantly slower, so you'd likely still want to > use the iterative version Generalizing this to the majority of recursive functions/methods, are their iterative counterparts more efficient? (I say "majority of" because I've personally encountered one or two recursive functions/methods that were either very difficult for me to translate to iteration or just not possible with my skill level at the time) > It is related to the old saying "If all you have is a hammer, then > everything looks like a nail". Using this saying in the context of programming languages is extremely accurate! Because Python can be object oriented or data oriented, it is a large toolbox capable of tackling an even larger set of problems quite simply. I've never personally used Lisp, but I have used Java a bit. Even just the strict object-oriented nature of Java was fairly cumbersome. The freedom, fluidity, and the dynamic nature of Python are the reasons it's my preferred language. For just a moment, allow me to abstract this argument to include languages other than Lisp I'm better versed in. Older languages, like Java and C, required explicit typing for their variables, explicit output types for their methods, and semicolons and brackets instead of utilized whitespace. Please correct me if I'm wrong, but this system was primarily for saving memory because computers were far less powerful when these languages were born. Python, being a relatively young language, is free from these shackles and was built to run on more modern computers where bits and bytes are not a common constraint. That said, if I were to ever design a software I planned on sharing, I would write it in one of the more space-friendly languages. Thank y'all for the great reading about Lisp vs Python and letting me get very off-topic. Best, Wyatt Biggs -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Fri, 7 Aug 2020 at 19:48, Richard Damon wrote: > The difference is that the two languages define 'expression' differently. > [...] I don't know if this is interesting or pertinent to the topic. Christian Seberino just expressed a doubt about how a clear separation between a statement and an expression is quite desiderable in the "real" programming world. And I tried to explain it with the assignment operation, since a ton of programmers feel very frustrated about reading code of other programmers with assignment in an if statement. I'm quite sure that they thought, as I thought: "What do this?" Worse when their program failed and they discovered that they wrote `if (a=b)` instead of `if (a==b)`. I'm just more curious about why Lisp programmers think that it's better to not make a hard distinction between statements and expressions. -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 2020-08-07 at 11:02:50 -0700, Christian Seberino wrote: > > In Lisp, your hammer is the list. > > > In, say, Java, your tool is classes and inheritance. > > And yet if Lisp or Java programmers were here they would say their > languages //are// multi-paradigm too. For example, Lisp has the > Common Lisp Object System (CLOS) and Java has the Vector class and so on. Of what is "Java has the Vector class" an example? That the tools in Java are classes and inheritance? -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 2020-08-07 at 21:54:35 +0200, Marco Sulla wrote: > On Fri, 7 Aug 2020 at 19:48, Richard Damon wrote: > Christian Seberino just expressed a doubt about how a clear separation > between a statement and an expression is quite desiderable in the > "real" programming world. And I tried to explain it with the > assignment operation, since a ton of programmers feel very frustrated > about reading code of other programmers with assignment in an if > statement. I'm quite sure that they thought, as I thought: "What do > this?" > Worse when their program failed and they discovered that they wrote > `if (a=b)` instead of `if (a==b)`. Don't conflate the concept with the syntax. The fact that Python now has "the walrus operator" says that assignment expressions are useful. The issue with the C version is that the assignment and comparison operators look too much alike and using the wrong one can cause *silent* catastrophes (although modern C compilers can and do emit appropriate warnings or errors, if you ask them nicely). > I'm just more curious about why Lisp programmers think that it's > better to not make a hard distinction between statements and > expressions. Simplicity of syntax. Very few languages have a simpler syntax than Lisp (Ook, et al, notwithstanding). -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 8/7/2020 11:46 AM, Chris Angelico wrote: My point is that doing Fibonacci recursively is arguably more elegant while being materially worse at performance. This is a common misconception. Linear iteration and tail recursion are equivalent. The issue is calculating values once versus multiple times. Here is the fast recursion equivalent to the fast iteration. def fib(n, pair=(1,0)): previous, current = pair if n: return fib(n-1, (current, previous + current)) else: return current for i in range(10): print(fib(i), end=' ') # 0 1 1 2 3 5 8 13 21 34 One can also do the slow algorithm, with wasteful duplication, iteratively with one or two stacks of values instead of the hidden stack of execution frames. I don't remember the details right now without checking a text. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 2020-08-07 at 13:43:06 -0500, Wyatt Biggs wrote: > > It's also probably significantly slower, so you'd likely still want to > > use the iterative version > > Generalizing this to the majority of recursive functions/methods, are > their iterative counterparts more efficient? (I say "majority of" > because I've personally encountered one or two recursive > functions/methods that were either very difficult for me to translate > to iteration or just not possible with my skill level at the time) As usual, it depends. :-) Often, a recursive algorithn in the *source* code is rewritten/optimized by a compiler into an iterative algorithm in the *object* code. And sometimes, iterative code is rewritten into straight line imperative code (i.e., loop unrolling, constant folding, etc.). At runtime, that stack of pending items has to be somewhere, and the hardware stack (where the CPU-level return addresses are stored) can be as good a place as any, which means that the recursive version *might* be as fast or faster than the iterative version, under certain circunstances. > For just a moment, allow me to abstract this argument to include > languages other than Lisp I'm better versed in. Older languages, like > Java and C, required explicit typing for their variables, explicit > output types for their methods, and semicolons and brackets instead of > utilized whitespace. Please correct me if I'm wrong, but this system > was primarily for saving memory because computers were far less > powerful when these languages were born. Python, being a relatively > young language, is free from these shackles and was built to run on > more modern computers where bits and bytes are not a common > constraint. Lisp is older than both C and Java (by decades), and there's still no explicit typing for variables. In Lisp, the data has a type, and the "variables" are just names for it (just like Python, or rather Python is just like Lisp). > That said, if I were to ever design a software I planned on sharing, I > would write it in one of the more space-friendly languages. Space-friendly? -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Fri, 7 Aug 2020 at 19:41, Christian Seberino wrote: > I think this is really significant point why more syntax does necessarily > mean less readability. I don't think so. Readability of programming languages was measured using an objective method, and Python was one of the most readable. The fact that a grammar is simpler does not mean it's more readable for human beings. It's surely most simple to optimize for compilers. For example, RISC instructions in CPUs were simpler than CISC. Even if Intel tried to defend CISC, modern Intel CPUs have reduced their set of instructions a lot. Furthermore, the majority of smartphone CPUs are ARM, that have RISC instructions. Think also about NAND. You can express the whole boolean logic using only NAND or NOR. In the beginning, only the Military and NASA constructed electrical circuits only with NAND or NOR gates. Now there are electronic circuits made for common people, using only or mainly NAND gates: they are, for example, pen cards and SSD drives. But they are not simpler to understand. For example, in math you *could* think a*b as a+a done b times. But what if a and b are imaginary numbers? There are many programmers that just feel Python much more simple to read and use. Google can tell you a lot about this. Also Rosetta code can show it to you clearly: http://www.rosettacode.org/wiki/Rosetta_Code It seems to me that you want to convince your colleagues that Python is better than Lisp. I think that: 1. there's not a "best". The "best" depends heavily on what you need. 2. the people you have to convince is only yourselves 3. to convince yourselves, you have to try. "Refuse the temptation to guess" :) -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Fri, 7 Aug 2020 at 22:35, Terry Reedy wrote: > This is a common misconception. Linear iteration and tail recursion are > equivalent. The issue is calculating values once versus multiple times. > Here is the fast recursion equivalent to the fast iteration. > > def fib(n, pair=(1,0)): > previous, current = pair > if n: >return fib(n-1, (current, previous + current)) > else: >return current > > for i in range(10): print(fib(i), end=' ') > # 0 1 1 2 3 5 8 13 21 34 It seems to me a sort of not persistent caching. If you do: fib(very_large_number) without calculating any previous Fibonacci number before, it will be very slow and you could have a stack overflow. A language with tail call optimization will execute it faster and with less memory. Otherwise why asyncio de-facto implemented tail optimization? PS: it seems there's a module that implement tail call: https://github.com/baruchel/tco -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Sat, Aug 8, 2020 at 6:34 AM Terry Reedy wrote: > > On 8/7/2020 11:46 AM, Chris Angelico wrote: > > > My point is that doing Fibonacci recursively is arguably more elegant > > while being materially worse at performance. > > This is a common misconception. Linear iteration and tail recursion are > equivalent. The issue is calculating values once versus multiple times. > Here is the fast recursion equivalent to the fast iteration. > > def fib(n, pair=(1,0)): > previous, current = pair > if n: >return fib(n-1, (current, previous + current)) > else: >return current > > for i in range(10): print(fib(i), end=' ') > # 0 1 1 2 3 5 8 13 21 34 > > One can also do the slow algorithm, with wasteful duplication, > iteratively with one or two stacks of values instead of the hidden stack > of execution frames. I don't remember the details right now without > checking a text. I'm aware you can do recursion iteratively and iteration recursively, but why WOULD you ever do this? The version you've shown here isn't any more elegant than the purely iterative version, and all it's doing is implementing a for loop using recursive calls. (Also, it has one thing that rankles with me, and that's a function signature that is intentionally different for the recursive calls as for the main call. You should *never* pass the 'pair' parameter on the initial call, and it will *always* be passed on the recursive calls.) The idiomatic recursive version is not tail recursive. Same with the idiomatic recursive merge sort, which does forking recursion and then tail-calls the merge operation. (Or you can implement the merge inline, but whenever I'm explaining it, I prefer to write merge() as a separate function.) Knowing how to translate recursion into iteration and vice versa is a useful skill (picture this: you're trying to build some actual coded logic into an alias expansion system, where the only conditional you have is "execute this file" with text substitution in the file name, and the only looping you have is to re-execute the same file), but it's not the way to show off the beauty of recursion. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 8/7/20 4:08 PM, Terry Reedy wrote: > On 8/7/2020 11:46 AM, Chris Angelico wrote: > >> My point is that doing Fibonacci recursively is arguably more elegant >> while being materially worse at performance. > > This is a common misconception. Linear iteration and tail recursion > are equivalent. The issue is calculating values once versus multiple > times. Here is the fast recursion equivalent to the fast iteration. > > def fib(n, pair=(1,0)): > previous, current = pair > if n: > return fib(n-1, (current, previous + current)) > else: > return current > > for i in range(10): print(fib(i), end=' ') > # 0 1 1 2 3 5 8 13 21 34 > > One can also do the slow algorithm, with wasteful duplication, > iteratively with one or two stacks of values instead of the hidden > stack of execution frames. I don't remember the details right now > without checking a text. > But your example breaks the 'problem' in the recursion that Fibonacci, when expressed 'naturally', the current value is based on two different earlier values. You have morphed the definition, using basically the iterative solution, so that the recursive call to fir(0, ...) doesn't actually calculate the fib(0) value, but fib(n). Yes, this shows that you can convert an iterative solution into a recursive solution with a bit of hand waving, but you still end up with a program based on the iterative algorithm, not the possibly natural recursive one. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Sat, Aug 08, 2020 at 01:46:28AM +1000, Chris Angelico wrote: > On Sat, Aug 8, 2020 at 1:38 AM Python wrote: > TBH most people won't get the recursive version right the first time > either. So FWIW, I/my team don't find this to be true. I was originally going to mention this in my previous post but decided to leave it out for brevity (and in part because I assumed anyone familiar with the problem already expected it was so). In fact my team frequently uses Fibonacci as an interview question. We've been doing so for at least a decade, so we do have a not-insubstantial sample size. We find that candidates can much more easily implement the recursive version correctly, and do so on the first try roughly 70-80% of the time. Nearly all candidates choose to implement the recursive version for that reason. Those that don't are pretty familiar with the problem, and choose the iterative version so they can "show off" their knowledge of the performance benefits. They typically also implement the recursive version immediately after, because it's pretty trivial to do it in most programming languages, and because they assume the point of the question is to ascertain whether they grok recursion. Which is partly true, but only partly--we use it because it is a short problem that can be quickly implemented, and demonstrates a few different interesting concepts, one of which is recursion. When we do use it, we always follow up with "Can you implement this iteratively?" (assuming they didn't already). A small percentage insist that it is impossible. Most who try (again, roughly 70-80%) fail on the first try. Figuring out how to correctly prime the state is pretty much invariably the sticking point. These are not students, they are experienced programmers. This may explain why they usually can easily implement the recursive version, but it does not really address why most of them have trouble with the iterative version. :) -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 8/7/2020 11:55 AM, Marco Sulla wrote: @Chris: note that "real" recursion in Python is not possible, This is backwards. Python only does real recursion when one writes recursive calls. since there's no support for tail recursion. I am pretty sure that what you mean by 'support' is to turn tail recursive syntax into iteration, making it fake recursion. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Any ideas for a new language inspired to Python?
Let me first say that I don't know if my post is on topic with the mailing list. If so, please inform me. My idea seems to be very simple (so probably it's not simple at all): a language similar to Python, but statically compiled. (Yes, I know Cython, RPython, Julia, Rust...) Since I've not great skill in low-level programming, I'm trying first to define what I really want. My core ideas are: 1. Statically compiled (of course...). So if you write: var a = 1 the variable `a` is an integer and it's value can't be changed to anything that is not an integer 2. Use of smart pointers. Instead of having a refcount in every object, the language implementation will use a smart pointer as a sort of "proxy" to the "real" pointer. This could allow the language implementation to delete the object only when really necessary (lack of memory) and/or do JIT optimizations (move the object to a slower or a faster memory; compute and cache some object attributes, as hash; remove object duplicates...) 3. functional programming under-the-hood. Users can write also in imperative style, but in the language implementation only the functional style is really used. This way *maybe* it's more simple to write concurrent programs without a GIL. But I have a lot of doubts. The one that bothers me most is: compile to binary or to C? My idea at the beginning was to compile to C code without creating an AST. Virtually any system has its own C compiler. Maybe it *seems* more simple, but it's quite more difficult? -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 8/7/20 3:54 PM, Marco Sulla wrote:
> On Fri, 7 Aug 2020 at 19:48, Richard Damon wrote:
>> The difference is that the two languages define 'expression' differently.
>> [...]
> I don't know if this is interesting or pertinent to the topic.
>
> Christian Seberino just expressed a doubt about how a clear separation
> between a statement and an expression is quite desiderable in the
> "real" programming world. And I tried to explain it with the
> assignment operation, since a ton of programmers feel very frustrated
> about reading code of other programmers with assignment in an if
> statement. I'm quite sure that they thought, as I thought: "What do
> this?"
> Worse when their program failed and they discovered that they wrote
> `if (a=b)` instead of `if (a==b)`.
>
> I'm just more curious about why Lisp programmers think that it's
> better to not make a hard distinction between statements and
> expressions.
Actually, they might put a fairly hard distinction between statements
and expressions, a statement is a list that begins with a programmatic
atom, while an expression is a list that begins with an operator atom.
The fact that EVERYTHING is a list, makes those not used to the idea see
it as all the same (which I suppose in a way it is).
One side effect of this is that a program isn't just a bunch of
statements in sequence, but is actually a LIST of those statements, so
the whole program becomes effectively a single list.
The really interesting part is that since Lisp programs manipulate lists
as data, and the program is just a list, Lisp programs have the
theoretical ability to edit themselves (assuming the implementation give
access to the list of the program to the program).
Now for the general separation of expression from statement, which isn't
really as applicable to Lisp, since (if I remember right) assignment
doesn't use the = token, so you are less apt to make the mistake, there
are several arguments.
The confusion of assignment for equality comparison is likely on of the
big issues.
Some languages solve the problem by making assignments a special type of
statement, so you can't make the mistake, some of these even make = be
both, so the have to make the distinction.
Some languages (like C) make assignment just a 'normal' operator, and
either just trust the programmer or use conventions to help generate
warnings (either at compile time or a separate Lint phase). People using
these languages will either like the additional power it give, or curse
the language for the additional opportunities to make mistakes (or
both). Some langagues make the mistake harder to make by using some
symbol other than = for assignment, like Pythons new := symbol.
One advantage of blurring the line between statements and expressions is
power, putting assignments in the middle of an expression, can allow
code to be more compact. Some extensions to C are even trying to take
this farther, and letting the programmer embed a { } block into a
statement as an expression, which is perhaps taking that idea to an extreme.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Sat, 8 Aug 2020 at 00:28, Richard Damon wrote: > The really interesting part is that since Lisp programs manipulate lists > as data, and the program is just a list, Lisp programs have the > theoretical ability to edit themselves (assuming the implementation give > access to the list of the program to the program). This is a bit hard to understand for me. I know that code can be translated to an AST, that is a tree. It's quite difficult for me to imagine the code organized as a list. Do you have some links about it? On Sat, 8 Aug 2020 at 00:28, Richard Damon wrote: > One advantage of blurring the line between statements and expressions is > power, putting assignments in the middle of an expression, can allow > code to be more compact. I agree with you. I experimented a little with CPython code and I saw assignments inside if statements. The code without them was less readable. I also found this example: https://stackoverflow.com/a/151920/1763602 My only fear is the abuse. How many people really use the walrus operator to render the code more readable? My fear is that the majority of programmer will use it for laziness and because it's "cool" ^^ -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On 8/7/20 6:55 PM, Marco Sulla wrote: > On Sat, 8 Aug 2020 at 00:28, Richard Damon wrote: >> The really interesting part is that since Lisp programs manipulate lists >> as data, and the program is just a list, Lisp programs have the >> theoretical ability to edit themselves (assuming the implementation give >> access to the list of the program to the program). > This is a bit hard to understand for me. > I know that code can be translated to an AST, that is a tree. It's > quite difficult for me to imagine the code organized as a list. Do you > have some links about it? Lisp is built on Nested list, Lists were some (many) of the nodes are other list. (Somewhat like you might build the AST in Python) Generally the first element of the list defines what the list is, type of statement or operation, and the rest are the parameters for it. Many of these will be lists for sub expressions or dependent statements. Perhaps the best option would be to search for the Lisp Language, and see how you write programs. > > On Sat, 8 Aug 2020 at 00:28, Richard Damon wrote: >> One advantage of blurring the line between statements and expressions is >> power, putting assignments in the middle of an expression, can allow >> code to be more compact. > I agree with you. I experimented a little with CPython code and I saw > assignments inside if statements. The code without them was less > readable. I also found this example: > https://stackoverflow.com/a/151920/1763602 > My only fear is the abuse. How many people really use the walrus > operator to render the code more readable? My fear is that the > majority of programmer will use it for laziness and because it's > "cool" ^^ There is always the danger, that as you give the programmer more expressive power, they can use it for 'good', or they can miss-use it to make code harder to read. The question comes how much are you willing to trust the programmer, or are you just going to give them enough rope so that can do themselves in. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
Il 28/07/20 00:19, Grant Edwards ha scritto: You err. I read it, I had to test. In effects, it was simple to test. me@debsrv:~/tmp/test$ ln -s /home/me/mydir aaa me@debsrv:~/tmp/test$ ln -s /home/me/mydir bbb me@debsrv:~/tmp/test$ ls aaa bbb me@debsrv:~/tmp/test$ stat --format=%i /home/me/mydir 18481153 me@debsrv:~/tmp/test$ stat --format=%i aaa 2364513 me@debsrv:~/tmp/test$ stat --format=%i bbb 2374065 Thanks -- Pastrano con un altro account -- https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
Il 28/07/20 02:50, Dennis Lee Bieber ha scritto: inode numbers apply for HARD LINKS Thanks -- Pastrano con un altro account -- https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
Il 27/07/20 20:37, Chris Angelico ha scritto: Unfortunately there's no real way to shortcut this if you just want to check one target directory. You'd still have to readlink() every symlink to try to find them. Sorry for 10 days of delay (hardware problems at home). Yes, that is. It's a mode to order directories from their content, but due the first chars are always the same, and then I got a tree like finaldir/f/firstpart/secondpart [changing_values] and the test should be done only on a small list of links, so they're fast. -- Pastrano con un altro account -- https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
On 2020-08-08 at 01:58:13 +0200, Termoregolato wrote: > me@debsrv:~/tmp/test$ stat --format=%i /home/me/mydir > 18481153 Try ls -i. :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
>> Readability of programming languages was measured >> using an objective method, and Python was one of >> the most readable. Do you have a source for this? -- https://mail.python.org/mailman/listinfo/python-list
Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?
On Sat, 8 Aug 2020 at 03:46, Christian Seberino wrote: > >> Readability of programming languages was measured > >> using an objective method, and Python was one of > >> the most readable. > > Do you have a source for this? This question means you have not read at all my suggestions :-D Anyway, this is one: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3933420/ I do not agree with the entire work, but generally speaking it seems to me they used a good approach. What really surprises me is the absence of languages like JS and PHP. -- https://mail.python.org/mailman/listinfo/python-list
