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: Tim Bradshaw on 28 Apr 2010 17:23

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!

From: Raymond Wiker on 29 Apr 2010 01:17

grucidipo <gruzcidol(a)yahoo.es> writes:

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

There are no rationals in Python, either.

From: Raymond Wiker on 29 Apr 2010 01:19

From: J Kenneth King on 29 Apr 2010 09:42

grucidipo <gruzcidol(a)yahoo.es> writes:

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

I cannot abide the "construct a new language" argument.

Macros are a part of Lisp. They don't modify the language of Lisp.
They don't create new languages inside of Lisp.

Take the concept of "triangle." One does not mention a figure of three
distinct points that do not lie on the same straight line and the lines
connecting those points. They just say "triangle" and the concept is
clear.

Similarily, such concepts begin to emerge in a program. Common ones
where we need to run a collection of operations in the context of using
a resource that needs to be released when we're done. Instead of
repeating that pattern throughout the program, we give it a name for
brevity and move on.

It's clear you do not understand Lisp to a level where you can make a
critical judgement such as you have.

I might even wager you don't know Python nearly as well as you think
either. Though you sound like you know it better than Lisp. I
recommend spending some real time and effort learning Lisp. Read the
seminal papers and popular books. Download some source and send in a
few patches. Come back in a few years and see if you still hold the
same beliefs and opinions.

hth,

j_king

From: Tim X on 29 Apr 2010 19:17

grucidipo <gruzcidol(a)yahoo.es> writes:

> On 29 abr, 10:25, Tim X <t...(a)nospam.dev.null> wrote:
>> grucidipo <gruzci...(a)yahoo.es> writes:
>> > 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.
>>
>> Its a false question, like asking what do you think is more important
>> feet or hands. Personally, I want both.
>>
>> --
>> tcross (at) rapttech dot com dot au
>
> Hello Tim, it can be a false question, we know that in the complex
> field C there is no total order, and that arrow theorem says that
> there is no a perfect scheme for voting and so on. I was expecting
> some subjective reflections about the importance of macros and speed
> of Lisp as useful advantages with respect to Python.
>
> I agree that there is no objective way of assigning numbers to those
> factor, nor are they ortogonal wrt each other. But I think that what
> Lisper think about this factors can be useful.
>

Its not just false due to theoretical and philosophical reasons. Its
false because it is based on a false dichotomy as it assumes there has
to be a choice between the two and you cannot have both.

Apart from the difficulty of obtaining objective measurement for things
like ease of use and even speed, it will be impossible to get an
objective measurement because everyone has different experiences and
skills or operate in similar environments.

Your question is based on the assumption that one language is either
faster to develop in than the other or runs faster than the other, which
has macros, neither of which are necessarily true. Your question implied
we can have one or the other, but I find I have both and so therefore
don't need to make such a decision.

For example, given the stuff I do for a hobby, CL is both fast to code
in and runs fast enough that speed is never and issue for me. However,
at work, CL cannot do what I need and even python cannot do it as well
as the 4GL that I use. I don't know python, but I do use perl a lot and
if I substitute perl for pythin, I still find your question false. I
never find myself making a decison as to which language to use based on
speed or macros. More frequently the decision will be made based on who
else will need to maintain the code, what envrionment the code needs to
run in and what libraries are available.

If I have a really hard problem to work out and I don't know how to
start or where it will take me, I will probably prefer to use CL to
"explore" the problem. What language is used in the end will depend on
many factors, most of which are based more around politics than
technology. More often than I'd like, the prototype never gets
re-written anyway and arguments about what language should be used end
up being a moot point.

Recently, (last 4 months), I've been using CL to do many more things at
work that once I would have used perl or shell scripts for. Once I got
into the swing of it, the only real difference I've noticed is that I
now tend to enjoyu writing the scripts more than I use to. Unlike many
others who prefer CL because lisp was their first language, for me, its
one of my most recent languages (my path wrt paid programming was C ->
x86 ASM -> Tcl -> Prolog -> C++ -> Java -> Perl -> PL/SQL -> CL and for
my own personal projects I've also used pascal, elisp, scheme, ruby, clojure,
lua and a spattering of other things, but only enough to be dangerous!).
So for me, while macros are both useful and powerful, my decisions to
use CL are based more around it being different to much of what I've
used in the past and is more about challenging myself than about
technical issues. It has helped stop me from becoming jaded and bored by
allowing me new ways to explore and express solutions.

I find language debates mostly boring. In the end, its all still reduced
down to 1s and 0s and like religion, it will generally just be a basis
for argument rather than anything approaching consensus or cooperation.
Of course, I'm sure those working in the field of langauge theory would
find my statement offensive too, so I'll just back out of the room now
and try to avoid eye contact, returning to my less confronting and more
interesting repl to get some work done.

Tim

--
tcross (at) rapttech dot com dot au

| Next | Last
Pages: 1 2 3
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.