Counting occurences
in [Lisp]
|
Prev: Black-Jewish History FAQ - Is The Secret Relationship between blacks and jews a “hate literature”?
Next: which library to generate xml with namespaces?
From: Captain Obvious on 22 Jun 2010 05:26 ??>> You've abstracted out hash-table, but you didn't abstract out lists. R> So? There are at least four variants possible: 1. concrete hash table and concrete list; 2. abstract associative container and conrete list; 3. concrete hash table and abstract sequence; 4. abstract hash table and abstract sequence. Particularly, let's consider fourth option. It could be something like: (require :dictionary) (require :abtract-sequence) (defclass counter (dictionary) ()) (defclass sequence (abstract-sequence) ()) (defmethod add ((c counter) item) (setf (ref c item) (1+ (ref c item 0)))) (defmethod count-items (sequence) (let ((c (make-instance 'counter))) (iterate-abstract-sequence sequence (lambda (item) (add c item))))) I don't see a good reason why you prefered 2 to 3 or 4. So this was an arbitrary choice. And now you're preaching about that. This probably means that you do not understand that each abstraction is a tradeoff. And if you do not understand this, you're not the one to speak about "paedogogy". Once again, "Patterns of Software" by R.P.G. is a recommended reading for you: http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf That will help to get rid of naivety. ??>> So your code is not consistent and it is a bad example. (Unless you're ??>> willing to teach inconsistency.) R> Huh? I have no idea what you mean by that. That's because you're retarded.
From: Captain Obvious on 22 Jun 2010 12:03 R> There's a lot of data from programming as well. Languages that offer R> abstract maps as core constructs (e.g. Python, Javascript, PHP) Common Lisp's hash tables are as abstract as those. R> seem to get more traction with beginners more than those that don't. Traction with beginners is not what programming languages should be optimized for.
From: Nick Keighley on 23 Jun 2010 03:11 On 18 June, 23:31, "Captain Obvious" <udode...(a)users.sourceforge.net> wrote: > BF> You're arguing about LOC, Ron is arguing about correct abstraction.. > > There is no such thing as a "correct abstraction." > If code works, it is correct. until you try to change it... The beginning of wisdom for a [software engineer] is to recognize the difference between getting a program to work, and getting it right. -- M A Jackson, 1975 > Otherwise, we can put a shitload of abstractions on top of it -- but will it > make it better?
From: =?iso-8859-1?Q?Bj=F6rn?= Lindberg on 28 Jun 2010 08:31
wrf3(a)stablecross.com (Bob Felts) writes: > Tim Bradshaw <tfb(a)tfeb.org> wrote: > >> On 2010-06-18 17:59:32 +0100, RG said: >> >> > dictionary.lisp is only 295 LOC including comments and blank lines. Even >> > if you add in rg-utils (only a tiny part of which is used by >> > dictionary.lisp) that's only an addition 970 LOC. That is not "huge" by >> > any stretch of the imagination. >> >> It's about two orders of magnutude larger than simple versions of >> occurrence-counting funcions using alists or hashtables (both of which >> come out at around 7 lines without comments, so maybe 9 with): > > You're arguing about LOC, Ron is arguing about correct abstraction. I > have to side with Ron on this one: getting the correct abstraction is > paramount above everything else. Small LOC is good if the abstraction > doesn't matter; it's easy to change programs with small LOC. "The correct abstraction", in the case that you want to be able to easily change the underlying implementation, is two or three functions which govern access to the underlying hash table. These you can write on a per application basis. No large library is needed. This approach has two advantages: your accessors can have names meaningful to your application, and they can be designed to better suit the access pattern of it. A generic, complex library is very likely not "the correct abstraction" for any particular application. I wonder if this is not an issue of reusing code for the purpose of reusing design. I would argue that code is interesting to reuse if it performs something useful, and that design is better done in the application itself. Bj�rn Lindberg |