Mailing List Archive

On Fri, Aug 7, 2020 at 1:16 AM Christian Seberino <cseberino@gmail.com> 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?

Ook has an even simpler syntax. It has just three syntactic elements:
"Ook." "Ook?" "Ook!"

The purpose of code is to represent a programmer's intentions in a way
that can be understood by other programmers, and by the
interpreter/compiler. Simpler syntax allows a simpler parser, but it
doesn't create expressiveness.

If your definition is based entirely on how quickly a beginner would
be able to learn the details of how a language is run, then that's
missing a lot of the point of readability. The point of learning a
language isn't that you can take a piece of pre-existing code and
figure out what it'll do, step by step; the point is to be able to
encode your intentions in that language, and to read the code and
understand the other programmer's intentions. That's why we have
comments - the language would be (slightly) simpler without them, but
we would lose an important aspect of that programmer-to-programmer
communication.

Ook is one of the least expressive and most simple languages there is.
Python is far more expressive, far more detailed... and far FAR more
useful.

Lisp is elegant and simple, but it's also less expressive than Python
is. That's why Python is (often) easier to work with.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On Thursday, August 6, 2020 at 10:52:00 AM UTC-5, Chris Angelico wrote:
> The point of learning a
> language isn't that you can take a piece of pre-existing code and
> figure out what it'll do, step by step; the point is to be able to
> encode your intentions in that language, and to read the code and
> understand the other programmer's intentions.

Thanks for sharing your thoughts. How do you define "expressiveness"?
Also, why is Python syntax able to more clearly communicate intentions?
Both Python and Lisp have comments so that isn't it.

cs
--
https://mail.python.org/mailman/listinfo/python-list

On Fri, Aug 7, 2020 at 2:36 AM Christian Seberino <cseberino@gmail.com> wrote:
>
> On Thursday, August 6, 2020 at 10:52:00 AM UTC-5, Chris Angelico wrote:
> > The point of learning a
> > language isn't that you can take a piece of pre-existing code and
> > figure out what it'll do, step by step; the point is to be able to
> > encode your intentions in that language, and to read the code and
> > understand the other programmer's intentions.
>
> Thanks for sharing your thoughts. How do you define "expressiveness"?
> Also, why is Python syntax able to more clearly communicate intentions?
> Both Python and Lisp have comments so that isn't it.
>

Expressiveness is about how well you can translate your ideas into
code, and how well someone else can interpret your ideas by reading
your code. It's hard to quantify, but it's in a way the most important
thing about any language.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

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. 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.

...Akkana
--
https://mail.python.org/mailman/listinfo/python-list

On 2020-08-07 at 04:00:34 +1000,
Regarding "Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?,"
Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Aug 7, 2020 at 2:36 AM Christian Seberino <cseberino@gmail.com> wrote:
> >
> > On Thursday, August 6, 2020 at 10:52:00 AM UTC-5, Chris Angelico wrote:
> > > The point of learning a
> > > language isn't that you can take a piece of pre-existing code and
> > > figure out what it'll do, step by step; the point is to be able to
> > > encode your intentions in that language, and to read the code and
> > > understand the other programmer's intentions.
> >
> > Thanks for sharing your thoughts. How do you define "expressiveness"?
> > Also, why is Python syntax able to more clearly communicate intentions?
> > Both Python and Lisp have comments so that isn't it.
> >
>
> Expressiveness is about how well you can translate your ideas into
> code, and how well someone else can interpret your ideas by reading
> your code. It's hard to quantify, but it's in a way the most important
> thing about any language.

I would say that expressiveness is how *directly* you can translate your
ideas into code, and how *directly* some one else can see your original
idea by reading your code.

So when I say something like "create a new list in which each value is
double the value in the current list," that translates to relatively
idiomatic Python like so:

new_list = []
for value in current_list:
new_list.append(2 * value) # or maybe value + value; YMMV

Or even:

[ 2 * value for value in current_list ]

In Lisp, it might look like this:

