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, [ ... ]
2QdxY4RzWzUUiLuE@potatochowder.com 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
> > > 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, [ ... ]
2QdxY4RzWzUUiLuE@potatochowder.com 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