pro

pro@common-lisp.net

344 discussions

[pro] Learning Lisp the Bump Free Way
by Daniel Weinreb 21 Jan '11

21 Jan '11

This is a very nice essay to help people get over their initial problems with Lisp: http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way I also just came across an online book called "Successful Lisp", by David B. Lamkins (maybe many of you already know about this): http://psg.com/~dlamkins/sl/ It's also available from Amazon, in trade paperback (300 pages). http://www.amazon.com/Successful-Lisp-How-Understand-Common/dp/3937526005/r… I'm not sure whether we need any more Lisp textbooks now that we have Practical Common Lisp, but it's somehow just nice to know that there are more books about Lisp that managed to get published; at least in the sense that Amazon has it (the web site of the publisher seems to have expired). -- Dan

16 22

[pro] simple-style-warning
by Vladimir Sedach 21 Jan '11

21 Jan '11

Is there a portable way to create a simple-style-warning condition that when signaled with WARN won't cause SLIME to claim that file compilation failed, that works for all/most CL implementations? I'm trying to use this: (define-condition simple-style-warning (style-warning simple-warning) ()) (found in one of KMP's usenet posts: http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/c55278c8…) but it works inconsistently in SBCL and CCL. Thank you, Vladimir

3 2

Re: [pro] Learning Lisp the Bump Free Way
by Vladimir Sedach 21 Jan '11

21 Jan '11

I really didn't appreciate this whole discussion, but I think I can contribute a few points about how to think about the problem so that things like this will stop happening. There are two assertions being made here: * "Lisp is falling behind" * "To stop Lisp falling behind, we need to do <X>" No one has provided any quantitative evidence for either. How is Lisp "falling behind?" Compared to what? And what effect does that have? What effect does that have on you personally? Why do you think doing <X> will be good? Did anyone ask for <X>? Is it actually preventing people from doing things? How can you tell <X> will work when you can't even quantify the "falling behind" thing <X> is supposed to change? What is the basic pattern behind this argument? Alexander, I will use your original post as an example, please don't take it personally: "Lisp is dying: some JavaScript implementation is slower than Clozure; let's work on the Clozure IDE!" Where is the logic here? Most of these arguments use "Lisp is dying" handwaving to promote a personal project, and in most of these cases no one outside the current Lisp community cares about the issue. What does it mean to say "Lisp is falling behind?" There aren't enough people using it? Have you tried listening to people who have tried and failed to use Lisp? Do you understand the difference between a reason and a rationalization? There are people who rationalize not using Lisp by saying it has parentheses, and there are people who have a reason for not using Lisp because they can't find the libraries they need. Listening to the former is a waste of time, listening to the latter will give you a way to actionably decrease the "Lisp falling behind" and measure it. Here are some things I notice people actually saying: 1. The #1 problem is that people (and this includes even people who have been using Lisp for decades and post to this list, not going to name names :)) have misconceptions about what current Lisp implementations, libraries and tools can do. And this is just the people that know about the existence of Lisp. Simply letting people know about Lisp and how great it is is the most direct way you can get more people to use it. 2. There are no libraries to do <X>/I can't find any libraries. Improve and promote the existing libraries. Write new ones for some service/software/function that isn't possible from Lisp yet. Put a description of your library on CLiki, ask Zach to add it to Quicklisp. Help improve the existing library listings in CLiki. Help with Quicklisp, add metadata and search stuff to Quicklisp projects (https://github.com/quicklisp/quicklisp-projects). Give Zach money. Basically anything that makes Quicklisp better is good. 3. How do I deploy applications? Web apps (the story here is incredibly bad - http://stackoverflow.com/questions/2458805/nohup-sbcl-ubuntu-couldnt-read-f… Work on cl-launch, lispx-proxy, cl-daemonize This is today's list, it will change tomorrow. The important thing is to understand what's really going on, and the psychology behind it. Which is why the last thing I'm going to say is that saying "Lisp is dying" is destructive. If Lisp experts are saying our community is a loser, why would anyone want anything to do with Lisp? Stop doing it. ------ Now I'm going to reply to Dan. I think ITA's attitude of "I wish we didn't write qpx in Lisp but it's the only thing good enough" is bizarre. That no one was assigned even part time to be a "Lisp evangelist" was a *strategic* mistake. It would have saved ITA hundreds of thousands in recruitment costs, and improved productivity through an improved Free Software Lisp ecosystem. Another thing is the "I won't be allowed to use Common Lisp" attitude. This is the perfect opportunity to force Common Lisp into Google, and you're walking in expecting to fail. Vladimir

1 0

Re: [pro] Learning Lisp the Bump Free Way
by Alexander Repenning 20 Jan '11

20 Jan '11

Hi Drew, perhaps the point of a mailing list for professional lisp developers is to act, well ... professional? Remember one of the points made in original article about the Lisp community: "The community isn’t nearly as blood thirsty as some people might portrait it." Seems to me you just confirmed what many people appear to worry about. Well done. Alex On Jan 20, 2011, at 10:57 AM, Drew Crampsie wrote: > On 20 January 2011 08:04, Alexander Repenning <ralex(a)cs.colorado.edu> wrote: > >> Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it. > > I participated in the creation of this mailing list in part to get > away from trolling like this on the other lisp forums. Is there no > place on the interwebs safe from such bullshit? > >> The 21 century computer science world need no more essays explaining why Common Lisp is the way it is (stale). > > And i'm not convinced a mailing list for professional lisp developers > needs more diatribes explaining how _we_ should 'fix' Common Lisp to > make it 'cool' again. > > Can we leave this sort of drivel on comp.lang.lisp where i have > plonk-ability, and keep this mailing list for "people who already know > and use Common Lisp and who don't want to discuss the > merits of it or how other languages are worse or better"? > > Cheers, > > drewc > > > > > > On 20 January 2011 08:04, Alexander Repenning <ralex(a)cs.colorado.edu> wrote: >> One point made: >> >>> It’s probably faster than most dynamic languages. >> >> is still mostly true but as I am tracking the speed of JavaScript versus Common Lisp I can see a scary performance cross over point in the near future (months). Already, in some of our benchmarks JavaScript running in OS X Chrome is getting very close (10% gap) to Clozure Common Lisp. Why is that? Common Lisp has gone STALE. The Common Lisp community preserves Lisp instead of advancing it. The result: flatline! As far as I can tell non of the exciting JIT compiler technologies developed in the last couple of years have made it into any CL implementation. If you follow this trend you may conclude the right thing to do, if you want to continue to use Lisp, would be to compile it down to JavaScript, yes, JavaScript, not C or direct to binary. >> >> Same thing with IDEs: stale, flatline.. Perhaps with the exception of LispWorks it appears that most Lisp programmers are just fine with Emacs. Well, Emacs was great 35 years ago. Remember the actually innovative IDEs of Lisp on Lisp machines? Is SLIME really the best we can do now? Take Clozure CL. As far as I can tell most people, including some the developers perhaps, are using SLIME too. Start using something new. For instance start using the Cocoa based CCL IDE. Yes, still primitive but with real opportunities to create some fine IDE tools that actually would look OK even to a 21 Century computer science students. Nowadays, even browser (e.g., Safari and FireFox) have debugging tools built in that make SLIME look like last century technology that belongs to a computer museum. >> >> The Lisp community is not only small but also fragmented. The 21 century computer science world need no more essays explaining why Common Lisp is the way it is (stale). It is time to leap into action and to IMPLEMENT stuff that is not just interesting to the Common Lisp community but to computer science in general. Play with Clozure Common Lisp the IDE version (Mac and Window). Do not just get frustrated and switch back to Slime but ask yourself "what can YOU do for Common Lisp (or more specifically CCL) to make it cool again" >> >> best, Alex >> >> >> >> >> On Jan 19, 2011, at 3:06 PM, Daniel Weinreb wrote: >> >>> This is a very nice essay to help people get over their >>> initial problems with Lisp: >>> >>> http://pavelpenev.posterous.com/learning-lisp-the-bump-free-way >> >> Prof. Alexander Repenning >> >> University of Colorado >> Computer Science Department >> Boulder, CO 80309-430 >> >> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf >> >> >> >> _______________________________________________ >> pro mailing list >> pro(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/pro >> Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf

7 9

[pro] Style issue about predicates
by Daniel Weinreb 16 Jan '11

16 Jan '11

If you have a function that is a predicate, in the sense that the function's contract says that its value should be interpreted as being either false or true, do you think it's better to code it so that it always returns "t" for the true case? Since Common Lisp is quite clear that when a value is being considered in the context of being true/false, nil means false and everything else means true. So from a language point of view, even considering the "intent" of the definition and not just the spec, there is no need to return t. Furthermore, the contract of the function should make it clear that the returned value is an a true/false context. This should be in the doc string, or at least in a comment, and the function name should end in "p" (or always "-p" but let's please not get into that in this email thread). So the caller should know. All that said, it's possible that a programmer will fail to heed the contract, simply look at the code, and take advantage of the returned value in more than true/false context. If you want to prevent that, you can do something like: (defun ... ... (when (fn1 arg2 arg2) t)) It seems that it might depend on the circumstance: how likely do you think it is that a programmer would commit such a mistake? The more potentially valuable the returned value is, the more likely. On the other hand, if it's so valuable, maybe you should actually make that part of the contract rather than making the function have the contract of a predicate. Is this good, bad, don't care, depends on the circumstance? -- Dan

9 8

Re: [pro] Style issue about predicates
by Bob Kerns 15 Jan '11

15 Jan '11

Agreed. As I indicated later, throwing away useful information wasn't my intent -- having a tight, well-defined contract was. T serves that purpose, but other values may also serve it and add utility at the same time. The WORST case, in my mind, is to return something useful, but leave the contract as "non-null". This encourages programmers, who may or may not have observed the contract wording, to experimentally observe the actual behavior, and depend on it. It's probably even more likely in Lisp than in most languages, because it's so easy to type a test case into a read-eval-print loop. I am not generally dogmatic that all aspects of all behavior need to be tightly specified. For example, there can be substantial performance benefits to leaving traversal/iteration orders unspecified, or there can be substantial benefit from implementation freedom, or it can be completely impractical to write a full specification. But return values, especially boolean return values, are well worth consistently specifying tightly. And I think there's little danger of a religion arising based on it -- and it'd be a relatively harmless one even so. ----------- Date: Sat, 15 Jan 2011 15:23:48 +0100 From: "Svante Carl v. Erichsen" <Svante.v.Erichsen(a)web.de> Subject: Re: [pro] Style issue about predicates Hi! I would not like such a rule in a style guide, for fear of religious followers. My view is: yes, tighten the contract, but no, it needs not (but may) specify exactly t. If something useful can be returned, why throw it away?

1 0

Re: [pro] Style issue about predicates
by Bob Kerns 15 Jan '11

15 Jan '11

Just to clarify my earlier stance: I agree -- if there's something well-defined and more useful than T to return, return that. It's the 'null/non-null' contracts that are problematic. The extra wiggle-room here offers no utility at all. It does allow for one branch of an implementation to avoid a constant load, or in some cases a test/branch and load. In this day and age, I do not find small constant bits of CPU compelling, in contrast to matters that affect reliability of large-scale software, when coded by real-world teams of programmers. ---------------- Date: Fri, 14 Jan 2011 17:59:52 +0100 From: Edi Weitz <edi(a)weitz.de> Subject: Re: [pro] Style issue about predicates There are lots of functions in the standard which are predicates in that they return generalized booleans but on the other hand return something "useful" if the result is not NIL, e.g. MEMBER or STRING<. I think this is good practice, i.e. return something other than T in case this might make more sense. Of course, this should then be documented in the predicate's contract and thus should be OK to use by the caller.

1 0

Re: [pro] Style issue about predicates
by Bob Kerns 15 Jan '11

15 Jan '11

Dan, my firm-but-not-rabid opinion on this has been formed from decades of tracking down portability bugs, irreproducible bugs, etc. Return 't'. Try to get the contract tightened up to specify t. But so long as the contract is loose, in testing it can be useful to try to inject defects by returning other values. For any one instance of this, the odds of there being a bug based on the return value is low. But given how many functions return boolean values, the odds of none of the calls to them having a bug aren't so good. Making everything return 't' as a matter of standard practice has the potential to eliminate quite a number of bugs (in the sense of bad behavior, rather than in the sense of incorrect coding). It's not just Lisp that has this problem. I've seen quite a number of C/C++ bugs where code erroneously depended on a return value of 1 or -1 or odd/even or positive/negative when it should have been zero/non-zero. A similar area is when algorithms are sensitive to the order of traversal of hash tables. Java supplies LinkedHashTable and LinkedHashSet, which is one approach to removing this variability. In both cases, the real issue isn't so much that there can be bugs. It is that the bugs that can result, have the potential to be very hard to reproduce, test for, and eliminate. An API contract that doesn't leave this sort of wiggle room makes for much better testability. Of course, if everyone follows this rule, there's no need for: (when (fn1 arg2 arg2) t) because fn1 would have returned t or nil -- unless you have an actual mismatch/conversion of contract. In that case, I argue that it is best to actually capture that intent in the code, as well as all the benefits above. But perhaps it should be written: (not (eq (fn1 arg2 arg2) null)) and reserve when for actual control-flow matters, rather than boolean operations. Date: Fri, 14 Jan 2011 11:42:16 -0500 From: Daniel Weinreb <dlw(a)itasoftware.com> Subject: [pro] Style issue about predicates If you have a function that is a predicate, in the sense that the function's contract says that its value should be interpreted as being either false or true, do you think it's better to code it so that it always returns "t" for the true case? Since Common Lisp is quite clear that when a value is being considered in the context of being true/false, nil means false and everything else means true. So from a language point of view, even considering the "intent" of the definition and not just the spec, there is no need to return t. Furthermore, the contract of the function should make it clear that the returned value is an a true/false context. This should be in the doc string, or at least in a comment, and the function name should end in "p" (or always "-p" but let's please not get into that in this email thread). So the caller should know. All that said, it's possible that a programmer will fail to heed the contract, simply look at the code, and take advantage of the returned value in more than true/false context. If you want to prevent that, you can do something like: (defun ... ... (when (fn1 arg2 arg2) t)) It seems that it might depend on the circumstance: how likely do you think it is that a programmer would commit such a mistake? The more potentially valuable the returned value is, the more likely. On the other hand, if it's so valuable, maybe you should actually make that part of the contract rather than making the function have the contract of a predicate. Is this good, bad, don't care, depends on the circumstance? -- Dan

2 1

[pro] Initialization of shared slots
by Didier Verna 10 Jan '11

10 Jan '11

The following message is a courtesy copy of an article that has been posted to comp.lang.lisp as well. Until now, I've been uncounsiously relying on something that the standard does not seem to specify: the fact that shared slots equipped with an initform are initialized before the first instance is created: (defclass test () ((slot :allocation :class :initform t))) (defmethod initialize-instance :before ((test test) &key) (format t "Slot boundp: ~A~%" (slot-boundp test 'slot))) * (make-instance 'test) Slot boundp: T * (make-instance 'test) Slot boundp: T I just realized that because with ABCL (and contrary to the other implementations I've tried), the result is NIL, and then T. But now, I'm a little confused. Section 7.1.3 of CLHS says: An :initform form is used to initialize a slot only if no initialization argument associated with that slot is given as an argument to make-instance or is defaulted by :default-initargs. So after re-reading this (the "only" part notably), it now appears to me somewhat abusive to initialize shared slots earlier than at first instance creation time (like most lisps seem to do), because there's no way to know, at that time, whether the fist call to make-instance will provide an initarg. WDYT? Related to this is a question of style as well. I rarely use shared slots, but until now, I thought of it as a convenient way to encapsulate information that's supposed to be used by instances only (including the first one). Maybe this is not a good idea after all... -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

9 28

[pro] List of Lisp consultants/freelancers
by Vladimir Sedach 08 Jan '11

08 Jan '11

The consultants page on the ALU wiki (http://wiki.alu.org/Consultant) seems out of date. I'd like to have somewhere to point managers or business owners to where they can get professional-level help for professional-level prices. Who here is/knows CL consultants and freelancers? Please add/encourage them to add themselves to the ALU consultants page. If there's another directory you think should be used instead, please let me know. The immediate motivation is that LinkedIn gave me some free ad credit, and I'm planning to use that to run some ads targeted at software managers and pointing to https://sites.google.com/site/beatingtheaveragescl/ (feedback on that idea and landing page appreciated as well). Vladimir

3 2

← Newer
1
...
28
29
30
31
32
33
34
35
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

pro