(mapcar #'(lambda (value) (* 2 value)) current_list)

Unless you're familiar with Lisp (or Lisp-like languages), and
comfortable with high order functions (which many/most beginners aren't,
although most Lispers are), it's a lot harder to see the idea in the
code.

Having written my share of both Python and Lisp, I appreciate the
benefits of Lisp's syntax, but I also know that it still takes me a
little longer to read and understand a big block of straightforward Lisp
vs. a big block of straightforward Python. (Between dunders,
properties, and other bits of magic that takes place far away from its
invocation, Python code and the logic behind it can be *very* confusing
to unravel. Lisp macros present the same problem.)
--
https://mail.python.org/mailman/listinfo/python-list

On Fri, Aug 7, 2020 at 5:10 AM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
>
> I would say that expressiveness is how *directly* you can translate your
> ideas into code, and how *directly* some one else can see your original
> idea by reading your code.

Yep, how directly or how accurately.

> So when I say something like "create a new list in which each value is
> double the value in the current list," that translates to relatively
> idiomatic Python like so:
>
> new_list = []
> for value in current_list:
> new_list.append(2 * value) # or maybe value + value; YMMV
>
> Or even:
>
> [ 2 * value for value in current_list ]
>
> In Lisp, it might look like this:
>
> (mapcar #'(lambda (value) (* 2 value)) current_list)
>
> Unless you're familiar with Lisp (or Lisp-like languages), and
> comfortable with high order functions (which many/most beginners aren't,
> although most Lispers are), it's a lot harder to see the idea in the
> code.

One thing worth noting is that your mental pseudo-code is affected by
the languages you're comfortable with. You said:

> create a new list in which each value is double the value in the current list

which clearly and obviously translates into a list comprehension. But
what if you instead thought of it as:

> double every value in this list

? That would translate far more obviously into an imperative construct
that doesn't really work in Python, but imagine that we had reference
variables:

for &value in list: value *= 2

So the expressiveness of a language isn't a fixed quantity, but it
depends on the programmer. And it can change as you learn and adjust,
too.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On 2020-08-07 at 05:22:53 +1000,
Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Aug 7, 2020 at 5:10 AM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:

> One thing worth noting is that your mental pseudo-code is affected by
> the languages you're comfortable with. You said:
>
> > create a new list in which each value is double the value in the current list
>
> which clearly and obviously translates into a list comprehension. But
> what if you instead thought of it as:
>
> > double every value in this list
>
> ? That would translate far more obviously into an imperative construct
> that doesn't really work in Python ...

for (index, value) in enumerate(this_list):
this_list[index] = 2 * value

Or:

for index in range(len(this_list)):
this_list[index] *= 2

(But I tend to avoid that, though, because I can never remember exactly
which mutations work inside a loop and which ones don't (or does
enumerate remove some or all of those restrictions?). Which feeds right
into what you said about being comfortable with certain languages or
programming styles.)

[Shared] Mutable Data will be the death of us all! ;-)

> So the expressiveness of a language isn't a fixed quantity, but it
> depends on the programmer. And it can change as you learn and adjust,
> too.

I think the expressiveness of the language remains fairly constant, new
features notwithstanding. Unless you mean that a given programmer's
usage of that expressiveness changes, in which case I absolutely agree.
--
https://mail.python.org/mailman/listinfo/python-list

On 8/6/20 4:07 PM, 2QdxY4RzWzUUiLuE@potatochowder.com wrote:
> for (index, value) in enumerate(this_list):
> this_list[index] = 2 * value
>
> Or:
>
> for index in range(len(this_list)):
> this_list[index] *= 2
>
> (But I tend to avoid that, though, because I can never remember exactly
> which mutations work inside a loop and which ones don't (or does
> enumerate remove some or all of those restrictions?). Which feeds right
> into what you said about being comfortable with certain languages or
> programming styles.)

Since you are not using an iterator of the list, changing it shouldn't
cause any problems. You loop (for its control) looks at the loop once,
before it starts, so as long as you don't delete any elements (which
would cause the index to go to high) you can't have an issue mutating
the list.

--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

> 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.

So basically while recursion is easy to write it isn't so easy for other
people to understand compared to iterative code. So maybe that is a
big part of it....recursion is just harder on the brain than iteration.

cs
--
https://mail.python.org/mailman/listinfo/python-list

On Thu, Aug 06, 2020 at 04:08:29PM -0700, Christian Seberino wrote:
> > 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.
>
> So basically while recursion is easy to write it isn't so easy for other
> people to understand compared to iterative code. So maybe that is a
> big part of it....recursion is just harder on the brain than iteration.

Not necessarily. Some problems very naturally lend themselves to
recursive solutions. Fibonacci's sequence is one.

#!/usr/bin/python

def fib(x):
if x < 1:
raise "arg must be >= 1"
if x == 1:
return 0
elif x == 2:
return 1
else:
return fib(x - 1) + fib(x - 2)

Pretty straightforward. Now try yourself to write the iterative
version. If you haven't done this recently, there's a pretty good
chance you'll get it wrong on your first try. The recursive version
is a bit simpler and more straightforward to understand, requiring
less state to be preserved (and mentally retained, if you're trying to
work through the algorithm mentally or on paper).

It's also probably significantly slower, so you'd likely still want to
use the iterative version, unless you're trying to illustrate how
recursion works or care more about writing easily understood code than
performance..

--
https://mail.python.org/mailman/listinfo/python-list

On 2020-08-06 at 16:08:29 -0700,
Christian Seberino <cseberino@gmail.com> wrote:

> > 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.

"[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.

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.

> So basically while recursion is easy to write it isn't so easy for other
> people to understand compared to iterative code. So maybe that is a
> big part of it....recursion is just harder on the brain than iteration.

