Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
jgrant27
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
17 ms
·
151.
▲
by
jgrant27
17y ago
The new graphs are up too.
152.
▲
It's good to be wrong (about Lisp performance)
(jng.imagine27.com)
18 points
by
jgrant27
17y ago
|
1 comments
153.
▲
A followup to "I want to believe in (in Lisp vs. C performance)", and a challenge ...
(imagine27.com)
2 points
by
jgrant27
17y ago
|
0 comments
154.
▲
by
jgrant27
17y ago
http://news.ycombinator.com/item?id=591897
155.
▲
by
jgrant27
17y ago
It's ironic that this was posted as the same day as this --> http://news.ycombinator.com/item?id=591897 Would be interesting to see how a version in Clojure compares.
156.
▲
by
jgrant27
17y ago
It's ironic that this was posted as the same day as this --> http://news.ycombinator.com/item?id=591897 Would be interesting to see how a version in Clojure compares.
157.
▲
by
jgrant27
17y ago
Agreed
158.
▲
by
jgrant27
17y ago
Relax and don't be afraid (your language is safe) and always will be. The C version is not fully optimized (yes it's naive) and this was intentional and stated in the article (perhaps not clearly enough). A fully optimized C version would r
159.
▲
by
jgrant27
17y ago
You mention that the reason for lower performance of Lisp vs. C has to do with a lack of motivation. This couldn't be further from the truth. Have a look at the source repos for SBCL, Clozure or any other dozen Lisp implementations or diale
160.
▲
by
jgrant27
17y ago
exactly and this is clearly stated in the article.
161.
▲
by
jgrant27
17y ago
Does it have anything comparable to Lisp macros ?
162.
▲
by
jgrant27
17y ago
Yes yes but they are optionally imperative but were first functional. "system maintenance" for the url that you posted.
163.
▲
I want to believe (in Lisp vs C performance)
(imagine27.com)
20 points
by
jgrant27
17y ago
|
19 comments
164.
▲
Recent obscure western and sci-fi movies
(jng.imagine27.com)
4 points
by
jgrant27
17y ago
|
1 comments
165.
▲
by
jgrant27
18y ago
That would depend on who's using the word "usually". See Norvig's "Paradigms of Artificial Intelligence Programming - Case Studies in Common Lisp", Chapter 8 - Symbolic Mathematics : A Simplification Program, 8.6 - Integration, page 252. h
166.
▲
by
jgrant27
18y ago
I'm not going to implement that for you. Sorry. See Norvig's "Paradigms of Artificial Intelligence Programming - Case Studies in Common Lisp", Chapter 8 - Symbolic Mathematics : A Simplification Program, 8.6 - Integration, page 252. http:/
167.
▲
by
jgrant27
18y ago
Absolutely not. Nested functions are LEXICALLY scoped in CL. Why the aversion ?
168.
▲
by
jgrant27
18y ago
There's recursion and then there's tail recursion. Recursion is idiomatic of all functional languages. Using the loop macro as in your example is iterative and hence some of the contention about whether that is idiomatic for a functional la
169.
▲
by
jgrant27
18y ago
Nothing at all. The loop macro version is iterative and the original is recursive. However some things are easier to represent recursively than iteratively. That is if the programmer clearly understands recursion.
170.
▲
by
jgrant27
18y ago
Interesting opinion regarding my style. Thanks for explaining. There are many things in the CL spec that are very contentious. Arguably too many. Dan Weinreb pointed this out earlier in the week( http://ilc2009.scheming.org/node/7 ) which i
171.
▲
by
jgrant27
18y ago
The code compiles and runs just fine on any CL compiler. Try SBCL or CLozure CL. Actually the loop macro in CL can be a very contentious topic. I'd hardly refer to the loop macro as idiomatic. Imperative and functional styles in CL can bot
172.
▲
by
jgrant27
18y ago
agreed
173.
▲
by
jgrant27
18y ago
What else does integration primarily entail ?
174.
▲
Integral Calculus in Lambda Calculus (Lisp)
(jng.imagine27.com)
18 points
by
jgrant27
18y ago
|
20 comments
175.
▲
Live Lisp coding as art
(imagine27.com)
40 points
by
jgrant27
18y ago
|
17 comments
176.
▲
by
jgrant27
18y ago
http://jng.imagine27.com/articles/2009-04-07-135246_cl_hard_...