Comparing Lisp to Python, what you consider more important: speed or macros.
in [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: His kennyness on 2 May 2010 20:07 Duane Rettig wrote: > On Apr 30, 10:18 pm, "Scott L. Burson" <g...(a)zeta-soft.com> wrote: >> On Apr 29, 6:42 am, J Kenneth King <ja...(a)agentultra.com> wrote: >> >>> grucidipo <gruzci...(a)yahoo.es> writes: >>>> 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. >> Oh, I beg to differ. (And I'm very surprised no one else has >> challenged this.) > > It just gets tiring making that challenge for the Nth time. Also, he > is obviously not talking about CL macros. He can't abide the new- > language argument because he has obviously never abode in a new > language constructed with CL. Puh-leaze. Every English speaker abiddeds in a macro language. Macroexpand any Shakesperean sonnet and what do you get? Nothing but a bunch of arithmetic! Mostly 0s and 1s at that! hth. kxo
From: Pillsy on 3 May 2010 10:29 On May 3, 5:18 am, "Captain Obvious" <udode...(a)users.sourceforge.net> wrote: [...] > I'm not saying that macros are _too hard_. They are just (relatively) harder > than writing an average code. I don't know, maybe it should be that way, or > maybe not. There's always an extra step, right? > From my experience: > * writing code is usually easy. I can just say "I need a function that does > this and this" and then write it in a few minutes, and usually it just works > without debugging. With a function, you have something you want to do, and you write code that does it. With a macro, you have something you want to do, and you write code that writes code that does it. You have to solve two problems instead of one. [...] > * writing macro-writing macros is goddamn hard. I need to think a lot about > each line. It never works right from the first time, it needs > trial-and-error process. Now you've got at least three problems to solve instead of one. In these cases you often have to have a good understanding of the different phases in the life of a Common Lisp program (load time and compile time and macroexpansion time and all the rest) which is goddamn hard in its own right. [...] > IMHO general macros (where you need a full power of CL code to make an > expansion) are rarely needed. A lot of macros are just backquote templates > with little code fragments which do interesting things. Can we make nested > backquote templates more manageable? I think we can. Absolutely we can. The tools standard CL provides for writing macros are surprisingly weak when you think about it---you have backquotes, DESTRUCTURING-BIND, and a bunch of general purpose list- and sequence- manipulating constructs. There's a lot of things out there that would make it easier, like pattern-matching, that you either have to provide yourself, get a library, or do without. Providing those things yourself isn't necessarily that hard, but the gulf between "not much work" and "no work" is gigantic. Which is a big part of why macros are so appealing in the first place. Cheers, Pillsy
From: Bigos on 4 May 2010 13:54
On Apr 29, 7:44 pm, grucidipo <gruzci...(a)yahoo.es> wrote: > On 29 abr, 16:06, Nick Keighley <nick_keighley_nos...(a)hotmail.com> > wrote: > > > > > > > On 28 Apr, 20:27, grucidipo <gruzci...(a)yahoo.es> 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. > > > why did Python score 0.4 for macros? Does python have some sort of > > macro facility? > > Python has eval, so you could construct a macro using strings and > eval. There is not standard library for macros in Python, but I think > using eval is a good tool to build a library for using macros. The > point is that people using Python don't think macros are useful for > them, so I don't know any library for making macros with python. > > I score 0.4 for macros because I think 1) it can be done, 2) in the > usual work with python I don't miss macros. > > Nick, thanks for being a real Kind. Don't know much about Python, but Ruby has eval too. In my opinion when you try using eval to simulate macros in Ruby then suddenly Ruby looses all it's syntax beauty and code looks like an entry for code obfuscation competition. That's why such practices are considered as ugly hacks and usually avoided. Lisp on the other hand doesn't seem to look any worse when you try to use macros. So maybe besides having proper macros Lispers also should appreciate this fact as well. Here is my attempt to add C style for loop to Ruby #! /usr/bin/ruby1.9.1 #C style for############################################ def cfor( args, code) macro1="#0 while #1 puts x #{code} #2 end" args.each_index {|index| macro1["##{index}"]=args[index]} puts macro1 eval macro1 end cfor ['x=0','x<5','x=x+1'], 'puts "hello"' Do you have his impression that having only ( and ) brackets makes code look better and more consistent? |