I don't know about that. Have you ever seen an iterative or imperative
version of quicksort (or any divide-and-conquer algorithm, for that
matter)? Yes, it's doable, but explicitly managing your own stack of
unsorted data ranges can really obscure the idea(s) of quicksort.

And it's hard to imagine any language being more straightforward than
Haskell's recursive factorial function:

factorial 0 = 1
factorial n = n * factorial (n - 1)

(Yes, it fails for n < 0, but that's outside the scope of whether or not
recursion is harder on the brain than iteration. Pattern matching is a
beautiful thing, too.)
--
https://mail.python.org/mailman/listinfo/python-list

Some problems are well suited to recursion but perhaps //most// problems are better suited to iteration?

Maybe the spread is 10% vs 90%?

Therefore in general more often the Python way seems simpler than Lisp?
--
https://mail.python.org/mailman/listinfo/python-list

On 2020-08-06 at 20:07:05 -0700,
Christian Seberino <cseberino@gmail.com> wrote:

> Some problems are well suited to recursion but perhaps //most//
> problems are better suited to iteration?

> Maybe the spread is 10% vs 90%?

Citation needed?

> Therefore in general more often the Python way seems simpler than Lisp?

In general, the right tool is simpler than the wrong tool, regardless of
the problems and tools. Both Python and Lisp supoprt recursion,
iteration, and a number of other mindsets, paradigms, patterns, and
styles. 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.

Consider focusing less on the language and more on solving problems.
You, the problems you solve, and your solutions, will all grow over
time, and you'll discover what you like, what you don't like, what
you're good at, what you're not so good at, what works, and what
doesn't. And things will change. Solve the same problem in a different
language, preferably idiomatically rather than by transliteration. Go
back and look at code you wrote a few months or a year ago, laugh at
yourself for being so immature, and apply what you've learned since
then. Sometimes, it takes me only hours to realize how much better I
could have written a piece of code.
--
https://mail.python.org/mailman/listinfo/python-list

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

On Fri, Aug 7, 2020 at 11:11 AM Python <python@bladeshadow.org> wrote:
> Not necessarily. Some problems very naturally lend themselves to
> recursive solutions. Fibonacci's sequence is one.
>
> #!/usr/bin/python
>
> def fib(x):
> if x < 1:
> raise "arg must be >= 1"
> if x == 1:
> return 0
> elif x == 2:
> return 1
> else:
> return fib(x - 1) + fib(x - 2)
>
> 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. The iterative version seeds the
algorithm and lets it run:

def fib(x):
if x < 1: raise ValueError
last, cur = 0, 1
for _ in range(1, x):
last, cur = cur, last + cur
return cur

It needs a way of remembering the previous as well as the current,
whereas the recursive one needs to ask to calculate the previous and
previous-by-two. I'll leave it to you whether that's better or worse.

But if you want something that is massively more elegant when done
recursively, the best place to look is an inherently recursive data
structure. How do you process all files in a directory tree?

def process(dir):
for thing in dir:
if is_file_we_want(thing): use_thing(thing)
if is_dir(thing) process(thing)

Now THAT is recursion at its best. Of course it's possible to do it
iteratively, but it won't be anything like this clean. There's a
reason that directory tree operations are usually called "recursive"
(eg "rm -r" means "remove directories and their contents recursively",
per the man page).

Similarly, quick sort and merge sort are beautiful when written recursively:

def mergesort(list):
if len(list) < 2: return list
mid = len(list) // 2
left = mergesort(list[:mid])
right = mergesort(right[mid:])
return merge(left, right)

I think recursion looks best when it's doing multiple levels at once
(eg "sort the left, sort the right"), rather than just a single one
(factorial being "n * factorial(n - 1)"), since it's a lot harder to
create an elegant iterative version of multiple recursion. The
Fibonacci example is a bit of an outlier, as the recursive one is just
*so bad* in performance that it loses some elegance points, but the
other examples don't suffer from that, and they're still very clean.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

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

> 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

> ChrisA

You're definitely an expert programmer.

--
https://mail.python.org/mailman/listinfo/python-list

> 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

On Sat, Aug 8, 2020 at 1:06 AM Christian Seberino <cseberino@gmail.com> 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

On Fri, Aug 07, 2020 at 04:23:42PM +1000, Chris Angelico wrote:
> On Fri, Aug 7, 2020 at 11:11 AM Python <python@bladeshadow.org> 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

On Sat, Aug 8, 2020 at 1:38 AM Python <python@bladeshadow.org> wrote:
>
> On Fri, Aug 07, 2020 at 04:23:42PM +1000, Chris Angelico wrote:
> > On Fri, Aug 7, 2020 at 11:11 AM Python <python@bladeshadow.org> 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

On Fri, 7 Aug 2020 at 17:14, Christian Seberino <cseberino@gmail.com> 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

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