Comparing Lisp to Python, what you consider more important: speed or macros. [Lisp]

Prev: Comparing Lisp to Python, what you consider more important:speed or macros.
Next: Comparing Lisp to Python, what you consider more important: speed or macros.

From: grucidipo on 28 Apr 2010 16:08

From: fortunatus on 28 Apr 2010 17:04

On Apr 28, 4:08 pm, grucidipo <gruzci...(a)yahoo.es> wrote:
> .... The most difficult part is to develop an algorithm to solve a
> problem, i don't think there is any difficulty writing the code.

There must be some difficulty, else you wouldn' be able to
differentiate "easy to program" between the two languages as you
have. Surely you must have some opinion about your relative skill
level with each language.

Some of my thoughts:
.. Python and Lisp both gain giant "easy to program" marks for dynamic
data typing, ie, values have type but variables don't need to (unless
optimizing for speed, for instance).
.. Common Lisp has compiler hints to optimize speed. (And space.
Wizard of space and time.)
.. Macros can let some library functions, like compatability layers,
add essentially no speed penalty over in-line code.
.. Some general GUI code I've seen in Python suffers hugely from lack
of macros - blocks of 8-20 lines cut & paste copied, with minor
modifications many times. This makes it easy to introduce mistakes,
which should lower the evaluation of "easy to program" due to hours
spent debugging. Macros accordingly, for me, raise Lisp's "easy to
program" by reducing mistakes.
.. Macros also let you make new control flow constructs where bodies of
code are an argument, and the macro can change the body of code before
dropping it into place, like scanning through and replacing keywords
with new bits of code. Again, if you have some experience under your
belt with regard to macros, and you tend to revisit very similar
problems, Lisp should get another huge "easy to program" boost for all
the times after the first couple, when you are using your great macro.
.. You'll never come to the end of why Lispers like macros...

From: grucidipo on 28 Apr 2010 17:04

On 28 abr, 21:33, His kennyness <kentil...(a)gmail.com> wrote:
> grucidipo wrote:
> > I find easier to program in Python than in Lisp, but Lisp has Macros
> > and it can optimise for speed.
>
> > Here are some subjective numbers:
>
> > Easy to program & Standard Library & Speed & Macros
> > or similar
>
> > Python: 0,8 0,8 0,5 0.4
> > Lisp : 0,5 0,5 0,8 0,8
>
> > I would like to know what weight other Lisper give to theses
> > factors. I know that it depend of what type of application you are
> > developing, but I am curious what other think about this.
>
> I cannot evaluate your "easy to program" values without knowing your
> level of mastery of each language. Would that happen to be 8-5?
>
> kt

As you are developing teaching algebra, here is a more simple program
for learning basic operations :))

(defun ask-what-is(op arg1 arg2)
(let (op&name res)
(setq op&name '((+ "sum") (* "product") (- "difference"))
res (funcall op arg1 arg2))
(format t "~%What is the ~s of ~s and ~s?" (second (assoc op
op&name)) arg1 arg2)
(setq in (read))
(if (= in (funcall op arg1 arg2))
(format t "~%Correct!")
(format t "~%The correct answer is ~s" res))
(= res in)))

(defun teach(num)
(let (h1 h2 l1 l2 op)
(setq h1 (make-hash-table)
h2 (make-hash-table)
l1 '(+ * -)
l2 '(sum product difference))
(dotimes(i num)
(setq op (nth (random (length l1)) l1))
(when (ask-what-is op (random 10) (random 10))
(incf (gethash op h1 0)))
(incf (gethash op h2 0)))
(format t "~%Result of this test:")
(dotimes (i (length l1))
(format t "~%for the ~s operation you got ~s correct answers
out of ~s"
(nth i l2) (gethash (nth i l1) h1 0) (gethash (nth i l1) h2
0)))))

From: grucidipo on 28 Apr 2010 17:21

On 28 abr, 23:04, fortunatus <daniel.elia...(a)excite.com> wrote:
> On Apr 28, 4:08 pm, grucidipo <gruzci...(a)yahoo.es> wrote:
>
> > .... The most difficult part is to develop an algorithm to solve a
> > problem, i don't think there is any difficulty writing the code.
>
> There must be some difficulty, else you wouldn' be able to
> differentiate "easy to program" between the two languages as you
> have. Surely you must have some opinion about your relative skill
> level with each language.

The difficulty is about taking care of the correct type, for example
nth, gethash, char, aref, svref instead python accessor [], that is
you gain speed because you don't use CLOS like operations, defgeneric
[](.....)
> Some of my thoughts:
> . Python and Lisp both gain giant "easy to program" marks for dynamic
> data typing, ie, values have type but variables don't need to (unless
> optimizing for speed, for instance).
> . Common Lisp has compiler hints to optimize speed. (And space.
> Wizard of space and time.)
> . Macros can let some library functions, like compatability layers,
> add essentially no speed penalty over in-line code.
> . Some general GUI code I've seen in Python suffers hugely from lack
> of macros - blocks of 8-20 lines cut & paste copied, with minor
> modifications many times. This makes it easy to introduce mistakes,
> which should lower the evaluation of "easy to program" due to hours
> spent debugging. Macros accordingly, for me, raise Lisp's "easy to
> program" by reducing mistakes.
> . Macros also let you make new control flow constructs where bodies of
> code are an argument, and the macro can change the body of code before
> dropping it into place, like scanning through and replacing keywords
> with new bits of code. Again, if you have some experience under your
> belt with regard to macros, and you tend to revisit very similar
> problems, Lisp should get another huge "easy to program" boost for all
> the times after the first couple, when you are using your great macro.
> . You'll never come to the end of why Lispers like macros...

I agree, macros are a big win, but the problem I see is that they are
not easy to standardise, you can construct a new language with macros
and for others reading your code can be difficult.

From: grucidipo on 28 Apr 2010 17:30

On 28 abr, 23:23, Tim Bradshaw <t...(a)tfeb.org> wrote:
> On 2010-04-28 21:08:44 +0100, grucidipo said:
>
> > i don't think there is any difficulty writing the code.
>
> Then just use COBOL, it runs everywhere. Problem solved!

Well, there are no bignums, C, rationals, ... in COBOL, so to make
some mathematical computations you should have to write again all the
code, so there is no real difficulty in writing the code, the problem
is that you should have to write a lot of libraries, that is a new
language.

Just remember .... any complex language have a small Lisp inside (I
don't remember exactly the name Greenspoon rule or similar).

Also someone not very popular here compared Lisp to COBOL, hint is
something like Wax

| Next | Last
Pages: 1 2 3 4
Prev: Comparing Lisp to Python, what you consider more important:speed or macros.
Next: Comparing Lisp to Python, what you consider more important: speed or macros.