While we're on the topic of a literate Github, let me just point out
that we might want to go just a little beyond Github to the way we
write code itself. Look again at the capitalize-every-word function I
defined above. In my original unshortened commentary, I included also
this:
.............
To split a string into words (in the simplest case):
Split the string on a separator, the canonical one being space, but
also including punctuation characters such as ",';:./(){}-+_|\
BUT: Re-assembling the string will not reproduce the old string in
general unless space is the only character that splits. In order to
preserve this simple abstraction, we would need to rewrite split and
assemble. We could also change the string in-place.
Ossia: To split a string into words:
Split the string on space. Use clojure.string/split.
.............
You can see that I am writing here not only about the current good-
enough implementation, but a \future implementation, should it ever be
needed. In fact, I discovered a bug in my code before I ever wrote
the code; but the question is what to do about the bug!
What I really want you to notice is how we are faced with a choice:
either we improve the library code (presumably by making split
optionally return an array of separators matched by the regex for
later reassembly by join, perhaps in metadata of some sort), or we go
with a less felicitous abstraction. There probably should be some
sort of formal analogue to this decision point in the natural language
text.
What does this mean for a Github? It may mean----and no doubt this
will be controversial----that once we have the capability of a
function search engine, we don't really worry about there being
canonical library code any more. If I face this particular problem,
maybe I decide to re-write Join and Split to my own specifications. I
then put them out there under my own namespace, and when someone needs
to use them they just type (use '[nchurch :only join split]) wherever
they are in their file, or whatever the exact incantation is (this is
one place I always need to go to the docs....). They have no trouble
browsing multiple alternatives, because they can see at a glance how
each one differs.
Now we have possibly multiple joins and splits; and so the community
no longer has a standard! Well, it would seem to me this fits well
with Github's always-fork philosophy. I do think there is only one
way to write a good library function, but it may be that there will
need to be a proliferation of alternatives----each making its own
argument and tradeoffs across various levels of abstraction, to return
to the theme of literate programming----before an optimal basis is
discovered. (There must have been a time before phillips head vs.
regular.....) And when that happens, perhaps it goes into
clojure.string (modulo legalities about contributor agreements----
something that might also be handled at the Github level, by the
way.).
On Dec 22, 11:19 pm, nchurch <nchubr...@gmail.com> wrote:
> I'll do everything I can to help. I have tons of thoughts (as you
> might guess); but I haven't demonstrated myself to be a great coder,
> yet. I feel like I'm a coder who needs something like literate
> programming to be great, so it's kind of a chicken-and-egg problem.
> I'm already partway there with the existence of Clojure, but although
> it's the most intelligent language I've every come across (and it is
> at least Lisp), it still isn't enough.
>
> On Dec 22, 11:14 pm, daly <d...@axiom-developer.org> wrote:
>
>
>
>
>
>
>
> > On Thu, 2011-12-22 at 17:53 -0800, nchurch wrote:
> > > Firstly, there really needs to be something like a Github for literate
> > > programming.
>
> > What a great idea!
> > I'll see what I can do.
>
> > Tim Daly
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
