Re: Parallel Programming with Lisp for Performance
The Parallel Programming with Lisp for Performance talk was given at the European lisp conference. http://medias.ircam.fr/xe5f73b At around 13:00 he mentions STM and comments that it works but is not good for performance. At around 14:00 he mentions livelock where STM process 1 does a rollback causing process 2 to do a rollback causing process 1 to do a rollback ... etc. Anyway, an interesting talk. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
non-literate, excellent documentation style
Giving my LP horse a rest I'd like to call your attention to backbone.js and the way they arrange documentation. It is less of a story form or why explanation and more on the details which are not apparent in the code. I don't know what tool was used to create it. http://backbonejs.org/docs/backbone.html 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Code Poetry
Ok, so I'm a bit over the edge about how good code should be written, as many of you might have guessed... but it could be worse: http://sourcecodepoetry.com good code reads well, best code rhymes and, best of all, it is a contest! Tim Daly /me mutters about being one-upped :-( -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Heidegger, literate programming, and communication
Forward from Ralf Hemmecke: On 05/22/2014 11:21 AM, Gregg Reynolds wrote: I can tell you I would rather maintain the four lines of C++ without the largely useless commentary. That's a simple AXIOM program, but I'm sure one can easily translate it into any programming language. foo(a: Integer, b: Integer): Integer == if a 0 then if a b then return foo(b,a) return foo(b-a,a)) return b Question: Does the program have a bug? Ralf -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Heidegger, literate programming, and communication
Tim, as someone already mentioned, the multi-page Java code you posted from the Clojure core is actually one file from the Java ASM library, copied into the Clojure Github repository from one version of that library available from here: Hmmm, I didn't see that in the documentation :-) Thanks for the warning. In order to write the book I took a clone of the repository at a particular time with the intention of walking up the diffs after I had a clue about the details. There are 18,821 lines of Java code in that library, as it has been copied into Clojure in the src/jvm/clojure/asm directory. Oh, good. That means I can read the library documentation :-) I would strongly recommend that you *not* spend a lot of time reading and documenting that code, if you want to document things that are unique to Clojure. That library is used by other projects besides Clojure. Between Clojure 1.5.1 and Clojure 1.6.0, a new version of it was copied over the older version that was used before then. http://dev.clojure.org/jira/browse/CLJ-713 That will likely happen again in a future Clojure release, to better support JDK8: and again for JDK9... and again for JDK10... and again for... If Clojure needs the library then it needs to be documented. I am using a reference model. If code references a function then document the function. If no code references the library then it won't get documented. Any living piece of software is going to have changes made but I'm hoping that the core remain reasonably stable. Assuming, of course, I can distinguish core code. Reading code is SO much fun :-) Anyway, thanks for the warning. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Axiom-developer] Heidegger, literate programming, and communication
PS I have many chunks of code that I wrote 20-30 years ago and I have no idea why and what the code was written for even after reading each line of the code This is what got me interested in literate programming. Axiom was written at IBM as research code, mostly by people trying to get a PhD. I wrote bits and pieces of the internals but didn't bother to document anything, especially since I write dirt simple code. Fifteen years later I'm looking at my own code. I know what it does. I can even tell you what bytes the compiler will lay down in memory. I know the code is needed since the system fails if I remove it. But I have no clue WHY I wrote it. The person who wrote the code failed to communicate with the person who maintains the code. I have the misfortune of being both people. I understand the strong opposition to writing good documentation at any level. Especially when writing code; it just seems wasteful to state the obvious. One non-obvious side effect of doing literate programming is that the code quality improves a LOT. As Bill Hart said: Another thing I've been enjoying lately is literate programming. Amazingly it turns out to be faster to write a literate program than an ordinary program because debugging takes almost no time. I fear that we're going to have the same approach as the physicists. New theories get accepted when the previous generation dies out. Fortunately statistics show that programmers retire into management at age 35 so we won't have to wait that long. If there is any justice, the managers will have to hire noobs to maintain code they wrote so they get to listen to the noobs trash talk about their code. :-) 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Heidegger, literate programming, and communication
I know Clojure doesn't have all the documentation many would like, but Tim, this bit of info is in readme.txt, and the first 3 lines of every source file from the library :-) Touche! +2 points to you! I love it when my oh-so-noisy self gets skewered by facts! :-) 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Heidegger, literate programming, and communication
The primary focus of a documentation system is communication from the author to the audience. One of the struggles apparent in discussing issues of communication, especially with programmers, is Heideggers present-at-hand vs breaking down. Programmers write programs to instruct a machine to perform some task. In the ideal, this involves communication from the mind of the programmer to the execution of the program. If the program works the first time it is all a seamless entity (present-at-hand). When the program fails, by compiler errors, missing libraries, runtime errors, design errors, inappropriate actions, or any of the other dragons of programming, the process is not seamless. The details of the process rise to our awareness (breaking down). The burden of failure is likely to fall on people who use or maintain the program rather than the authors. If the program survives, these are likely audiences. Programmers, generalizing from my own case, rarely have a seamless experience. Programs that work the first time, are correct, efficient, and all of the other properties, are rather far outside our experience. The effect of this constant breaking down is that we have learned, rather painfully, to be aware of the machinery of the process at every step of the way. This focus on the machinery becomes the expected way of communicating with the machine. Scratch any programmer, interview at any company, listen to any talk, and you find machinery. But communication from the author to the audience is the underlying theme of literate programming. Knuth's point is about communication, not about the machinery of communication. The question is, to what audience, not how. Discussions seem to get lost in a debate about the machinery rather than the goal. We focus our debate on docstrings versus markup versus wiki. We consider literate programming to be too much machinery. In these forums there is rarely find any example of present-at-hand issues of communication. That is, given a large program (e.g. Axiom, Clojure), what is it that we need to communicate, to what audience, and at what level of detail? Axiom focuses on The 30 year horizon under the assumption that the computational mathematics will be forever valid and that the audience will be unable to contact the likely-dead authors. Pharr and Humphreys' Physically Base Rendering [0] is written as a literate program, a book that won an Academy Award, using Tex and C++. The very first thing they mention in the preface is the Audience. They communicate to humans and, also, to machines. What is the audience for Clojure? Common Lisp has achieved a long-term horizon by raising the language to a standard. No standard is perfect but it does make it possible to construct programs which have a stable base for communication. That base makes it possible to write a book like Lisp in Small Pieces [1] which communicates ideas in natural language using an embedded program as a reduction to practice. So the fundamental point is what to communicate to what audience, not how to implement it. Different audiences will need different implementations (e.g. docstrings for REPL users) but we must avoid losing ourselves in the noise. Axiom, by choice, has a defined audience. Does Clojure? Tim Daly d...@axiom-developer.org [0] Pharr, Matt; Humphreys, Greg Physically Based Rendering ISBN 978-0-12-375079-2 [1] Queinnec, Christian Lisp in Small Pieces ISBN 978-0521545662 -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] Clojure RETE implementation - CLIPS-like expert system
Ryan, Does this system compile the left hand sides into a shared data structure? 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Java API is copyright protected?
At the risk of getting slightly off-topic here, here's a comment on Hacker News from a well-respected commenter on legal issues - he's a lawyer specialising in startup and technology law and his analysis is uniformly excellent. He argues that while the result may be unpalatable, it's by no means the stitch-up by technological ignoramuses that that article makes it sound: https://news.ycombinator.com/item?id=7722674 Judge Alsop conflated two distinct and non-overlapping areas of intellectual property law by claiming that a copyrightable work (the API) must rise to the level of warranting patent protection. While that's a novel idea, it is nowhere in the copyright law. (Oracle, by the way, also holds patents on Java). Where the new decision might have a direct impact on Clojure would be if someone were to create a stand-alone Clojure (or other products that enable a developer to use Java directly in their products) that was compatible with the JVM-hosted version. There would seem to be a need for API-compatible functions. Doubly so if you could excute jar files. The court could find that infringing, it seems. On April 29th, Steven Vaughan-Nichols (a lawyer) predicted that Oracle would be defeated in court [0]... and he was wrong. Text is born with copyright and the API is a text specification. The EFF lawyer [1] who provided a friend-of-the-court brief seems very unhappy with the decision. Florian Mueller [2] at fosspatents.com has a much more in-depth analysis and basically agrees with the decision. He includes detailed quotes from the Court. Google claims that Sun issued Java under the GPL2. But Oracle has the freedom to change a license on its products and has made Java API changes since the Sun Java purchase. They did the same thing with MySQL, also GPL2, which is now pay-to-play. Our trouble with the Courts, and possibly with the lawyer's reasoning, is that they are not programmers. The other problem is that they are deciding the case on what the law SAYS, not on the effects. But the judge ruled that (a) Oracle could copyright the API (b) Google infringed that copyright Google's defense rests on fair use [3] quoted below. I have learned that legalese is NOT English so words don't mean what you think they mean. Legalese is also not logical but depends on prior cases. With those caveats, I don't see that Google has any chance to prevail. Oracle can certainly claim that the listed exceptions don't apply and that the 4 listed criteria all weigh in on their side. As we all know, a widely used API has network effects... you use it because everybody uses it. That's essentially why Google chose it rather than create their own. They can leverage the huge number of programmers who already use it. It would be a challenge to convince designers creating an API to create a competing, non-infringing version. Of course, Oracle claims that their API is very valuable intellectual property, vital to their business, and copyrighted. I personally hate the Court's decision but I also think they read the law as it was intended. Oracle is not SCO; they won't go away any time soon. So what would a non-JVM Clojure do? A non-profit JVM-compatible Clojure product would potentially escape using clause (1) below [3], assuming it was used for non-profit educational purposes. Can a non-Java Clojure be defined? Tim Daly = [0] http://www.zdnet.com/blog/open-source/oracle-vs-google-dead-lawsuit-walking/10843 [1] https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracle-v-google-federal-circuit-reverses-sensible-lower-court [2] http://www.fosspatents.com/2014/05/oracle-wins-android-java-copyright.html [3] Copyright Law Exceptions (quoted for comment purposes) :-) Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phonorecords, or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright. In determining whether the use made of a work in any particular case is a fair use the factors to be considered shall include: 1. the purpose and character of the use, including whether such use is of a commercial nature or is for non-profit educational purposes; 2. the nature of the copyrighted work; 3. the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and 4. the effect of the use upon the potential market for or value of the copyrighted work. -- 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
Java API is copyright protected?
It appears that the Java API can be copyright protected. This would mean that you have to get Oracle's permission and possibly pay a fee to use it. http://www.theverge.com/2014/5/9/5699958/federal-court-overturns-google-v-oracle 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Must hear...
There is a 3rd part to this series. Enjoy... Robert Lefkowitz -- The Semasiology of Open Source (part 3) http://daviding.wordpress.com/2007/10/22/robert-lefkowitz-the-semasiology-of-open-source-part-iii-oscon-2007-it-conversations-20060726/ Tim -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
A video on programming
Literacy, Programming, and Open Source by Robert M Lefkowitz http://www.youtube.com/watch?v=JxjTsQtxn8A -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[did...@lrde.epita.fr: [clisp-list] [CfP] International Lisp Conference 2014, Aug. 14-17, Montreal]
From: Didier Verna did...@lrde.epita.fr ILC 2014 - International Lisp Conference Lisp on the Move August 14-17 2014, University of Montreal, Montreal, Canada Sponsored by the Association of Lisp Users In cooperation with: ACM SIGPLAN http://www.international-lisp-conference.org Scope: Lisp is one of the greatest ideas from computer science and a majorinfluence for almost all programming languages and for allsufficiently complex software applications. The International Lisp Conference is a forum for the discussion ofLisp and, in particular, the design, implementation and application ofany of the Lisp dialects. We encourage everyone interested in Lisp toparticipate. We invite high quality submissions in all areas involving Lispdialects and any other languages in the Lisp family, including, butnot limited to, ACL2, AutoLisp, Clojure, Common Lisp, ECMAScript, Dylan, Emacs Lisp, ISLISP, Racket, Scheme, SKILL, HOP etc. The conference proceedings will be published in the ACM Digital Library. This year's focus will be directed towards integrated solutions,including mobile computing. We especially invite submissions in thefollowing areas: * Pervasive computing Interoperability Portability Implementation * challenges/tradeoffs for embedded/mobile platforms Language * support for mobile toolkits and frameworks Language support for * distribution Language support for reliability, availability, and * serviceability Mobile IDEs Mobile applications Contributions are also welcome in other areas, including but not limited to: * Language design and implementation Language integration, * inter-operation and deployment Applications (especially commercial) * Reflection, meta-object protocols, meta-programming * Domain-specific languages Programming paradigms and environments * Efficient parallel and concurrent computation Language support for * managing both manual and automatic GC Theorem proving Scientific * computing Data mining Semantic web Technical Programme: Original submissions in all areas related to the conference themes are invited for the following categories: Papers: Technical papers of up to 10 pages that describe original results. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries and applications. Workshops: Abstracts of up to 2 pages for groups of people who intend to work on a focused topic for half a day. Tutorials: Abstracts of up to 2 pages for in-depth presentations about topics of special interest for 1 to 2 hours. Panel discussions: Abstracts of up to 2 pages for discussions about current themes. Panel discussion proposals must mention panel member who are willing to partake in a discussion. The conference will also provide slots for lightning talks, to be registered on-site every day. For inquiries about any other kind of participation (commercial exhibits, advertising, prizes, book signing etc.), please see the contacts below. Important Dates: - May18, 2014: Submission deadline - June 09, 2014: Notification of acceptance - June 29, 2014: Final Papers due - August 14, 2014: Conference All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=ilc14 Organizing Committee: General Chair: Marc Feeley (Universitie de Montral, Montreal, Canada) Programme Chair: Didier Verna (EPITA Research lab, Paris, France) Local chair: Marc Feeley (Universitie de Montreal, Montreal, Canada) Programme Committee: Charlotte Herzeel, IMEC, ExaScience Life Lab, Belgium Damir Cavar, Eastern Michigan University, USA Dave Herman, Mozilla Research, USA Greg Pfeil, Clozure Associates, USAIrone Anne Durand, LaBRI University of Bordeaux, France Jim Newton, Cadence Design Systems, France Kuroda Hisao, Mathematical Systems Inc., Japan Matthew Might, University of Utah, USA Nicolas Neuss, Friedrich Alexander Universitat, Germany Ralf Meller, TUHH, Germany Sam Tobin-Hochstadt, Northeastern University, USA William Byrd, University of Utah, USA Contacts: * General Questions: ilc14-organizing-committee at alu.org * Programme Committee: ilc14 at easychair.org -- 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
Re: Proposing a new Clojure documentation system (in Clojure)
Less trivial things that I would like to be able to do: - transclude documentation from secondary files, so that the developer of a piece of code sees a short piece of documentation, while users of code can see something longer. - expand the documentation system as I see fit; i.e. the documentation system should be designed to an abstraction, not an implementation. - include diagrams and pictures It is easy to show the red-black tree rebalance algorithm with a few pictures whereas the words are rather opaque. Stacks and immutable copy algorithms are also easy in diagrams. You CAN do this with ascii-art but it IS the late 90s and some lucky few of us have 640x480 color terminals. Tim -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposing a new Clojure documentation system (in Clojure)
Compare Emacs Lisp, for example, which uses semi-structure in the comments to drive many of its features. Speaking of Emacs, there are (at least) two doc systems available, the emacs info system and org-mode. Both of those evolved due to a need for a better documentation system. The claim has been made that what exists is all we need since, if there was MORE we need then a doc system would arise. Several dozen have arisen and are in use. Wouldn't a gif of Rich's Ant system running make the whole point of the code perfectly obvious? Wouldn't it be even better if, when you changed the code, the gif updated to reflect the new change? We have Clojurescript and browsers have a canvas element. Given that I only have a 640x480 terminal I guess ascii ants would be ok :-) -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposing a new Clojure documentation system (in Clojure)
Gregg, My original comment on litprog (bad bad bad) was admittedly a little strong. I think its bad for some things, fine for others. And it's possible litprog conventions will evolve to address the problems some of us see with using it for programming in the large etc. Could you explain what some of the problems some of us see with using it for programming in the large might be? It is hard to refute bad bad bad and other assertions without specific examples. Axiom (1.2 million lines of lisp) is being rewritten into a literate program. So far I can't think of a problem. Clojure is being reworked into literate form already and I can't see a problem other than trying to understand and explain code I didn't write (reading code is hard). The Clojure community isn't ready to make the leap into a literate world. I understand that. But Clojure is still at the stage of writing new code for new uses. There are few people who need to modify code written by programmers who left the community. That's when the need will arise for clearly communicating ideas to other humans. The technical debt has not come due ... but it will. Tim -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposing a new Clojure documentation system (in Clojure)
Adding complexity and weaving heapings of prose in amongst the code isn't going to make the developer that wrote the above rewrite it in a better way. You'll just end up with more bad documentation getting in the way of what the code actually does. Bad documentation is worse than no documentation. At least with no documentation, the code doesn't lie. Bad documentation should have to leap the same hurdles as bad code. Code review ought to be able to push back against bad documentation just as easily as it screams at bad code. There is the famous WTFs per minute cartoon that can be applied to documentation. Doing regular doc reviews might provide full employment for English majors :-) In fact, working on a WTF code review social process in Clojure might be the most effective step toward better code and documentation overall. Of course, this would have to be instituted by Rich and company since they control the sources. We could post code snippets (ref my prior post) which need explanation and do a community documentation upgrade on the Clojure sources. Tim -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
deep thinking
== Tim Daly[4] tries to find documentation criteria that include in-file comments as well as higher level organization of needed information, representing the extreme case. Consider Clojure's primary data structure implementation. It is basically an immutable, log32, red-black tree. For some people that is more than sufficient, especially if they have been working in the code base for years. For others, especially as a developer new to the project, there is a lot to know. Without this information it is very difficult to contribute. A new developer needs an introduction to the IDEA of immutable data structures with a reference to Okasaki's thesis which is online at http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf (a bibliography). A new developer needs to know that the DESIGN of Clojure relies on these immutable data structures so they don't introduce any quick and efficient hacks that violate the design. (a Clojure overview) A new developer needs to know WHAT a red-black tree is, WHY it was chosen, and HOW Clojure maps user-visible data structures to them. (the chapter on this particular data structure) A new developer needs to know the IMPLICATIONS of the choice of log32 since it defines the efficiency. (the design constraints section and the algorithmic analysis section) A new developer needs to know HOW to update a log32 immutable red-black tree. (a pseudocode explanation with pictures) A new developer needs to know HOW the log32 red-black tree is implemented. It is not immediately obvious how the 5-bit chunks are mapped into a 32 bit word. If the task was to re-implement it on a 64 bit word they'd have to know the details to understand the code. (the actual code with explanations of the variables) If the new developer's task is to modify the code for a 64 bit architecture they would need a way to find the code (the table of contents) and places where this information is mentioned (an index). All of the places where it is written need to be properly updated. Even if we focus strictly on what a new developer needs to know we end up with something that smells a lot like a book. From the above we see the need for 1) a bibliography 2) a Clojure overview 3) a chapter focus on this data structure 4) sections on design constraints and algorithmic analysis 5) a section of pseudocode with pictures 6) a section with code and details of the actual implementation 7) a table of contents 8) an index [0] Val Waeselynck clojure@googlegroups.com Wed, 30 Apr 2014 16:08:33 -0700 (PDT) [1] Steve McConnell Code Complete, Second Edition Microsoft Press, Redmond, WA, USA, 2004 [2] Ronald M. Baecker and Aaron Marcus Human factors and typography for more readable programs ACM, New York, NY, USA, 1989 [3] Simon Benjamin Orion Parent How Programmers Comment When They Think Nobody's Watching Master's Thesis, University of Waterloo, Waterloo, Ontario, Canada 2014 [4] Tim Daly clojure@googlegroups.com Wed Apr 30 03:09:05 2014 -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
deep thinking
(Just as an aside, there is a conference called Write the Docs. see http://writethedocs.org) The only way to find out is to read the code - that is, the algorithm, not just the names. (This code was documented, by the way.) In my experience clashes between the natural language semantics of function and var names on the one had, and the jobs they actually do on the other, is pervasive, and I see little chance that this will ever change. Not because programmers are dumb but because coming up with expressive and accurate names is hard and time consuming. Imagine if a physics professor said that the only way to understand anything was to read the formula... not the text documentation. In some sense it is true that the formula (i.e. code) is truth but everyone EXPECTS that the surrounding text is accurate and up to date. Otherwise, there would be a LOT of people telling the author about the mismatch. Why don't we expect the same in programming? Writing just the code is about as effective as a book containing only the physics equations with no text, correct but opaque. We CAN have accurate, up-to-date, documentation. It requires changes to the way we write software. In particular, clear and accurate documentation should be a REQUIREMENT for every change checked into a repository. We have code reviews to check for bad code. The code review should also check that the code mirrors the documentation. This doesn't require a tool, per se, but a good tool would help others navigate among the ideas. Which leads to a larger point: a genuine improvement in the Clojure documentation situation requires (IMHO) some Deep Thinking about the nature of code, the relation between code (text) and algorithm, natural language text, expressivity, programmer practices, etc. In other words, we should follow Rich Hickey's example - I take it that Clojure itself emerged from some Deep Thinking about the nature of computation, programming language design, etc. Any software designer worth his title would first collect requirements. Then each of the proposed solutions can be checked to see if they fulfill the requirements. Most of the posted ideas don't begin to fulfill the requirements. Good documentation is not a new idea. It has been thought about deeply before. I know that some people dismiss literate programming by fiat (aka it is worthless..., it can't work..., it adds nothing..., etc) but surely Knuth is a Deep Thinker on par with Rich Hickey. Knuth said: I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title Literate Programming. Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. Knuth said: Yet to me, literate programming is certainly the most important thing that came out of the TeX project. Not only has it enabled me to write and maintain programs faster and more reliably than ever before, and been one of my greatest sources of joy since the 1980s -- it has actually been indispensable at times. Some of my major programs, such as the MMIX meta-simulators, could not have been written with any other methodology that I've ever heard of. The complexity was simply too daunting for my limited brain to handle; without literate programming, the whole enterprise would have flopped miserably. If people discover nice ways to use the newfangled multi- threaded machines, I would expect the discovery to come from people who routinely use literate programming. Literate programming is what you need to rise above the ordinary level of achievement Bill Hart, on the SAGE Mailing list wrote: Another thing I've been enjoying lately is literate programming. Amazingly it turns out to be faster to write a literate program than an ordinary program because debugging takes almost no time. Ross Williams, in the FunnelWeb Tutorial wrote: The effect of this simple shift of emphasis can be so profound as to change one's whole approach to programming. Under the literate programming paradigm, the central activity of programming becomes that of conveying meaning to other intelligent beings rather than merely convincing the computer to behave in a particular way. It is the difference between performing and exposing a magic trick. -- 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
research on documentation
How Programmers Comment When They Thin Nobody's Watching http://www.cgl.uwaterloo.ca/~commenting Documentation is essential to software development. Experienced programmers know this well from having worked with poorly documented code. They wish to improve their documentation techniques and habits, but there is little consensus for them to follow. Somehow, the many different standards must be compared objectively. -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposing a new Clojure documentation system (in Clojure)
the skill to create any technology we want. The problem is social. There needs to be a focus on creating professional standards. We need to raise the bar of what we expect as world-class professional programmers. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposing a new Clojure documentation system (in Clojure)
Phil, I like the general idea of the Valentin's proposal, but I don't understand every bit of it. It sounds complicated. Personally, I'd rather see something that's relatively simple, and good enough, than something that's perfect but unwieldy. If it's too difficult, people won't use it, or they'll waste time, or feel that the Clojure community expects them to spend too much time on something that detracts from what's important. Can I ask, quite seriously and not intending any sarcasm, what you mean by detracts from what's important? For me, what's important is to communicate ideas, designs, and details from one developer to another so that others can maintain, modify, and extend what exists. I've already held forth on what I think that implies so I won't bore you with it. What I don't understand is your criteria for what's important and how that translates to action. If we can agree on what's important then the technical details would have common criteria for simple and good enough vs something that's perfect but unwieldy. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
emacs + org-mode + ?
The python community has a track on reproducible research. I'd really like this to catch fire in Clojure (who would have thought?) See this, from their conference: http://www.youtube.com/watch?v=1-dUkyn_fZA We already have slime to make life easier. Now is the time to really upgrade your professional standards you expect for a professional programmer. Tim Daly Curmudgeon at large -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Academy Award goes to a literate program
From http://lambda-the-ultimate.org/node/4876: Matt Pharr, Greg Humphreys, and Pat Hanrahan have recently been given an Academy Award for Technical Achievement, for the book Physically Based Rendering. This is the first time the award has been given to a book and (more relevant to LtU) the first time a literate program has won an Academy Award. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Lisp in Tex
TeX is viewed as a document markup language but it is turing complete. Occasionally people get ambitious. Here is executable lisp in a Latex document: ctan.org/pkg/lisp-on-tex Perhaps some bright spot can do a Clojure-in-tex during the next Google summer of code :-) 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: IDE feature
Find me a person who fluently used paredit that stopped and reverted back to manual parenthesis manipulation. /me raises my hand. Structural editing was useful in LispVM (on IBM mainframes) where the display was 12 lines by 40 characters. It might also be useful for the iPad lisping app. If your IDE uses 80% of your display for buttons, lines, and icons I can see where it would be useful, since most of the text area is gone. However, I've been programming in lisp for 42 years on everything from punched cards to mega-displays. I find that keeping structure and counting parens is like finishing a thought. It just happens. I don't remember the last time I had a paren-balance bug. I've spent the last 13 years rewriting and refactoring Axiom which is 1.2 million lines of lisp code so I have a fair sized sample as a test case. I find that programming occurs in my head and that the computer is only useful for recording the results. For me, smart editing and IDEs get in my way, like a helpful newbie in a metal shop. Then again I don't use IDEs. If it works for you, go for it. Tim -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Story
Re: org-mode. I stand corrected. Some days my religious zeal overwhelms my fingers. Thanks for setting the record straight. Tim -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Story
I'm with you 100% on the mind-blowing greatness of literate programming, Actually, it's not the technology of literate programming I'm on about. Rich Hickey comes up with marvelous and insightful ideas and reduces them to practice, like his work on reasonable big-O data structures or his work on software transactional memory. Or his work on ... Yet if you look at the code you see nothing. Which means that the next set of people who get to slice-and-dice the code after Rich will miss some of the insight and get it wrong. I've seen it happen in many places. The apprentice is rarely as good as the master. Not to cast stones at the rest of the Clojure group, I'm just using hasty-generalization, my favorite form of reasoning, from my experience. I find that literate programming is the only way to capture the insight and keep it where it belongs, adjacent and intermixed with the code, but written for humans-to-human communication. Clojure is heavy with great ideas and they need to be communicated intact. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Story
I'm concerned that the ability to freely order comments and code will not interact well with Clojure's namespaces. Hmmm. If raw code is confusing because namespaces are not apparent perhaps it would help to surround the code with some natural language that explains the specific namespace used. :-) Seriously though, if you are trying to communicate from one human to another and you're aware that 'str' and 'string' both refer to 'clojure.string' but it might be ambiguous in the function under discussion, wouldn't you consider mentioning this? What this means is that Clojure code is pretty much unreadable unless you know the context it occurs in, specifically, you need to which namespace it is, know the symbols that were defined above it in the file, and know the aliases of all the namespaces referred to from this namespace. If you're using namespaces so heavily perhaps it would make sense to have a chapter/section early in the document to explain the structure and use of namespaces. If you freely bounce around from namespace to namespace in the description of your Clojure code, it's going to be very confusing. This suggests to me that a well-organized literate program in Clojure would tend to document one namespace at a time. Within a namespace, Clojure lets you move code See? Already the notion of explaining code to the reader has led to the notion of a well-organized literate program. Writing good, readable literature is a challenge but, hey, we're professionals. How do you deal with this lack of context when you present your code in a way that is completely unrelated to the namespace organization of your files? Well I deal with it by using unique names rather than namespaces so I have never encountered the issue. The whole notion of namespaces feels like an attempt by Java programmers to import the com.foo... filenaming snafu into lisp. In the common lisp world I rarely ever see more than one package (namespace) so I guess I just haven't seen this as an issue. Styles vary. If you're using namespaces I presume you're also exporting an API. Logically that implies that the namespace and its functions would live in a separate chapter I suppose. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Story
Recently, I discovered the story literate programming tool for Clojure, which I prefer to marginalia: https://github.com/jedahu/story ... (snip) ... I had never heard of story, but ran across a mention of it while looking through the issues on marginalia's github site, so I decided to give it a try. It's similar to marginalia, in that it's not true literate programming -- it doesn't let you freely order your comments and code irrespective of how they appear in the final files, but is a tool for extracting long comments written in markdown in order to weave some sort of narrative explanation of why the code is written the way it is. The ability to freely order comments and code is actually vital to the idea of literate programming. The key idea is writing to communicate ideas to another person. This almost certainly involves reordering and restructuring code. The machinery needed to support literate programming is trivial. See http://axiom-developer.org/axiom-website/litprog.html ... (snip) ... * Tim Daly posted a tool that lets him essentially write Clojure inside a TeX document. Seems to require a very different workflow to use effectively. Actually it isn't really a change in workflow but a change in mindset. Literate programming is not documentation, they are different ideas. Right now, I care more about the literate programming side of things, but I'm always interested in learning anything about good documentation tools If you want the full-on Sturm und Drang see my talk at the WriteTheDocs conference in April (Literate Programming in the Large): http://www.youtube.com/watch?v=Av0PQDVTP4A I gave a similar talk at the Clojure conference a couple years ago. and practices for Clojure. For Clojure specific efforts see http://daly.axiom-developer.org/clojure.pdf (PDF) http://daly.axiom-developer.org/clojure.pamphlet (source) Download the source, follow the one-time instructions which are clip out and compile the tangle C program clip out the Makefile When you type 'make' it will recreate Clojure's Java directory structure, compile Clojure, run all the test cases, rebuild the PDF, and put you in the REPL. Your workflow is now: edit the source (clojure.pamphlet) loop-forever: type make fiddle with the REPL, clip the slime result into the source write a couple sentences You'll soon discover that writing code and writing explanations are co-equal activities, making the effort to write in a literate style so much easier and natural. Oh, and you get a pretty book at the end. Some PDF readers will update when changed so you can watch the book change as you work. I keep mine running so I can see the final book after each time I run make. Markdown, story, org-babel, javadoc, doxygen, and all of the other kinda-sorta-maybe-literatey efforts miss the point as they try to elevate documentation into what looks like a literate style but fail to really address the point. Really understanding lisp is an epiphany moment where you change from asking Why would anyone write like this? to Why doesn't everyone write like this?. Literate programming is the same kind of epiphany event. It takes time but the results are worth it. I'll see you on the other side. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Defining the ground truth
Is the ground truth your spec or your code? Here is an interesting read: http://shanecelis.github.io/2013/05/20/why-im-trying-literate-programming Shane started with a co-worker, working from a spec, to create a program. He eventually found that only he could make changes because only he understood the code and the spec was out of date. The last big project I worked on had 6 people for 6 years. The central data structure eventually became complex. It had optimizations and mountains of code that depended on them. When we tried to write a new and better central algorithm it turned out that nobody knew all the various substructures embedded in the main data structure so we couldn't make the improvement. The person who managed the main data structure had left the project, taking with him all the knowledge. The program died. Are you limiting our ability to collaborate because you don't communicate? Do we have to read (and reverse engineer) your code before we can write? Does your code add, change, or extend the spec with special cases? Can you keep up with the whole team using reverse engineering? Can you identify the person who holds it all together? Is your whole project dead code if certain people leave? If you want your code to live, communicate. Write words for people who will maintain your code but you'll never meet. Tim Daly Knuth fanboi -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Lisp In Summer Projects
If you have a Clojure project you could earn money and fame. Check out Lisp In Summer Projects http://lispinsummerprojects.org/?2013 Heow-Eide Goodman, the man behind LispNYC, is getting a group of experts together to judge the projects. You'll get your name in front of some well-connected people, a nice check, and a chance to speak at a LISP conference. Best of all, they don't even have to be literate programs! :-) Tim Daly Elder of the Internet -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Hacker News, Clojure, and GSOC
At least 2 of the people on this mailing list read Hacker News. One thing that really annoys me is the Link Expired message. If you wait more than a minute or two on a page, the NEXT button will fail to get the next news item. It seems to me that the Hacker News people need an education in using immutable data structures and a lesson or two in Hickey's notion of state and time. If Hacker News kept their news chains as immutable data structures they could update the pages without expiring links. You get a fresh head of the pages but I'm 3 pages further along on an old path yet we're both walking the same immutable structure. This is painfully obvious to a Clojure user like myself. Does anyone know anyone associated with Hacker News? Can we clue them into immutable data structures? Better yet, does ClojureScript fully support a method of walking immutable host data structures so they could code the pages with ClojureScript? That would be a very visible win in a widespread community. How would Datomic play in this game? Would the global immutable data structure living in Datomic? Or would you simply architect multiple machines that push/pull git-like updates among themselves? A clone of Hacker News in Clojure would be a good GSOC project as it is well defined and small enough for a single person effort. 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
MPI and Clojure
MPI does buffer copying when sending. Since Clojure doesn't modify data there is an optimization that could be made to skip this copy. Has anyone looked at MPI for Clojure with this optimization? Tim Daly d...@axiom-developer.org -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Light Table - a new IDE concept
On Friday, April 13, 2012 1:34:54 PM UTC-5, looselytyped wrote: This is an awesome implementation of Brett Victors Inventing On Principle [http://vimeo.com/36579366] using Clojure and Noir by Chris Granger (who also wrote Noir). Figured I would share it with the group. http://www.chris-granger.com/2012/04/12/light-table---a-new-ide-concept/ Raju A most excellent piece of work. I would like to see some extensions to support literate programming. Look at http://axiom-developer.org/axiom-website/litprog.html Look at section 2.2 Besides the function, I would like to see the surround div text. Even better, I would like to be able to edit the text as well as the function. Search could be specialized to the text. For Clojure code, look at http://daly.axiom-developer.org/clojure.pamphlet which is a latex document containing the source code for Clojure, as well as its test cases and Ant build script. (The PDF is at http://daly.axiom-developer.org/clojure.pdf) Here I have Clojure and Java code, access to a table of contents as well as an index of terms. The document is broken up into \chapter, \section, \subsection, and other text markups. Is light-table open source? How can I contribute these kinds of changes? Tim Daly d...@literatesoftware.com -- 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
Re: Literate programming in emacs - any experience?
On Tue, 2012-03-20 at 12:27 -0700, Tim Dysinger wrote: I'm using org-mode, org-babel swank for a living document I'm writing. I'm generating a PDF which includes documentation, working clojure code that generates incanter graphs. Also the generated incanter graphs are included in the generated (latex) PDF. On Monday, January 23, 2012 3:14:09 AM UTC-10, Colin Yates wrote: Hi all, There are some excellent resources on this mailing list regarding literate resources, but they are more based around the theory rather than actual use. You might find this of interest: Literate Programming example with Clojure http://youtu.be/mDlzE9yy1mk It is a quick video of my normal literate programming workflow (ignoring the usual git commits) It shows 3 things: 1) Extracting Clojure from the book and rebuilding the book PDF 2) adding code chunks and rebuilding clojure and the book 3) making text-only modifications and rebuilding only the PDF Has anybody got any real world usage reports regarding using literate programming in emacs? In particular, does paredit and slime work inside the clojure fragments when using org.babel for example? Finally - how are people finding practising TDD with literate programming? I imagine that Clojure's excellent REPL (+ evaluating clojure forms from within a buffer) mean there are far less type, extract tangled code, run tests needed. Hmmm, not sure that is clear. What I mean is, do people find that the ability to evaluate a clojure form from within org.babel (assuming that is possible!) is sufficient for TDD or do you find you need to type, extract the tangled code and then run lein (for example) to run the tests? When you run 'make', as shown in the video, it rebuilds the program and runs all the tests. Basically - how do y'all get on with TDDing in emacs following the approach of literate programming - any advice welcome! Here is an interesting quote from Greg Wilson (http://vimeo.com/9270320) From a IBM 1970s study: Hour for hour - the most effective way to get bugs out of code is to sit and read the code, not to run it and not to write unit tests. Code review is the best technique known for fixing bugs. Get somebody else to read your code. Sixty to Ninety percent of errors can be removed before the very first run of the program. And hour for hour, if you have a choice of writing unit tests and reading code, read the code. Thus, literate programming, which explains the reasoning behind the code and the issues involved, would seem to make code reviews be much more effective. I would love to do a study about this but so far I have not found any professors interested. Tim Daly d...@axiom-developer.org -- 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
Re: Use metadata instead of :require-macros for requiring macros from ClojureScript?
On Thu, 2012-03-22 at 22:23 -0400, Cedric Greevey wrote:
On Wed, Mar 21, 2012 at 1:12 AM, Evan Mezeske emeze...@gmail.com wrote:
Hi,
I'm working on some tools for making it easier to share generic Clojure code
between Clojure and ClojureScript, and one problem that does not seem to
have a pretty solution is that of requiring macros. Clojure uses a regular
(:require ...) whereas ClojureScript needs a (:require-macros ...). I
understand that the distinction is necessary for ClojureScript because
macros are written in Clojure.
This difference in the (ns ...) form is troublesome when trying to share
code between the two languages. Right now, the only solution is to
copy+edit the shared file (possibly with an automated tool) so that it has
:require and :require-macros as appropriate. This is not very pretty.
So that gets me to wondering, has anyone brought up the idea of using
metadata to identify macro namespaces? So instead of using :require-macros,
:require would be used, but each namespace identifier would be inspected to
see if it had ^{:macros true}.
; The existing way to require macros from ClojureScript:
(ns example.shared
(:require-macros
[example.macros :as macros])
(:require
[example.other :as other]))
(ns example.shared
(:require
^:macros [example.macros :as macros]
[example.other :as other]))
That might be one way to do it. The other obvious one is to implement
:require-macros in Clojure's ns macro, as a synonym for require, and
make sure require(-macros) is idempotent.
If you use a literate programming style it would be easy to extract
the code segments that are specific to the Clojure or ClojureScript
targets. Each code segment would be in its own chunk and could be
a separate selection. In addition, you could explain why it was
necessary to use :require in Clojure and :require-macros in
ClojureScript, making it clear to other developers.
So you would write
\begin{chunk}{Clojure code}
(ns example.shared
(:require
^:macros [example.macros :as macros]
[example.other :as other]))
\end{chunk}
\begin{chunk}{ClojureScript code}
(ns example.shared
(:require-macros
[example.macros :as macros])
(:require
[example.other :as other]))
\end{chunk}
In the Clojure case you extract the chunk with
tangle mydoc Clojure code file
and in the ClojureScript case you extract it with
tangle mydoc ClojureScript code file
In this way you can mingle code for both platforms
and explain why they need to be different, which would
be useful for other developers using your code.
That way you don't have to write a Clojure macro to
cover code intended for ClojureScript.
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
Re: Literate programming in emacs - any experience?
On Sat, 2012-01-28 at 06:51 -0800, Folcon wrote: Hi Tim, Personally if you have done or would be interested in doing a quick vid cast of how you progress through your workflow, I think that would be very interesting. Sorry for the delay. Here is the answer to your request. Note that the source and PDF are at: src: http://daly.axiom-developer.org/clojure.pamphlet pdf: http://daly.axiom-developer.org/clojure.pdf I have a quick video of my normal literate programming workflow (ignoring the usual git commits). It shows 3 things: 1) Extracting Clojure from the book and rebuilding the book PDF. 2) adding code chunks and rebuilding clojure and the book 3) making text-only modifications and rebuilding only the PDF. http://youtu.be/mDlzE9yy1mk Tim -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Mon, 2012-03-12 at 21:59 +0900, Andrzej wrote:
On Sun, Mar 11, 2012 at 2:56 AM, Softaddicts
lprefonta...@softaddicts.ca wrote:
About item 1:
The first Lisp I used was runing on a DEC-10 with 256k 36 bits words of
physical
memory (magnetic-core memory).
It had a structural editor. We would change nodes, add/remove child nodes,
...
Interesting. I thought it was only a planned feature, which has never
got implemented.
VMLisp on the IBM Mainframe also was a structure editor.
(Mark Wegman, Martin Michaelson, Fred Blair)
They were useful because the initial editors on small systems
used sed-like commands to edit the text so you did blind
edits (e.g. c/the/twe/ 200 lines changed). Think DOS
edlin, TECO, etc. In my first 7 years of programming, the
only way to see the text was to type it out but that was
hugely wasteful of paper and something you rarely did so
editing was done in your head.
Structure edits made sure that your edits were properly
formed s-expressions. This helped a lot because you no
longer had to keep a running count of parens in your head.
I still wonder how it could fare compared to the text base approach we are
used
to these days. Maybe this is worth an attempt with the current processing
power
we have at hand and graphic aids that did not exists et the time.
Structure editors took up more memory. Since my big PDP 11/40
had 8k (including the OS), this was a trade-off. With a simple
editor files could be up to 4k of text before the next char
crashed the system. A more complex editor ate into the program
size and caused an earlier crash due to memory being exhausted.
I think it could work rather well in an education-oriented environment
or in DSLs. I don't think it would be interesting enough to flip
mainstream software engineers on its side, unless it had an Apple
badge on it. ;-)
Emacs has paredit which allows s-expression level edits, see
paredit-splice-sexp, paredit-forward-slurp-sexp, etc. The
http://www.cliki.net/Editing%20Lisp%20Code%20with%20Emacs
has examples.
I'd rather like to see it working in practice - LISP is all about
about using and manipulating ASTs, yet s-expressions are somewhat
masking this feature (at least to newcomers, which tend to think of
the LISP syntax as of a string of characters with some parentheses
added to it).
This leads to thinking about s-expressions as wholes where
each s-expression at every level does something you could name.
This tends to break down a bit as you get closer to the machine.
However, at the DSL level structure edits are pretty clean.
If you are at a level where you can think in wholes then
a structure editor might be useful. The VMLisp editor
tended to make you think on the syntax level and that
is very distracting. You generally don't see the parens
when writing code since lisp allows one to ignore all
syntax issues. Other languages (e.g. C++) require random
';', '{', etc. which forces attention to syntax. Maybe
that's why people like IDEs since they tend to provide
auto-insertion of delimiters and motion by expression
which is a kind of structure editing.
Clojure brings back some syntax issues because binding
contexts require [ ] pairs and other structured surface
syntax protrudes into your attention. Would a Clojure
structure editor tend to drift to an IDE? Wouldn't
CCW qualify as a structure editor? I believe they have
some of paredit's abilities:
http://code.google.com/p/counterclockwise
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
Re: Can Clojure be as readable as Python or Ruby ?
On Fri, 2012-03-09 at 10:04 -0800, Evan Gamble wrote: I find let? useful and readable, as do others. There's a bit of brain- training necessary to read it, but not a lot. Probably no more than the keyword clauses of the for comprehension. The argument that decades of Lisp programmers haven't invented this particular chucklehead macro is a bit weak, since there have been many other similar macros. ...and I have learned to love nil, even the :else nil clause that repels you. There is a bit of brain-training necessary to read code with parens but not a lot. In fact, my editor can read paren code. The let? syntax breaks code walkers. The let? syntax breaks pretty printers. The let? syntax complexes read. See the loop package in Common Lisp. Some people swear by it, others swear at it. The idea isn't new. If you want readable code write a literate program. Literate programs communicate from person to person rather than having the person decode your idea from the code. If you understand the idea, any syntax is easy to read. 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
Re: Google Summer of Code 2012 - any mentors?
: I did GSoC years ago for Plan9 (Inferno-OS specifically). I was not very familiar with their community, and I doubt many people have ever read a book about programming Limbo. As a result, a lot of the ideas that were listed were strangely specific from my limited undergrad perspective. I was interested in learning about Plan9 and contributing, not necessarily learning Plan9 to make a distributed authentication system that someone else wanted for reasons that were unknown to me and/or were not well described in the description. As a result, keep in mind that we will potentially have people submitting proposals to write Skynet 1.0 in 3 months who are doing their undergrad and may have only just had an introduction to lisp or scheme. Last note (I promise) is: potential mentors, this is not a small commitment. Trust me on that. It's as much your responsibility to steer someone toward success as it is theirs. I'm actually working on the ePub idea with a book so the mentoring would actually be more of a collaborative effort since it travels into what is, for me, new territory. There are still some things to demonstrate and a lot of reading of the ePub3 standard but it progresses slowly. An ePub book with embedded interactive canvas elements seems to be the best path to inspire people to write literate software. Tim Daly d...@axiom-developer.org -- 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
Re: Literate programming in emacs - any experience?
On Wed, 2012-02-01 at 10:43 +, Sam Aaron wrote: On 30 Jan 2012, at 17:07, daly wrote: The key result was that I discovered what I call my personal irreducible error rate. If I do 100 things I will make 3 errors. This was independent of the task. So typing 100 characters has 3 wrong letters which were mostly caught while typing. Writing 100 lines of code had 3 errors somewhere. Composing email introduces 3 errors per 100 lines of code. I wonder if that rate has changed since the time you measured it. Unfortunately not. However I am now able to identify several errors that I continue to make. The 2/3 keys get mistyped. The _/+ keys get mistyped. I seem unable to overcome this. Which is really bad considering my hobby is computer algebra. The largest contribution to my errors is using copy/paste. It is responsible for about 50% of all errors. If I could convince myself to stop using it my error rate would drop. On good days I don't use it but I get lazy. Curiously I do have a lower error rate in Lisp than I do in other languages. In C, for instance, I get caught by things like float to double conversions on calls, despite knowing about it. In Java I miss the null case checks despite being aware that Java is brain-dead about null. In Python I skip selfing things. In Javascript I miss the 'var' occasionally. Lisp just works and works just as I expect. It eliminates whole categories of errors. (The most annoying thing about Clojure is the null pointer exceptions from Java.) When I want solid, correct code I reach for Lisp. For random segment faults, C. For heap exhaustion or null pointers, Java, etc. Rich did a marvelous thing by forcing alter to require dosync. It eliminates a whole class of errors. When I find a mistake I still try to find the root cause. Then I try to change what I do so the mistake cannot exist. This changes the type of possible errors but the 3% is still there. I just make more sophisticated, higher level errors. I am hoping that Literate Programming will raise my errors to truly epic proportions :-) One of my personal motivations for literate programming is to eliminate errors. I have no tool that will catch errors in reasoning, missing cases, bad design, mindless stupidity, and horrible inefficiency. Writing an explanation of the code is the best way I have found to catch errors of this kind. One of Rich's stated motivations for Clojure was that he found concurrent programming in various languages to be very error prone and wanted to create a language that would eliminate concurrent errors. In some sense, we are trying to achieve similar goals. So Literate Programming is not about tools. It is about a change in mindset. I want to be a better programmer and this is an effective tool to help me generate higher quality (ie less buggy) code. 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
Re: Literate programming in emacs - any experience?
On Sat, 2012-01-28 at 10:04 -0500, daly wrote: On Sat, 2012-01-28 at 06:51 -0800, Folcon wrote: Hi Tim, Personally if you have done or would be interested in doing a quick vid cast of how you progress through your workflow, I think that would be very interesting. Sort of extreme pair programming with everybody? :-) There is no such thing as a simple job but I'll see what I can do. A watchable video takes time to compose. I am composing the notes for this video and I realized I have a piece of programming information about myself that you probably do not have about yourself. Years ago I wrote a program (Archive) to allow users of a time shared mainframe to back up programs to magnetic tape. This was a single person project. As an experiment I copied every input at the keyboard and every output of every command. I also kept a journal of everything I did, why I did it, and what failed. The key result was that I discovered what I call my personal irreducible error rate. If I do 100 things I will make 3 errors. This was independent of the task. So typing 100 characters has 3 wrong letters which were mostly caught while typing. Writing 100 lines of code had 3 errors somewhere. Composing email introduces 3 errors per 100 lines of code. Most of the errors were trivial (spelling), some were syntax (missing delimiter), some were semantic (wrong action), some were design (wrong solution). As a result of this measurement I have formed habits to look for the 3 mistakes I know exist. For example, I am writing a book of Axiom graphics images (a gallery). I have written 679 equations so far, which are going to create the images. I know there are at least 21 uncaught errors lurking in those equations. So before I attempt to generate the images I will examine them in detail with an eye toward finding what I know is there. Literate programming is both a source of errors and a help. It is a source of errors because I have more typing to do and will generate bad latex and meaningless sentences, as well as the standard coding errors. So in some sense I have added to the number of errors I WILL introduce. But the tools, like the compiler, tex and spellcheck will at least warn me of these failures. However, literate programming helps because I am explaining what I am doing to myself as well as others. This really reduces the big, costly errors, those in the design and implementation. There are no tools to help so I have to create a discipline that will highlight these errors as soon as possible. I KNOW my intrinsic error rate. What is yours? What discipline can you apply to your work to find your errors? I'm not sure how to get this important piece of self-knowledge into the video so I thought I'm mention it here. 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
Re: Literate programming in emacs - any experience?
On Sat, 2012-01-28 at 06:51 -0800, Folcon wrote: Hi Tim, Personally if you have done or would be interested in doing a quick vid cast of how you progress through your workflow, I think that would be very interesting. Sort of extreme pair programming with everybody? :-) There is no such thing as a simple job but I'll see what I can do. A watchable video takes time to compose. 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
Re: Literate programming in emacs - any experience?
On Sat, 2012-01-28 at 15:27 +, Colin Yates wrote: I know I would find it incredibly helpful, and would consider paying a token sum of money (£5?)... An amusing thought but no thanks. Buy yourself a pint and swear you'll at least try to write your next program in some form of literate programming. At the next conj I'll buy you a pint. On 28 January 2012 15:04, daly d...@axiom-developer.org wrote: On Sat, 2012-01-28 at 06:51 -0800, Folcon wrote: Hi Tim, Personally if you have done or would be interested in doing a quick vid cast of how you progress through your workflow, I think that would be very interesting. Sort of extreme pair programming with everybody? :-) There is no such thing as a simple job but I'll see what I can do. A watchable video takes time to compose. 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 -- 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 -- 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
Re: Setting up Emacs to edit Clojure for Windows folks
On Wed, 2012-01-25 at 11:59 -0800, Rick Hall wrote: I tried to set up a development environment for Clojure on a Windows box. As you all know there are lots of editors available and multiple ways of setting up each editor. There are also several versions of instructions as the process has changed over time. I have virtually never ventured out of Visual Studio for the past 8 years. I found the range of options overwhelming, and while I understand the instructions more clear in retrospect I thought it might be nice to leave a trail for those who follow behind me. I have written a blog post that shows how to install the jdk, leigingen, emacs, clojure-mode and slime. The level of detail in some places may seem excessive, but given the amount of time it took me to comprehend instructions like: from within a project insert M-x clojure- jack-in, I figured it was better to err on the side of detail. For anyone who needs the help, the post is here: http://onbeyondlambda.blogspot.com/2012/01/setting-up-clojure-emacs-on-windows.html I had some trouble getting slime to work on windows. If you are running emacs you can get a lot of functionality with simple keyboard macros. If you split the screen 'Ctrl-x 2' and start a shell buffer 'Meta-x shell' you can run clojure in the shell. You can edit lisp in the other buffer and use 'Ctrl-x o' to switch between the buffers. A simple keyboard macro can be set on a key (e.g. f1) with 'Meta-:' (global-set-key [f1] \C-x/1\C-[\C-a\C-@\C-[\C-f\C-[w\C-xo\C-y\C-m\C-xo\C-xj1) Pressing the F1 key now will evaluate the s-expression that contains the point. This works by: (remember the position) \C-x/1 (go to the beginning) \C-[\C-a (remember the point) \C-@ (mark the s-expression) \C-[\C-f (push it to the killring) \C-[w (switch to other buffer) \C-xo (yank the s-expression) \C-y (hit enter to eval it)\C-m (switch to other buffer) \C-xo (go back to position) \C-xj1 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
Re: Literate programming in emacs - any experience?
On Mon, 2012-01-23 at 05:14 -0800, Colin Yates wrote:
Hi all,
There are some excellent resources on this mailing list regarding
literate resources, but they are more based around the theory rather
than actual use.
Has anybody got any real world usage reports regarding using
literate programming in emacs? In particular, does paredit and slime
work inside the clojure fragments when using org.babel for example?
I've been using literate programming for years in Axiom.
Basically I write in a buffer containing latex, my literate tool
of choice. I have a *shell* buffer open running Lisp.
The lisp code is in a chunk delimited by
\begin{chunk}{chunkname}
(this is the lisp code)
\end{chunk}
All I have to do is clip the lisp code, yank it into the *shell*
buffer, and it gets evaluated.
Once I've developed a small piece of program (about 20 lines
or so), I do a complete system rebuild and run all of the tests.
If all of the tests pass I git-commit the result, push it to
the public servers, and start writing again.
Finally - how are people finding practising TDD with literate
programming? I imagine that Clojure's excellent REPL (+ evaluating
clojure forms from within a buffer) mean there are far less type,
extract tangled code, run tests needed. Hmmm, not sure that is
clear. What I mean is, do people find that the ability to evaluate a
clojure form from within org.babel (assuming that is possible!) is
sufficient for TDD or do you find you need to type, extract the
tangled code and then run lein (for example) to run the tests?
Axiom has a directory of tests, all of which are also literate
documents. When I create a new test I write the new tests, run
the tests, and capture the output. The captured output is part
of the literate test document.
When I do a system build the new test is run as part of the whole
test suite. The test results are compared against the stored
results and failures are noted.
I've attached an example of a literate test case.
Basically - how do y'all get on with TDDing in emacs following the
approach of literate programming - any advice welcome!
Thanks all.
Col
--
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
--
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\documentclass{article}
\usepackage{axiom}
\setlength{\textwidth}{400pt}
\begin{document}
\title{\$SPAD/src/input clifford.input}
\author{Timothy Daly}
\maketitle
\begin{abstract}
\end{abstract}
\eject
\tableofcontents
\eject
\section{Overview}
CliffordAlgebra(n, K, Q) defines a vector space of dimension 2**n
over K, given a quadratic form Q on K**n.
\begin{verbatim}
If e[i] 1=i=n is a basis for K**n then
1, e[i] 1=i=n, e[i1]*e[i2] 1=i1i2=n,...,e[1]*e[2]*..*e[n]
is a basis for the Clifford Algebra.
The algebra is defined by the relations
e[i]*e[j] = -e[j]*e[i] i ^= j,
e[i]*e[i] = Q(e[i])
\end{verbatim}
Examples of Clifford Algebras are:
gaussians, quaternions, exterior algebras and spin algebras.
Choose rational functions as the ground field.
\section{License}
\begin{chunk}{license}
--Copyright The Numerical Algorithms Group Limited 1991.
\end{chunk}
\begin{chunk}{*}
)set break resume
)spool clifford.output
)set message test on
)set message auto off
)clear all
--S 1 of 39
K := FRAC POLY INT
--R
--R
--R (1) Fraction Polynomial Integer
--R Type: Domain
--E 1
--% The complex numbers as a Clifford Algebra
)clear p qf
--S 2 of 39
qf: QFORM(1, K) := quadraticForm(matrix([[-1]])$(SQMATRIX(1,K)))
--R
--R
--R (2) [- 1]
--R Type: QuadraticForm(1,Fraction Polynomial Integer)
--E 2
--S 3 of 39
C := CLIF(1, K, qf)
--R
--R
--R (3) CliffordAlgebra(1,Fraction Polynomial Integer,MATRIX)
--R Type: Domain
--E 3
--S 4 of 39
i := e(1)$C
--R
--R
--R (4) e
--R 1
--R Type: CliffordAlgebra(1,Fraction Polynomial Integer,MATRIX)
--E 4
--S 5 of 39
x := a + b * i
--R
--R
--R (5) a + b e
--R 1
--R Type: CliffordAlgebra(1,Fraction Polynomial Integer,MATRIX)
--E 5
--S 6 of 39
y := c + d * i
--R
--R
--R (6) c + d e
--R 1
Re: Literate programming in emacs - any experience?
On Mon, 2012-01-23 at 07:18 -0800, Sam Ritchie wrote:
I've been wondering this as well -- I'm specifically curious about how
one might jump back and forth between literate source like this and
the REPL. I know you can evaluate code snippets into the repl; I'm
thinking of early steps like loading an entire namespace into the repl
when its code exists in separate code blocks. Some command like
evaluate all code snippets that'll be tangled into this file.
It is trivial to write a lisp program which reads a literate file,
collects the chunks into a hash table, and writes out the chunks
into a standard text file which you can load.
I've attached a common lisp file that I use for that purpose.
It accepts either noweb syntax for chunks, as in:
chunkname=
(this is lisp code)
@
or latex syntax for chunks, as in:
\begin{chunk}{chunkname}
(this is lisp code)
\end{chunk}
You could also write one to process straight HTML, as in:
http://axiom-developer.org/axiom-website/litprog.html
I would even be trivial to write an elisp version that runs
as an emacs command, although I've never felt the need.
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; 0 AUTHOR and LICENSE
; 1 ABSTRACT
; 2 THE LATEX SUPPORT CODE
; 3 GLOBALS
; 4 THE TANGLE COMMAND
; 5 THE TANGLE FUNCTION
; 6 GCL-READ-FILE (aka read-sequence)
; 7 GCL-HASHCHUNKS
; 8 GCL-EXPAND
; 9 ISCHUNK-LATEX
; 10 ISCHUNK-NOWEB
; 11 ALLCHUNKS
; 12 makeHelpFiles
; 13 makeInputFiles
;;; 0 AUTHOR and LICENSE
;;; Timothy Daly (d...@axiom-developer.org)
;;; License: Public Domain
;;; 1 ABSTRACT
;;; This program will extract the source code from a literate file
;;; A literate lisp file contains a mixture of latex and lisp sources code.
;;; The file is intended to be in one of two formats, either in latex
;;; format or, for legacy reasons, in noweb format.
;;; Latex format files defines a newenvironment so that code chunks
;;; can be delimited by \begin{chunk}{name} \end{chunk} blocks
;;; This is supported by the following latex code.
;;; 2 THE LATEX SUPPORT CODE
;;; The verbatim package quotes everything within its grasp and is used to
;;; hide and quote the source code during latex formatting. The verbatim
;;; environment is built in but the package form lets us use it in our
;;; chunk environment and it lets us change the font.
;;;
;;; \usepackage{verbatim}
;;;
;;; Make the verbatim font smaller
;;; Note that we have to temporarily change the '@' to be just a character
;;; because the \verbatim@font name uses it as a character
;;;
;;; \chardef\atcode=\catcode`\@
;;; \catcode`\@=11
;;; \renewcommand{\verbatim@font}{\ttfamily\small}
;;; \catcode`\@=\atcode
;;; This declares a new environment named ``chunk'' which has one
;;; argument that is the name of the chunk. All code needs to live
;;; between the \begin{chunk}{name} and the \end{chunk}
;;; The ``name'' is used to define the chunk.
;;; Reuse of the same chunk name later concatenates the chunks
;;; For those of you who can't read latex this says:
;;; Make a new environment named chunk with one argument
;;; The first block is the code for the \begin{chunk}{name}
;;; The second block is the code for the \end{chunk}
;;; The % is the latex comment character
;;; We have two alternate markers, a lightweight one using dashes
;;; and a heavyweight one using the \begin and \end syntax
;;; You can choose either one by changing the comment char in column 1
;;; \newenvironment{chunk}[1]{% we need the chunkname as an argument
;;; {\ }\newline\noindent%make sure we are in column 1
;;; %{\small $\backslash{}$begin\{chunk\}\{{\bf #1}\}}% alternate begin mark
;;; \hbox{\hskip 2.0cm}{\bf --- #1 ---}% mark the beginning
;;; \verbatim}% say exactly what we see
;;; {\endverbatim%process \end{chunk}
;;; \par{}% we add a newline
;;; \noindent{}% start in column 1
;;; \hbox{\hskip 2.0cm}{\bf --}% mark the end
;;; %$\backslash{}$end\{chunk\}% alternate end mark (commented)
;;; \par% and a newline
;;; \normalsize\noindent}%and return to the document
;;; This declares the place where we want to expand a chunk
;;; Technically we don't need this because a getchunk must always
Re: Literate programming in emacs - any experience?
On Mon, 2012-01-23 at 16:17 -0500, Cedric Greevey wrote:
On Mon, Jan 23, 2012 at 11:19 AM, daly d...@axiom-developer.org wrote:
It accepts either noweb syntax for chunks, as in:
chunkname=
(this is lisp code)
@
A rather unfortunate choice of delimiter if you wanted to use this
with Clojure code, since Clojure code frequently has internal @-signs
for other purposes. I don't suppose that noweb syntax was developed
with Clojure in mind, though, or vice-versa.
The noweb syntax was chosen by Norman Ramsey, the author.
Since the tangle program processes the literate document,
the REPL would never see the chunk syntax. The unfortunate
side effect is that latex DOES see the chunk syntax so you
have to use a weave program to get straight latex.
Instead I implemented a new latex environment called chunk
so I could use \begin{chunk} as the delimiter. This means
that the weave step is no longer required and my document
is straight latex.
In the HTML version I used pre id=chunkname so that
the weave step is not required either.
For Eclipse I suppose we could invent a chunk syntax
and create a plugin. If people are interested perhaps we
could create a Literate Clojure plugin for Eclipse. See
http://www.eclipse.org/articles/Article-Your%20First%
20Plug-in/YourFirstPlugin.html
That would make Clojure and Literate much more useful
to Eclipse users.
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
Re: Literate programming in emacs - any experience?
For Eclipse I suppose we could invent a chunk syntax and create a plugin. If people are interested perhaps we could create a Literate Clojure plugin for Eclipse. See http://www.eclipse.org/articles/Article-Your%20First% 20Plug-in/YourFirstPlugin.html That would make Clojure and Literate much more useful to Eclipse users. Based on CCW, or a de novo effort? Ah. I was unaware of CCW although it has been mentioned here. I don't use Eclipse. I was just following the principle that advocacy is volunteering and, since I'm advocating doing literate programming and the topic is literate Clojure under Eclipse, I felt I needed to set up some kind of solution. I try to implement what I advocate (e.g. showing tangle for lisp code and HTML code). Otherwise I'd be expecting someone else to do stuff I want and that's not really how open source should work. So, no, if CCW is already doing this then follow their lead. 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
Can Simplicity Scale?
Can Simplicity Scale? http://blog.regehr.org/archives/663 Sadly you'll note that the source code https://github.com/damelang/gezira/tree/master/nl does not even include comments. The code is obvious that it clearly does not need comments since the machine has no trouble understanding it. I, however, find it rather opaque. I wish it were literate and that the literate program explained the ideas. Look at the code. It is clearly simple (but not in the sense Rich Hickey mentioned). DSLs are great and I use them a lot but a domain specific language presumes you speak the language. 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
Re: are non programmers the better programmers?
On Wed, 2012-01-18 at 11:11 +0100, Dennis Haupt wrote: let's call it the biased experience effect. if there are 20 ways to solve a problem, and you just know 3 of them, you are a hammer and the problem looks like a nail. if you have a broader knowledge, you can pick a more appropriate solution. what i claim is that if you know NO solutions, the one you'll come up with will most likely be better than the one you come up with if you know 3 solutions because you are not biased. That is clearly a testable hypothesis. Gather some students from music class who have not taken any CS courses and some senior CS students and construct a test. If your hypothesis holds true then it seems that Google's number of ping pong balls in a bus test would select for people who cannot program. How very odd. 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
Re: are non programmers the better programmers?
technologies. Code cannot communicate why it was written. Any real program that a company creates to solve a real problem is going to be a large, complex web of technologies and *ideas*. Once the original authors leave the project, the *ideas* are lost. We need to capture the *ideas* as well as the code. My particular solution is the literate programming meme. Your results might vary but the good code meme is not the solution. tl;dr the good code meme is not enough; use the literate programming meme 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=enAlgebraicFunctionField(F, UP, UPUP, modulus): Exports == Impl where F : Field UP : UnivariatePolynomialCategory F UPUP : UnivariatePolynomialCategory Fraction UP modulus: UPUP N == NonNegativeInteger Z == Integer RF == Fraction UP QF == Fraction UPUP UP2 == SparseUnivariatePolynomial UP SAE == SimpleAlgebraicExtension(RF, UPUP, modulus) INIT == if (deref brandNew?) then startUp false Exports == FunctionFieldCategory(F, UP, UPUP) with knownInfBasis: N - Void ++ knownInfBasis(n) is not documented Impl == SAE add import ChangeOfVariable(F, UP, UPUP) import InnerCommonDenominator(UP, RF, Vector UP, Vector RF) import MatrixCommonDenominator(UP, RF) import UnivariatePolynomialCategoryFunctions2(RF, UPUP, UP, UP2) startUp: Boolean - Void vect : Matrix RF - Vector $ getInfBasis: () - Void brandNew?:Reference(Boolean) := ref true infBr?:Reference(Boolean) := ref true discPoly:Reference(RF) := ref 0 n := degree modulus n1 := (n - 1)::N ibasis:Matrix(RF) := zero(n, n) invibasis:Matrix(RF) := copy ibasis infbasis:Matrix(RF) := copy ibasis invinfbasis:Matrix(RF):= copy ibasis branchPointAtInfinity?() == (INIT; infBr?()) discriminant() == (INIT; discPoly()) integralBasis()== (INIT; vect ibasis) integralBasisAtInfinity() == (INIT; vect infbasis) integralMatrix() == (INIT; ibasis) inverseIntegralMatrix()== (INIT; invibasis) integralMatrixAtInfinity() == (INIT; infbasis) branchPoint?(a:F) == zero?((retract(discriminant())@UP) a) definingPolynomial() == modulus inverseIntegralMatrixAtInfinity() == (INIT; invinfbasis) vect m == [represents row(m, i) for i in minRowIndex m .. maxRowIndex m] integralCoordinates f == splitDenominator(coordinates(f) * inverseIntegralMatrix()) knownInfBasis d == if deref brandNew? then alpha := [monomial(1, d * i)$UP :: RF for i in 0..n1]$Vector(RF) ib := diagonalMatrix [inv qelt(alpha, i) for i in minIndex alpha .. maxIndex alpha] invib := diagonalMatrix alpha for i in minRowIndex ib .. maxRowIndex ib repeat for j in minColIndex ib .. maxColIndex ib repeat infbasis(i, j):= qelt(ib, i, j) invinfbasis(i, j) := invib(i, j) void getInfBasis() == x := inv(monomial(1, 1)$UP :: RF) invmod := map(s +- s(x), modulus) r := mkIntegral invmod degree(r.poly) ^= n = error Should not happen ninvmod:UP2 := map(s +- retract(s)@UP, r.poly) alpha := [(r.coef ** i) x for i in 0..n1]$Vector(RF) invalpha := [inv qelt(alpha, i) for i in minIndex alpha .. maxIndex alpha]$Vector(RF) invib := integralBasis()$FunctionFieldIntegralBasis(UP, UP2, SimpleAlgebraicExtension(UP, UP2, ninvmod)) for i in minRowIndex ibasis .. maxRowIndex ibasis repeat for j in minColIndex ibasis .. maxColIndex ibasis repeat infbasis(i, j):= ((invib.basis)(i,j) / invib.basisDen) x invinfbasis(i, j) := ((invib.basisInv) (i, j)) x ib2:= infbasis * diagonalMatrix alpha invib2 := diagonalMatrix(invalpha) * invinfbasis for i in minRowIndex ib2 .. maxRowIndex ib2 repeat for j in minColIndex ibasis .. maxColIndex ibasis repeat infbasis(i, j):= qelt(ib2, i, j) invinfbasis(i, j) := invib2(i, j) void startUp b == brandNew?() := b nmod:UP2:= map(retract, modulus) ib := integralBasis()$FunctionFieldIntegralBasis(UP, UP2, SimpleAlgebraicExtension(UP, UP2, nmod)) for i in minRowIndex ibasis .. maxRowIndex ibasis repeat for j in minColIndex ibasis .. maxColIndex ibasis repeat qsetelt_!(ibasis, i, j, (ib.basis)(i, j) / ib.basisDen) invibasis(i, j) := ((ib.basisInv) (i, j
Re: are non programmers the better programmers?
On Tue, 2012-01-17 at 23:10 +0100, Dennis Haupt wrote: Am 17.01.2012 22:46, schrieb James Reeves: On 17 January 2012 20:46, Dennis Haupt d.haup...@googlemail.com wrote: i've noticed this since i started to work as a programmer 10 years ago. programmers in general are supposed to be good at finding simple solutions, but my experience is: they are not. on the contrary, many suffer from their individual tunnel visions without being aware of it. to a hammer, everything looks like a nail. To borrow from Stuart Halloway: simplicity ain't easy. The example solutions you provide from non-programmers seem straightforward, but that's because they're instructions designed to be followed by a human being, who can infer and reason, rather than a programming language that is constructed around the idea of precise commands. For instance, you just make pairs hides a considerable amount of depth. How do you make pairs? You might select one number, then look for another number that is identical, but how do you ensure you don't pick the same number? Or what about count how often a number is in the list. Again, it seems a simple thing to do, but only if you're giving instructions to a human. In programming there are many additional questions, like where to store the numbers whilst you're counting them. Do you go through the whole list for each number, or do you go through the list once and keep a tally? If you keep a tally, which data structure should be used to implement this? in the end, the program must work down to the lowest level and there cannot be unanswered questions. but take a look at the 3 solutions given until now. in 2 cases, all i read is do this, then that, i don't care how. in the third, a hashset was picked. but it didn't have to be one. any non-map-collection type would have worked here. It's often a lot easier to find a complex solution to a problem than a simple one. Simple solutions are hard work to find. i'd say they require different strategies to find On a completely different approach, have you seen Polya's book How to solve it? 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
Re: Use You a Spaced Repetition System for Great Good!
On Tue, 2012-01-10 at 10:24 -0800, Kai wrote: Hi Tim, I found your post very compelling in the questions, analogies, and possibilities raised - something like a Clojure Etudes is really needed to move beyond learning just the syntax and general concepts, and into the next level of skill with Clojure - or any other language. Perhaps that level is akin to idioms and basic design patterns, but whatever it is, it can be very valuable when learning/studying alone. One thing I've identified, as mentioned in my post, is the ability to change the style of a solution without changing the basic character of the solution. So I've been looking at Knuth's Sorting and Searching book and thinking about trying each algorithm in different styles. That is, write bubble sort in a functional style, a procedural style, an Object oriented style, a rule based style, a table driven style, a spreadsheet style, a call/CC (scheme continuation) style, in a threaded, concurrent style, in a parallel style, as a DSL style, as a Hadoop/MapReduce style, etc. Clearly some of these are going to be rather artificial for any given problem but the same is true of trying to write a romantic love song in heavy metal. The point is the style, not the solution. The next Etude does the same thing with a merge sort. Eventually it should become clear what the style idioms are, independent of the task. In my opinion, someone skilled in the art and trying to master it would be able to move between styles fluidly without changing the problem. If these Etudes are done as literate programs then someone can pick up the bubble sort booklet and get each style explained in the context of the problem and understand how the solution was constructed. How many people are interested in this idea? If there's interest, how could we start and collaborate? I noticed there's a Clojure in Small Pieces book by you; is that the current go-to for this level of study? Thanks, Clojure is Small Pieces is intended to bridge the gap between the ideas in Clojure (e.g. immutable data structures) and their implementation. It has been my observation over the years that many projects die (Sourceforge has about 100k dead projects) once the original authors move on. It has also been my observation that literate software is a potential way to make programs that can be maintained and modified, that is, programs that live. I want Clojure to live. I have also personally observed that literate software is of much higher quality. Of course, these are only conjectures that need to be tested. I have been trying to find places that are willing to create real human factors experiments to test these conjectures. This is one example letter: It is clear that Literate Programming can improve code quality in three ways. First, the programmer finds mistakes in reasoning while explaining the code. Second, the code review team can question the reasoning as well as the implementation. Third, code can live beyond the lifetime of the original authors because the information necessary to modify and maintain the program has been communicated as part of the development. Since there are no studies to confirm or deny these statements they are just opinions. However, the second claim can be tested in a well designed study. The basic idea would be to take an existing program, telnet for example, and create a literate version. The extracted output of the literate form (the tangled form ala Knuth) would be byte-for-byte equal to the non-literate form. A proper study would evaluate the comprehension of programmers when given equivalent blocks of code, some literate and some not. For instance, there could be questions about telnet's buffer management scheme to try to highlight security flaws such as DOS attacks that use up the buffer pool. Would the literate group have a better understanding of the ideas and be better prepared to answer detailed questions about behavior? Such a study would underpin the improvement in quality of the source code and raise the quality and professionalism of programmers. Would you be interested in participating in such a study? === Such a study could be done with Clojure. For instance, take the implementation immutability using a Red-Black Trie structure. Make a literate form. Now create 2 groups, one reading the usual code containing only comments and one reading the literate form. Ask questions like, why are the 5 bit masking sequences used? When should they be 6 bit? What effect would this have on the O(x) complexity? Imagine if every Clojure programmer could answer those questions simply because they read the book. I believe it would set a standard for code excellence that would outshine every other project. Tim Daly -- You received this message because you are subscribed to the Google Groups Clojure
Re: Use You a Spaced Repetition System for Great Good!
On Tue, 2012-01-03 at 14:45 -0800, Joshua wrote: Hi Tim, Great idea re: GitHub! I'm guessing the Clojure decks could cover, multiple things if tagged appropriately and could be studied in various section. Or there could be multiple decks dealing with differing material. I'm not very familiar with github, but it is high time I really check it out and would be a great place for this sort of project. I just found the Clojure language API Anki deck so someone has been busy on this already. Have you found using an SRS helped with more than just studying on your own with regard to development? I've built a deck for guitar chords (using fretboard shapes) that I have been using for practice. I want to enhance it with the corresponding sounds. Self-study is the whole point. There are 732 cards in the Clojure deck, which implies that there is a whole lot of Clojure that I have yet to learn. Are you experiencing good retention rates and reduced practice time reviewing with Anki? I guess. I know that I can go through the decks quicker now than when I started so I guess something is sticking. Or maybe I am just mis-remembering how good I was at it the first time :-) I came to Anki due to the first chapter of a book, Practicing: A Musician's Return to Music. There are several things worth quoting but one was: it is impossible to feign mastery of an instrument, however skillful the imposter may be. It is actually an excellent computer book, unintentionally. Considering a computer to be the world of music and Clojure to be the chosen instrument. What is required to attain mastery? What is required to achieve the point of having Clojure-based solutions flow from the fingers without thought of the language? Are there practice exercises? Can we create books of standard forms? If we had a practice book of Clojure what would be in it? Currently all of the Anki examples seem to be limited to vocabulary which, while important, is hardly what seems to be the path to mastery. My current thinking is to follow Dan Friedman's lead with the Schemer series (e.g. The Seasoned Schemer, The Reasoned Schemer, etc.) but that would require that Anki support some means of linear review questions by chapter and I don't see how to do this. Perhaps we need an SRS in Clojure. Could we combine Friedman's approach with an SRS feedback and tracking system to form a set of Etude-like Clojure practices? Could we take algorithms (e.g. http://weblog.jamisbuck.org/2011/2/7/maze-generation-algorithm-recap build the Clojure code, deconstruct them into a Socratic style ala Friedman, linearly sequence them, and use SRS to chart progress? This would give an Anki-by-section rather than Anki-by-flashcard. These Friedman-Etudes could be written to cover topics like using agents (e.g. deconstructing the ant demo). Or Knuth's sorts. So, like Etudes for Piano. we have Etudes for Clojure. I watched a class taught by Billy Joel, clearly a master at the piano. He talked about a song he wrote and how he first thought of it in a reggae style (which he played), but then moved to a broadway style (which he played), then to a rock style (which he played), then classical, etc. He then explained why the style he chose was right. Imagine a Clojure programmer doing the same thing. Show me your application in a functional style, an object-oriented style, a rule-based style, a DSL style, a recursive style, etc. Unlike Java, lisp systems do not force a style. Can you gut feel which style is right for the problem at hand? Can we construct Clojure Friedman Etudes that show the essence of each of these styles? Rather than the Google ping pong balls in a bus interview wouldn't it be much more revealing to give an algorithm and ask to see it in several styles? Who do you want to be? The person who can reason out how many ping pong balls fit in the piano or the person who is fluid in styles? Who wouldn't love working with the Billy Joel of programming? 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
Re: Use You a Spaced Repetition System for Great Good!
I have built several Anki SRS decks for learning. I am building one now on American Sign Language. A Clojure deck would be a good idea. We could put a simple deck on github and make it so others could contribute. What should it cover? Only language syntax? Idiomatic forms (like lazy sequences)? Sections on Java interop? Tim Daly On Tue, 2012-01-03 at 18:19 +0100, Linus Ericsson wrote: Hi Joshua! I've been using Anki for repeating unsorted Clojure-stuff in about a year. It's good for knowing all the instructions and source code, but the key to success is always to solve more or less complicated problems (4clojure.org etc). On the practical side I have a lot left to learn, also since I'm not very skilled in algoritms in other languages [because the have so much boilerplate and therefore is boring to program in]. /Linus 2012/1/3 Joshua jos...@milehighcode.com Anybody else using a spaced repetition system (SRS) for Clojure learning? What about just general programming? How did it work out for you? I've just started using Anki and I uploaded a Clojure Sequence API shared deck. I'm hoping others might be interested in adding other Clojure related material to Anki. If you aren't familiar with the SRS concept, I wrote a short blog entry about it and how to import the Sequence API deck: http://blog.milehighcode.com/2012/01/use-you-spaced-repetition-system-for.html -- 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 -- 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 -- 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
Re: Clojure list syntax sugar: f(x) notation
On Mon, 2011-12-26 at 10:09 -0800, Louis Yu Lu wrote:
Recently, I found freedom of coding playing with Clojure with over 20
years’ experience on other program languages, Previously, I had
several trials of learning Lisp, but never got traction.
However there are two syntax notations always bother me, it feels
unnatural with my experience on other programming languages and math:
1)Prefix operator for math formula. Jeffrey Bester’s math library
https://github.com/jbester/cljext/blob/master/cljext/math.clj has
brought in the infix notation and solved the problem;
2)The leading item of a list follows the parenthesis when it serves
as a function name, (f x) instead of f(x). I am fully aware of many
discussions on alternative syntax for Clojure and Lisp in the past,
one stream is here
http://groups.google.com/group/clojure/browse_thread/thread/319a1c77ed718ba/3e4be7484b7cbe38
My proposition is enhance Clojure to accept both (f x) and f(x), the
leading item can appear either after ‘(‘ as usual with classic Lisp
notion:
(println Hello, world!)
or with conventional function call notation:
println(Hello, world!)
The f(x) notation is just a syntax sugar, the only restriction is no
space between the leading item and '('. If one or more spaces in
between, the item will be treated as a separate symbol. Either notion
or a mix of them can be used in the same program. Here are some
examples:
; classic Lisp syntax notation
(defn pig-latin [word]
(let [first-letter (first word)]
(if (.contains aeiou (str first-letter))
(str word ay)
(str (subs word 1) first-letter ay
(println (pig-latin red))
(println (pig-latin orange))
; f(x) syntax notation
defn(pig-latin [word]
let( [first-letter first(word)]
if(.contains(aeiou, str(first-letter))
str(word, ay)
str(subs(word, 1), first-letter, ay
println(pig-latin(red))
println(pig-latin(orange))
; classic Lisp syntax notation
(defn fib [n]
(if ( n 2)
1
(+ (fib (dec n) ) (fib (- n 2)
(fib 36)
; mix of two notations
defn(fib [n]
if(( n 2)
1
(+ fib(dec(n)) fib((- n 2)))
)
)
fib(36)
I have made minor changes (dozen lines) in one file (LispReader.java)
from Clojure source repository to implement this syntax sugar(code
posted at https://github.com/louisyulu/clojure-fx). It works with well-
formed classic Clojure code and the proposed notation.
Running the test suite from Clojure distribution results two error:
One in the file compilation.clj line 90:
(recur y ^Long(rem x y)]
The problem is ^Long(… becomes function call, the fix is adding a
space in between
(recur y ^Long (rem x y)]
The second is in the file sequences.clj line 1131:
(is (=(partition-by #{\a \e \i \o \u} abcdefghijklm)
The problem is (=(… , ‘=’ is associated with following ‘(‘, the
intention was the previous ‘(‘, the fix is also adding a space in
between
(is (= (partition-by #{\a \e \i \o \u} abcdefghijklm)
These two cases are caused by the not well-formed Clojure code
(strictly speaking, each item in the list should be separated by a
space).
The proposed syntax sugar apparently pleases my eyes and fingers from
conventional languages. With some experiments, I found the code is
more readable for me to use f(x) notation for function call, and (op
x) for operator.
I like to hear from the community what kind of dark corner the
proposed syntax sugar may run into.
Thanks,
Louis
This is an idea that happens quite frequently. Axiom, a lisp-based
computer algebra system, originally had a syntactic sugar almost
exactly like the one proposed. I uploaded an ancient design
document for this kind of language syntax, called boot. See
http://daly.axiom-developer.org/boot.tgz
This turned into a huge point of discussion. The Axiom decision
to remove this boot language eventually resulted in a fork of
the Axiom project.
Based on long experience I would strongly recommend NOT going
down this path.
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
Re: Literate Programming
On Sat, 2011-12-24 at 12:56 -0600, Jay Edwards wrote: Like this? http://brighterplanet.github.com/flight/impact_model.html My first reaction, after the first reading was almost ok. The task is reasonably mathematical so it seems useful to show the equations. Unfortunately, at the end, I have to ask myself the Hawaii question If someone sent me off to hawaii (so I couldn't talk to the author), would I know enough to maintain the program? Well, maybe. I really liked that they embedded a link to the impacts web page. That placed the problem in context. And I especially liked A multiplier to account for the extra climate impact of greenhouse gas emissions high in the atmosphere. Use 2.0 after Kollmuss and Crimmins (2009). I was unhappy with: =begin FIXME TODO date should already be coerced =end Really? Coerced to what, by what, for what reason, in what format? I was just hired and asked to solve this problem. =begin FIXME TODO deal with cities in multiple countries that share a name Tried pushing country, which works on a flight from Mexico City to Barcelona, Spain because it does not include flights to Barcelona, Venezuela BUT it doesn't work if we're trying to go from Montreal end up with flights to London, United Kingdom. Also pushing country breaks addition of cohorts - all 'AND' statements get changed to 'OR' so you end up with all flights to that country e.g. WHERE origin_airport_iata_code = 'JFK' OR origin_country_iso_3166_code = 'US' =end So why isn't this part of the dialog? Why does it break? Is the database improperly structured? Do we need a schema change? Or do we need program logic to handle this case? The use of FIXME is horribly jarring. Get rid of it. Think of a calculus textbook where the source code is the equations. Now imagine that in the middle of an equation you see the above comment. Something like: area = \sum_i^j x*3 =begin FIXME might be x^4 =end * y The editor-in-chief would never let the above equation get into the text. The FIXME should be discussed as part of the prose rather than in the equations. I don't think it would pass the code review phase with these FIXME things hanging around. FIXME is the programmer's internal dialog. Discuss the issue in the text as though you were talking to someone other than yourself. Odds are good this is where a design mistake (e.g. in the database schema) or a program bug lurks. The meta-issue is distinguishing communication from documentation. Literate programming is about communication, not documentation. Write with your audience in mind and assume that the audience is NOT your shower committee (a shower committee is the group of people you talk to in the shower who are not really there). This example really skates along the border. Overall I think it is wildly better than most examples I've seen. I'd much rather maintain this program with the text than without it. I'd certainly place it on the high side of the curve. 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
Re: Literate programming
On Thu, 2011-12-22 at 20:19 -0800, nchurch 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 I looked into cloning a github into lithub but that path won't work. Github does not publish its source code. Other things like gitorious are available but the setup is a challenge. 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
Re: Literate programming
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. Do yourself a favor and lose the great coder meme. Or get a job at google and remain blissfully unaware. One of the best books I've ever read about programming is called Practicing: A Musician's Return to Music where the author talks about his development as a musician. He would receive compliments on how great he was at playing the guitar. At one point he replies How would you know?. The better he got, the worse he knew he was. Your opinion of how great you are at programming will follow a bell curve. You'll start off coming out of college thinking you're ok, memorize a few algorithms and order theory (the google disease) and think you're great (google only hires great coders). But as you learn more you'll discover that you have SO much more to learn and as you work on larger projects you'll discover the musician's insight. People would rate you great but you'll be able to say How would you know?. At which point, the better you get, the worse you'll know you are. Anybody who rates themselves as great is probably on the uphill side of the learning curve. The fact that you're trying to learn Clojure, moving into areas that are beyond your comfort zone, and trying to learn literate programming to improve your game, all points to the fact that you will likely reach a point where you feel that being labeled great is a sign that the speaker is clueless. Give it 1 hours. On Thu, 2011-12-22 at 20:59 -0800, nchurch wrote: 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! You found it. This is the magic hidden in literate programming. Writing the natural language explanation, either before or during coding exposes bugs before they get into the code. It exposes hidden assumptions that will break boundary cases. It is hard to demonstrate this effect. You have to try to write a literate program and wait for the aha! moment to occur. Lisps in general, and Clojure in particular, have the same aha! moment where you transition from how could anyone code like this? to how could anyone code any other way?. Pick some useful task, like a code-walker that will list all of the called functions in a Clojure s-expression, and try to write a literate version. Odds are good that you will learn more than you ever wanted to know about Clojure. And, oh-by-the-way, everyone else can read your literate code and learn Clojure too. How sweet it that? 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
Literate Programming
Good Sir and Fellow Traveler, On Fri, 2011-12-23 at 03:33 -0800, Adam Getchell wrote: Having received the benefit of your kind reply, I must confess to a puzzlement which has vexed me ever since I read your missive. It is this: how should I have read it so as to receive some knowledge or insight with which I had not formerly possessed in the moments prior? For in truth I have not been able to discern its helpfulness thereby. Methinks thou hast conflated the spirit of literate programming, intended as a communication medium between fellow traveling souls on this dark road with the substance of the task involving the choice of conveyance and walking stick. Replying to the former 'twas I, whilest thou was't addressing the latter. We did pass by in our respective darkness. Forgive me for lacking light to guide your chosen path. I mistook your destination for mine own, a grievous fault, one to which I am ever prone. Clearly, as a craftsman of computer algebra tools yourself, you must agree that the selection of implements is of some import, lest you abandon that enterprise entirely and use Mathematica instead. Truly I do quake at the co-opting possible should the fair winds drift the conversation from the soul of the art to the choice and heft of tooling. Like the goodly Saint Alexander [1] we need to seek the order which contains life. What doth make a program live, or the building alive, is not to be found in the tooling but in ourselves. We must eschew the pernicious present practice lest we find our creation among the dead and dying on Sourceforge. I have chosen minimal tools for my algebra opus. Latex for smithing and tangle for forging. I find no need for any other save the, as yet unrealized, potential of graphing tools. 'Tis not the tools but my poor craftsmanship that constrains the quality of the work. The combination of literate + TDD seems forbidding Are you finding it hard to explain why you wrote a test? In this platonic exchange is made apparent my confusion. The dross of failures that skins the molten and fluid gold of your smelting needs but a few words. Lo, this might arise at the boundary of my creation. That the dross needeth explaining to the Smithy new to your endeavor, yet still it certainly can be conveyed in flowing natural language. Sharing the tale of the journey, the wonders of the vision, and the pleasures of final offering depends not on the choice of pen but on the craftmanship of language. That the gentle reader delight in your creation and sing its praises, see the vision, and dedication lifeblood to its continuance is all. That we might achieve such essential Quality [2] with Clojure is the dream. Sir Tim Daly, Elder of the Internet [1] Alexander, Christopher The Nature of Order: The Phenomenon of Life 2002 ISBN 0-9726529-1-4 [2] Persig, Robert Zen and the Art of Motorcycle Maintenance: An Inquiry into Values 1974 ISBN 0-553-27747-2 -- 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
Re: Literate programming
On Tue, 2011-12-20 at 00:26 -0800, Adam Getchell wrote: On Fri, Oct 28, 2011 at 2:45 PM, Damion Junk jun...@gmail.com wrote: I have also been using Emacs/Org-mode/Babel/R lately, mostly as a way to have easily modifiable write up and source code for assignments in statistics courses. I suppose this is one valid use, but I'm using it less to communicate code meaning and more as a convenient way to perform analysis, look at the results, and talk about them all in the same place, and then to easily generate documentation of my efforts [LaTeX output]. I'm interested in how you're including LaTeX in your code, as I'm writing models which require LaTeX to express what they're modelling. BTW I looked at marginalia+leiningen, which seems to work for my purposes except I'm unclear where to put the .tex files. I'm not sure what this sentence means. The .tex files ARE the literate program. By analogy, you seem to be asking something like I'm writing a book but I don't know where to put the text. The combination of literate + TDD seems forbidding. Are you finding it hard to explain why you wrote a test? 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
Re: Literate programming
On Thu, 2011-12-22 at 15:35 -0500, Larry Johnson wrote: On Thu, Dec 22, 2011 at 2:54 PM, daly d...@axiom-developer.org wrote: The combination of literate + TDD seems forbidding. Are you finding it hard to explain why you wrote a test? Tim Daly I decided awhile back when trying to answer questions about literate programming, that people get caught up in the moving parts, and not in what the approach actually yields. Your statement above puts it nicely and succinctly, and hearkens back to Knuths original articles. Lately I emphasize the woven text (without inititially calling it that) Untangling woven text is trivial. It can be done in any language. See http://axiom-developer.org/axiom-website/litprog.html and ask the person I'm talking with to imagine writing an article or book about their code, how it works, with proofs where appropriate. That article should be written as a work of literature. Not all literature has to be Hugo or Melville (or Jack Kerouac, or Gertrude Stein for that matter). Some programs are more appropriately Mickey Spillane or Terry Pratchett, or even in the style of a manual for an electric razor. The point is that it should be satisfying to read and comprehensively informative. Test code, and descriptions of external libraries are no different from any other sections of the article or book. The most important thing is to introduce them into the work at point most conducive to the reader's understanding. If a test is testing something worthwhile, as opposed to the blindly testing that 3=3 mindset, then it probably only takes a couple lines to motivate why you need the test. A test paragraph could contain the details. So if you're writing a hash table implementation, the test code of overflow chaining could explain what problems might occur (e.g. what happens when the table is actually full? How do you detect that the overflow chain has looped?, etc.) So if you wrote the hash table implementation code in literate form then each test could explain (and test) a particular boundary case or issue that might arise. This has the effect of motivating tests that are detailed, based on real issues, and handle boundary cases clearly. I really believe that there's no programming or engineering methodology which doesn't lend itself to literate programming. If it can be described, it can be presented in the form of an article. If it can't be describe in human language it's probably terrible code. Test cases don't have to appear as test cases. They appear in the text as either example code (useful for the reader but also testing) or as explanations of possible failures, misuse, misapplication, or boundary cases. This is especially powerful if you focus your tests on precondition/postcondition testing. See Hoare's paper An Axiomatic Basis for Computer Programming http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.116.2392 Using Hoare's ideas to focus the development of your test cases means that your tests have a good theoretical basis. They check for the conditions that should survive refactoring. Requiring precondition postcondition tests, along with clearly written natural language explanations, could be part of the peer code review prior to accepting new or revised code into the main line. Better yet, in a literate program, you can explain what the invariant is, why it is important, and what breaks when you violate it. So testing now has a good formal basis rather than random 3=3 tests. We can be so much better programmers. Raise your game. Be literate. 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
Re: Literate programming
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
Simple evaluation and environments
The Clojure community might find this article interesting. http://www.dalnefre.com/wp/2011/11/fexpr-the-ultimate-lambda He points out that Fexpr is more primitive (in the sense of simple) than Lambda. Fexpr decouples the operand access from the operand evaluation allowing more detailed control. (Fexpr is an old MacLisp term.) Given an s-expression there is always a question of what the symbols mean. The meaning is supplied by the environment, of which there are many. For instance, there is a dynamic environment (runtime call), the static environment (the value at the time the text is written), the macro environment, etc. See chapter 2 of Lisp in Small Pieces for a really in-depth discussion. It is hair-hurting discussions like this that make lisp so much more interesting than other languages. There isn't a way to express the concepts in other languages. Tim Daly There is no such thing as a *simple* job :-) -- 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
Re: Simple evaluation and environments
In http://www.dalnefre.com/wp/2011/11/fexpr-the-ultimate-lambda
Dale Schumacher writes:
One way to look at the difference between functional and object-oriented
algorithms is to consider the relationship between types and operations.
Let’s say I have a small set of types {A, B, C} and operations {f, g, h,
+}.
f
g
h
+
A
f(x:A) → A
g(x:A) → B
h(x:A, y:C) →
B
x:A + y:A → A
B
f(x:B) → B
g(x:B) → C
h(x:B, y:C) →
A
x:B + y:B → B
C
f(x:C) → C
g(x:C) → A
n/a
x:C + y:C → C
Table 1 shows how these operations might be modeled with functions. The
same function name refers to different operations based on the argument
type(s). Operations are grouped by function name, as shown by the
columns of the table.
Consider the table above. You can walk the type circle from A-A
by the calls: g(A)-B, g(B)-C, g(C)-A, or equivalently,
g(g(g(A)))-A.
Now consider making the same table for Clojure types and functions.
A might be a list, B might be a hash-map, etc. The f function
might be conj.
Given such a clojure table, the question is: Can we complete the
circle for each data type? Are we missing any functions? Is our
set of chosen functions orthogonal? Given the set of types and
a list of functions could we construct the table automatically?
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
Re: Literate Programming in Emacs?
I would be really interested to see some examples of literate programs. Please consider releasing them as open source, possibly pushed to github. Tim Daly On Tue, 2011-11-29 at 11:26 -0800, Stuart Sierra wrote: Here's the relevant bit of my .emacs for Babel + Clojure: https://github.com/stuartsierra/dotfiles/blob/cb88b1ca020fd5beebb3de092f12aa27daddd779/.emacs#L203 This requires Org mode version 7.7. I mostly use inferior-lisp mode instead of SWANK/SLIME. -S -- 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
Re: Literate Programming example
chastise me for failing to explain, or explaining things that the code does not do, or just plain failing to implement a correct solution. I have found that literate programming makes me a better programmer. Convincing people to use literate programming is like convincing them to use lisp. Before the AH-HA moment occurs they can't imagine why anyone would code this way. After the AH-HA moment they can't imagine why anyone would code any other way. I have clearly crossed that line. 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
Literate Programming example
Many of you asked me to show an example of a literate program and demonstrate the use of the tangle function. I usually use Latex for literate work but I've done this example using HTML and pre id=foo tags. I've written a self-referential literate program that explains the details of the tangle function in literate form. You can find the web page at http://daly.literatesoftware.com/lithtml/litprog.html and the source for the tangle function (which is in the web page but) http://daly.literatesoftware.com/lithtml/tangle.c I appreciate the time and attention you all gave me at the Clojure Conj. Hopefully someone will catch the ah-ha and write a literate program for next year's Conj. Tim Daly d...@literatesoftware.com -- 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
Re: Literate Programming example
sigh. Try http://daly.axiom-developer.org/lithtml/litprog.html On Fri, 2011-11-18 at 07:46 -0500, Chas Emerick wrote: On Nov 18, 2011, at 7:17 AM, daly wrote: http://daly.literatesoftware.com/lithtml/litprog.html FYI, this is 404 at the moment. - Chas -- 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
Re: Literate Programming example
I believe I fixed it. Please try it again and let me know. Tim On Fri, 2011-11-18 at 07:46 -0500, Chas Emerick wrote: On Nov 18, 2011, at 7:17 AM, daly wrote: http://daly.literatesoftware.com/lithtml/litprog.html FYI, this is 404 at the moment. - Chas -- 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
Re: Literate Programming example
On Fri, 2011-11-18 at 07:07 -0800, bernardH wrote: On Nov 18, 1:17 pm, daly d...@axiom-developer.org wrote: Many of you asked me to show an example of a literate program and demonstrate the use of the tangle function. Thanks to your perseverance, I am looking into practicing literate programming. However, I decided to settle for emacs org-mode environment with the literate elisp for the relevant code (abel'part of org-mode) being here : http://eschulte.github.com/org-babel/org-babel.org.html I found an example of clojure project (research on genetic programming) written in literate programming using babel org-mode for emacs is hosted here : http://gitweb.adaptive.cs.unm.edu/asm.git/tree I do hope that others find those resources as useful as I found them. I have nothing against org-mode. Indeed, I've been an emacs user since I could spell it. I believe the above examples are not literate programmings. They miss the point completely. They are using emacs org-mode for DOCUMENTATION. Literate programming is NOT documentation. It is a way to communicate from one person to another by starting from ideas and reducing them to practice. I may have missed the point but the above programs are just fancier ways of 1970 style coding using a new format tool. Compare the example I gave at http://axiom-developer.org/axiom-website/litprog.html with the above programs. See if you can spot a qualitative difference. My literate program tries to motivate the need for tangle, to explain why it works in a development context, and then gets down to details of implementation. It is a story. Where does this happen in the org-mode example? Perhaps I missed something but the author does not seem to be concentrating on communicating their ideas to me. Where did I go wrong? What emacs keystrokes get me a copy of the full document to read? Literate programming is about communication, not documentation. The org-mode tool is perfectly fine but be very, very careful not to miss this fundamental point. People should be able to just pick up clojure-core and read it like a novel, from ideas to implementation, and be able to understand it enough to change it. If your code can pass this independence test then your code is literate. Tim -- 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
Re: Reactions to google dart?
Doug Crockford was asked for his reaction to coffeescript. He loved it. He was asked for his reaction to Dart and he said that the set of features that Dart chose are not the set of features he would have chosen. Crockford on JavaScript - Section 8: Programming Style Your Brain http://www.youtube.com/watch?v=taaEzHI9xyY On Thu, 2011-11-17 at 22:22 +0530, Qihui Sun wrote: Google Dart vs. ClojureScript Dart - Dart is a new class-based programming language for creating structured web applications. Developed with the goals of simplicity, efficiency, and scalability, the Dart language combines powerful new language features with familiar language constructs into a clear, readable syntax. 1,Isolates as basic concurrent construct 2,rich web browser lib,such html,DOM... 3,more ClojureScript - ClojureScript is a new compiler for Clojure that targets JavaScript. It is designed to emit JavaScript code which is compatible with the advanced compilation mode of the Google Closure optimizing compiler. 1,macro 2,more Both are used to web browser and server side,complies to JavaScript,cross browers. 2011/10/15 Isaac Gouy igo...@yahoo.com On Oct 11, 7:43 am, Timothy Washington twash...@gmail.com wrote: I believe this is google's official blog http://dartinside.com/ to discuss and track issues around Dart http://www.dartlang.org/ ... H - Dart Inside The Unofficial Google Dart Blog Dart Inside is an online service from Trifork A/S, and is not affiliated with Google®. -- 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 -- Solomon HUAWEI Google+: Qihui Sun -- 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 -- 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
Announce: ClojLisp -- Clojure-in-CommonLisp
I have created a 0th iteration of the clojure in common lisp effort. git clone git://github.com/daly/clojlisp.git will create a directory called clojlisp containing: README -- how to get started from scratch clojlisp.pamphlet -- the literate program clojlisp.pdf -- a pdf generated from clojlisp.pamphlet clojureIcon.eps -- a pretty icon tangle.c -- the program for extracting chunks Makefile -- the basic tool for creating the code changelog -- a list of changed files You could read the README or just type: gcc -o tangle tangle.c make xpdf clojlisp.pdf sbcl (load clojlisp.lisp) (in-package CLOJLISP) (clojlisp) (common-lisp::+ 2 3) (sb-ext:quit) emacs clojlisp.pamphlet ... change stuff ... make Tim Daly Literate Software d...@literatesoftware.com -- 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
Clojure-in-CommonLisp?
It seems to me that a Clojure in Common Lisp might be the easiest non-JVM port. It would be a DSL within Common Lisp. A CL implementation would even allow rewriting the normal COND syntax. Is there an obvious reason why this would be a bad idea? Heck, it might even be possible to make the port literate :-) 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
Re: Clojure-in-CommonLisp?
On Mon, 2011-11-14 at 16:26 -0800, Phil Hagelberg wrote: On Mon, Nov 14, 2011 at 4:18 PM, daly d...@axiom-developer.org wrote: It seems to me that a Clojure in Common Lisp might be the easiest non-JVM port. It would be a DSL within Common Lisp. A CL implementation would even allow rewriting the normal COND syntax. Is there an obvious reason why this would be a bad idea? The biggest problem I can see is that if you do this I will be tempted to port it to Emacs Lisp as well, the thought of which is slightly disturbing. -Phil I knocked together a REPL in its own package. Is there a spec somewhere of the exact syntax accepted by the Clojure reader? 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
Re: Clojure Conj extracurricular activities spreadsheet
Well, despite my best efforts I'm unable to edit the spreadsheet. The Literate Software talk was supposed to be at 7pm in the Presidents Ballroom but it appears that Pallet has reserved that time. I'll default to the old-fashioned BOF schedule board when I arrive to try to post a time and place. Tim Daly On Mon, 2011-11-07 at 11:18 -0500, David Nolen wrote: Anybody mind if the miniKanren / cKanren presentation happens at 6pm Thursday in the main ballroom? David On Mon, Nov 7, 2011 at 10:53 AM, Christopher Redinger redin...@gmail.com wrote: On Thursday, November 3, 2011 3:46:40 PM UTC-4, David Nolen wrote: Any thoughts about when / where these events can take place? Is it possible to get access to a projector? Or do we have to fend for ourselves? We have modified the contract with the hotel to keep the projector in the main ballroom on Thursday evening until midnight. -- 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 -- 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 -- 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
Speculative Execution
One of the benefits of immutable data structures is the ability to do speculative execution. You can compute an answer and if you don't like it you can just abandon it. This is useful for techniques like backtracking. I don't see this idea mentioned anywhere in Clojure but I think it would make an interesting bullet point. 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
Re: Clojure Conj extracurricular activities spreadsheet
What times are available? How can I choose a time for the literate session? Tim Daly On Sat, 2011-11-05 at 10:37 -0400, Doug South wrote: On 04/11/2011, at 9:16 PM, Michael Fogus mefo...@gmail.com wrote: Any thoughts about when / where these events can take place? At this point it would be great if a Conj-planning heavyweight could step in and provide some additional ideas... although solutions would be great too. :-) According to the conference schedule the conference room is available until 11pm on Thursday. I don't know how big the room is, but as long as the Overtone folks don't get too loud ;), that might be a good place and time to have a mini open conference. As long as all the people involved take responsibility for returning the room to it's conference state at the end of the night, that might work well? Regards, Doug Sent from my iPhone -- 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
Re: Clojure Conj extracurricular activities spreadsheet
So, to be specific, lets assume that the literate programming session will meet in the presidential boardroom at 7pm on wednesday evening. It will likely be a small group and I don't expect it to take long. It is only scheduled for 15 minutes. Tim Daly On Sat, 2011-11-05 at 19:10 -0700, Christopher Redinger wrote: On Friday, November 4, 2011 9:16:08 PM UTC-4, Fogus wrote: At this point it would be great if a Conj-planning heavyweight could step in and provide some additional ideas... although solutions would be great too. :-) Oh, I guess that's me. See the floorplan for reference. We have the Oak Forest ballroom until midnight on Thursday and Friday and until 5pm on Saturday. This room holds 300 people. Since this is the main conference room, we would need it back in the same setup when the room is locked up at midnight that we need it when it is unlocked the next morning. We have the Atrium area, which is setup to hold around 50 people at round tables, until midnight on Thursday and Friday and noon on Saturday. This is designated as our game area. So, Go should definitely be happening here. This is an open area, and will feel more publicly accessible, passersby will possibly stop to see what's going on if it looks interesting. We have the Presidents Boardroom until midnight on Thursday and Friday and 6pm on Saturday. This is a small room that can hold about 20. So, smaller groups should use this room. There are also smaller public spaces round the ballroom where people could meet up for some organized hack sessions, etc. But, keep in mind that things are pretty heavily scheduled during this time as well. The plan is to have lightning talks in the ballroom on Thursday evening. Of course, many of those can be combined with the planning that's happening here. And Friday night, we have the party at the ArtSpace. Beyond that ... Chas said something about using his room when I mentioned I was wondering when and where all of these things were going to take place. I'm going to have to assume everyone that wants to organize some kind of activity is willing to do something similar. :) -- 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 -- 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
Re: Homoiconicity in clojure (macro power)
While Peter Norvig was discussing Python with John McCarthy (inventor of lisp) in the audience: John simply asked if Python could gracefully manipulate Python code as data. No, John, it can't was Peter's reply. Create a list and call read on it. Create a function, manipulate it as a list to modify it, walk it, print it, and treat it as a list in general. In particular, a macro is a list that operates on a list to produce a list that gets used as a list, possibly to define a data structure, or a function, or another macro or whatever else you might want. Lisp code is data. Lisp data is code. This is not true in most other languages. Tim Daly On Mon, 2011-10-31 at 02:40 -0700, vikbehal wrote: I am from java Background. We say Homoiconicity in Clojure (Lisp). Code is data and data is code. I read various blogs on it, still not clear, Can you give me some example? -- 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
Re: modern clojure summary
On Sun, 2011-10-30 at 09:04 -0700, Bill Robertson wrote: On Oct 27, 9:10 pm, falcon shahb...@gmail.com wrote: In Rich's most recent talk, Simple Made Easy, he mentioned that clojure for javascript was built from the ground up using protocols and other modern clojure constructs. Is there a resource which describes clojure using modern concepts, rather than introducing feature as they were added in a chronological order? Have you considered the Clojurescript source code? If it embodies these concepts then it should be a good place to start. This is exactly the point of literate programming. It should be possible to point to the source code and be able to read an explanation of the concepts. Note that the bare source code would only tell you how to compute the results, not why you might want to compute them or how the results fit into the larger context. 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
Re: Literate programming
On Fri, 2011-10-28 at 11:59 +0200, Tassilo Horn wrote: Hi Tim, while I agree that good documentation is important for maintaining and developing further a given code base, I always wonder how literate programming deals with refactoring and larger restructuring. I mean, in basically all software projects I'm involved in, developers have a hard time in keeping at least the most integral documentation up-to-date, e.g., docstrings, JavaDocs, etc. Now I consider a some literate code base, i.e., a book that describes the complete system in a very detailed manner including the reasons to design it that way. That's awesome for developers joining the project, but doesn't it hinder any further development? For example, I'm currently reworking some paper that includes code for some model transformation. If I had the right tools, I could extract the source code from the latex files and have a running transformation. But now, I had to do some minor modifications to the code which took me about 5 minutes, but adapting the surrounding text takes me hours over hours. I think, that's an experience many people have made: changing source code of a system that is well-designed and understood by the developer is much easier to do than changing a cohesive text in natural language. In code, I have an automated, picky lector that always reads the complete book after each change I make (also known as compiler). In plain text, only a human can verify consistency and only in very narrow borders. Well, that's more text than I intended to write. ;-) So short story long: how do you manage conistency of docs and code in literate code bases? Hard work? Book authors face the same problem. Every new change to Clojure makes more work for the authors. One side-effect of Literate Programming is that you re-arrange your code to fit the presentation. As a result you bring together chunks that are all related (e.g. the code to support Red-Black tries). I would claim that refactoring in the large is unlikely in a literate program because you have to think through the code in order to explain it clearly. But if you do a large refactor then it is just hard work. For small refactorings you might not have to change the explanation at all. Clojure is pretty well firmed up at this point. I don't know if there is going to be a large rewrite of the fundamentals. 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
Re: Literate programming
On Fri, 2011-10-28 at 09:54 -0700, Mark Engelberg wrote: On Thu, Oct 27, 2011 at 10:58 AM, daly d...@axiom-developer.org wrote: Have there been any new developments on the literate programming / Clojure front, in terms of tools that leverage existing build tools, test suites, generating meaningful line numbers for stack traces and debugging? The question is ill-posed in sense that literate programming is not a tool or technology but a change in mindset. To quote Knuth: I think my question is legitimate. To take an extreme example, if you tell me literate programming is great, but that I have to write out my programs by hand on paper and scan them into a computer, I'd laugh at you. Why would I want to give up the convenience of typing in my programs via keyboard to do literate programming? I'm not sure what tools you use for development. Straight emacs is sufficient for my development. Emacs doesn't care what style is used for development. So I'd like an honest appraisal of the state of the art in literate programming of Clojure -- what tools and conveniences do I have to give up to do LP. Do I have to give up things like meaningful line numbers when I get an error message? State of the art in literate programming in Clojure? Hmmm. The pamphlet link is my only example of literate programming related to Clojure. In order to develop you edit the pamphlet, type make at a command line, and the world is rebuilt. Since the code is extracted into the same source tree as it originally had, the line numbers will be related to the file and line as before. My development style involves changing about 10 lines of code or less followed by a complete system rebuild and test cycle. Overlapping rebuild and test is time for writing the literate explanations. Almost always, when something fails it is perfectly clear what lines caused the error. When that isn't the case then a little navel debugging (contemplating what might be wrong) is used. I don't use IDEs but I suppose it would be possible to write a literate plugin of some kind that ignored things that were not in code chunks. Line numbers could then be interpreted with respect to the start of the chunk. Most IDEs allow plugins. To your point, though, it is true that we may have reached a local optimum of tool development for tiny files. It might be necessary to move away from this peak in order to climb a different hill. This would imply making things worse for development until the tools adapt. Clojure moved off the local optimum of common lisp and broke all my code-walking software, violated quite a few of my assumptions, and invalidated my manuals but that isn't an argument for abandoning Clojure. You might feel that the current toolset is optimal and that literate programming is not worth the time and effort. De gustibus non disputandum. (There is no disputing taste). A literate Clojure would only be of benefit to those who come after. All it offers now is a lot of time and effort to communicate ideas to people we will never meet. However the thing that draws people to Clojure is the ideas, not the code. We can debate it at length over beers at the Conj. 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
Re: Literate programming
Try http://en.wikipedia.org/wiki/Literate_programming or the original paper www.literateprogramming.com/knuthweb.pdf or from the master himself: http://www-cs-faculty.stanford.edu/~uno/lp.html Tim Daly On Wed, 2011-10-26 at 19:49 -0700, jaime wrote: is there a place introducing (e.g. overview) more about Literate? have no ideas about this stuff. On Oct 27, 3:06 am, d...@axiom-developer.org wrote: I see that my Literate Programming session is beginning to gain some traction. I would encourage you to bring examples. We can discuss the merits and possibly gain some new insights. If nothing else, please sign up for the Literate Software session at Clojure-Conj. I promise to keep it short. Literate programming can take various forms. I am working on a survey of literate software. I came across an interesting non-latex example worth sharing: http://jashkenas.github.com/coffee-script/documentation/docs/nodes.html Notice how well they have documented an apparently simple line as in: exports.Base = class Base The Base is an abstract base class for all nodes in the syntax tree. Each subclass implements the compileNode method, which performs the code generation for that node. To compile a node to JavaScript, call compile on it, which wraps compileNode in some generic extra smarts, to know when the generated code needs to be wrapping up in a closure. An options hash is passed and cloned throughout, containing information about the environment from higher in the tree (such as if a returned value is being requested by the surrounding function), information about the current scope, and indentation level. Notice how this is not only giving trivial information (e.g. Base is an abstract base class) but WHY it exists (..as a base for all nodes in the syntax tree). It gives operational information (to compile a node..) as well as information about the effect (..which wraps...). It shows how global information is used (An options hash..) and WHY (containing information about the environment...) Code only tells you HOW something is done at the time it is done. It's like having a recipe without an idea what you would make. If our standards of documentation were raised to this level then large systems like Axiom, Clojure, and ClojureScript would be much easier to maintain and modify in the long term. If you want your code to live beyond you, make it literate. Tim Daly d...@literatesoftware.com -- 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
Re: Literate programming
On Thu, 2011-10-27 at 00:17 -0700, Mark Engelberg wrote: Tim, I recall that at some point you described your setup for doing Clojure literate programming, and if I recall correctly, you were primarily working in LaTeX, relying on incremental compilation to test little snippets of code as you wrote them. Yes, the idea is to write a literate version of Clojure, see http://daly.literatesoftware.com/clojure.pamphlet http://daly.literatesoftware.com/clojure.pdf similar in style to Lisp in Small Pieces. (The effort has been stalled temporarily while I try to find new employment.) From the above document you extract the Makefile, type 'make' and end up with the newly formatted PDF and a running REPL. So any edits to the document text are immediately reflected in the PDF and any edits to the code are immediately reflected in the compiled results. Have there been any new developments on the literate programming / Clojure front, in terms of tools that leverage existing build tools, test suites, generating meaningful line numbers for stack traces and debugging? The question is ill-posed in sense that literate programming is not a tool or technology but a change in mindset. To quote Knuth: I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title Literate Programming. Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. -- Donald Knuth Literate Programming (1984) CSLI 1992 pg. 99 So imagine a world where the eloquence of Rich Hickey was expressed in book form. Imagine the whole immutability lecture written down and decorated with the actual running code as illustration. Imagine that the original authors clearly explained software transactional memory and illustrated it with the actual code. Imagine a discussion of argument destructuring with running code illustrations. How many more people would be able to dive into the details of Clojure to maintain and modify the code? How many people would find it much easier to understand prototypes, defrecords, macros, and all of the other struggles that populate the current email forums? How are infinite sequences supported and what code supports it? What does NIL mean and why was it defined that way? We do not capture the ideas. We do not rewrite the explanations to clarify the fine points of confusion. We do not illustrate how the ideas of Red-Black tries are moved from ideas to implementation. We do not communicate the ideas to each other. We code for the machine. So we end up with the traditional tree of sand pile of little files. In order to overcome this we construct tools (IDEs) that know how to navigate this pile, tools to store the changes (SVN, git, hg), tools to put the sandpiles together (#include), tools to build guardrails, tools, tools, tools... (You can, of course, keep each chapter and section and subsection in separate files and include them in the book.) Now imagine that the book is multimedia where you can include animation (watch the tree balance), video, and a running REPL. Think Khan Academy for Clojure. This community is willing to overthrow the traditional ideas of lisp in order to make progress on a new path. Yet we continue to structure the development as though we worked on a PDP 11/40 with 4k file size limits. We continue to let the most valuable information which is the meat of Clojure disappear while we keep only the code, the bones of Clojure. Open the source code. Stare at it. Ask yourself if you understand exactly why it was needed, why it is structured that way, what would happen if you changed it and what else depends on this code. Imagine your job is to maintain and modify it but Rich is not available for questions and answers. Ultimately that is what matters. In the long term the code will be the only remaining artifact after Rich leaves the project. Look at Sourceforge and you will see thousands of dead projects that will never be picked up because they are just trees of code, dead code. Et tu, Clojure? Literate programming is about making code live. I like Clojure and I really want it to live. Think long term. Imagine a better way. 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
Re: Literate programming
On Thu, 2011-10-27 at 20:11 -0400, Larry Johnson wrote: My two favorite articles on Literate Programming are both from Donald Knuth's book Literate Programming. One is Computer Programming as an Art, and the other is Literate Programming. When I was preparing to interview Knuth a bit over a year ago I re-read the entire book. I expected it to be a somewhat outdated description of WEB, TANGLE, and WEAVE. On the contrary it was wonderfully timeless. When I mentioned that to Knuth he sort of grumbled something to the effect of Well, yes, some things in computer science have a long shelf life (that's a paraphrase, but it was something like that). Knuth's invention of literate programming is one of the unrecognized pearls of computer science. I have yet to see a programming team that has an Editor-in-Chief who does patch-review for clarity, sentence structure, punctuation, relevance, location in the book, proper citations and index terms, etc. Maybe someday. I haven't been working with it for awhile, but I did a somewhat primitive modification to the XML Docbook markup language (I just added a few appropriate tags for tangling the executable source code, and weaving the well formatted article documenting the code) which I used as the source language, then wrote a tangle and weave in perl. I got the idea from Norman Walsh's article Literate Programming in XML which can be found at http://nwalsh.com/docs/articles/xml2002/lp/paper.html The advantage of this was that given the array of tools for rendering Docbook weaving was a piece of cake, and perl had a good range of modules for doing the tangle. Any means of publication can be the medium for literate programming. As I rule I prefer Latex but anything will do. All you need is a distinguished means of quoting and naming the chunks. In html this could be as simple as: pre id=somename your code /pre and you need a program, often called tangle, to extract the chunk tangle mywebpage.html somename mysomename.file The machinery of literate programming is dirt simple. Poof! You're done. The hardest part of literate programming is the mindset. In order to do literate programming you need to change your focus from traditional programming to writing for humans and, as a side effect, writing for the machine. As I stated, I'm very new to clojure, but I've always been fascinated with LP, and I'm very happy to see this discussion going on here. Java has taken the PDP 11/40 sand files to their logical extreme where we have wired the name of the tiny file to the name of the tiny object. We have packaged the automobile into a crate with labeled bags of screws, hoses, switches, etc. and are expected to understand the car. Clojure is a very early adoptive, open minded community willing to challenge old assumptions. It helps to highlight what those old assumptions are, as Rich has done for Lisp, since they can be difficult to see and hard to displace. I am hoping the community will disrupt the tiny-files, javadoc, IDE, code-for-the-machine, mindset and start communicating with humans. Rich has great ideas in Clojure and all we get is the dried bones of source code. We can do so much better. 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
Literate programming
I see that my Literate Programming session is beginning to gain some traction. I would encourage you to bring examples. We can discuss the merits and possibly gain some new insights. If nothing else, please sign up for the Literate Software session at Clojure-Conj. I promise to keep it short. Literate programming can take various forms. I am working on a survey of literate software. I came across an interesting non-latex example worth sharing: http://jashkenas.github.com/coffee-script/documentation/docs/nodes.html Notice how well they have documented an apparently simple line as in: exports.Base = class Base The Base is an abstract base class for all nodes in the syntax tree. Each subclass implements the compileNode method, which performs the code generation for that node. To compile a node to JavaScript, call compile on it, which wraps compileNode in some generic extra smarts, to know when the generated code needs to be wrapping up in a closure. An options hash is passed and cloned throughout, containing information about the environment from higher in the tree (such as if a returned value is being requested by the surrounding function), information about the current scope, and indentation level. Notice how this is not only giving trivial information (e.g. Base is an abstract base class) but WHY it exists (..as a base for all nodes in the syntax tree). It gives operational information (to compile a node..) as well as information about the effect (..which wraps...). It shows how global information is used (An options hash..) and WHY (containing information about the environment...) Code only tells you HOW something is done at the time it is done. It's like having a recipe without an idea what you would make. If our standards of documentation were raised to this level then large systems like Axiom, Clojure, and ClojureScript would be much easier to maintain and modify in the long term. If you want your code to live beyond you, make it literate. Tim Daly d...@literatesoftware.com -- 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
Re: Rich Hickey: Simple Made Easy from Strange Loop 2011
If I understand your post correctly you feel that nil should ONLY represent the concept of a missing value. It should not represent false and empty. Having used lisp in many different forms over the last 40 years I think that the complecting of nil to represent all three concepts is one of the most brilliant aspects of the language. In fact it is one of the key flaws of scheme, in my opinion, that they added true and false. There is a fourth use of nil that is also very convenient. Lisp functions return it as a default value. This makes it possible to wrap functions with functions which other languages like C++ make very difficult. (e.g. if we have a C++ function void foo() we cannot wrap it with another bar(foo()) well, we can but we have to use the comma hack as in bar((foo(),1)) ) Java code is littered with checks for null before every iterator construct where the code could be so much cleaner if iterators just did the right thing with null, that is, end the iteration. The use of nil as a unified value for the many meanings leads to a lot of useful features. The context of the nil value completely defines the intended meaning. Tim Daly On Fri, 2011-10-21 at 09:50 -0700, Mark Engelberg wrote: I've always felt that Clojure's treatment of nil was somehow inconsistent with the elegance of many other features of Clojure. Now I can finally articulate why: nil complects non-existence, false, and empty. The choice to make nil represent so many concepts was an easy choice, because it saves a few characters when you can write things like (when seq ) vs. (when (empty? seq) ...) and Clojure implements sequences in a way that the former expression is also a bit more performant. It is also easy in the sense that it is more similar to what Lisp users (as opposed to Scheme) are used to from past experience. But it is decidedly less simple to have these ideas complected. Over the past couple of years, I've seen numerous bugs along the lines of Your function usually works great, but it breaks when the list/map/vector you pass in contains nil values. It seems clear to me that nil's complexity makes programs harder to analyze, because when you're writing your code, you might be thinking of nil as only representing non-existence or emptiness, for example, and forgetting that the system will treat nil as a false value as well. -- 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 -- 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
Re: Rich Hickey: Simple Made Easy from Strange Loop 2011
On Fri, 2011-10-21 at 12:36 -0700, Mark Engelberg wrote: On Fri, Oct 21, 2011 at 11:43 AM, Mark Engelberg mark.engelb...@gmail.com wrote: How does nil represent empty? '() does not equal nil. (cons 1 nil) is one obvious example. The pattern of using first/next/nil? as a more efficient/compact alternative to first/rest/empty? is arguably another. One more anecdote about this. One time, I wrote a function that looked like this: (defn f [s] (when s .)) At the time I wrote the function, I did the analysis, and realized that my function was always being called with sequences (specifically, sequences that had already been seq-ified at some prior point), so it was safe to use when as a way to screen out the empty things. So I opted for this easy, efficient way to express this. Somewhere along the line, as my application grew more complex, I needed to reuse f in another context, and when looking at the docs for f (which said something like consumes a sequence and does ..., I thought I could safely pass in a lazy sequence. But I couldn't because when a lazy sequence is empty it is not nil. My program was buggy and it took a while track down the source of the problem. THIS is where the multiple meaning of nil in traditional lisp is brilliant. I believe that Clojure got it wrong in the design decision to make (seq s) and (not (empty? s)) have different semantics. This is the same mindset that causes (me) so much grief in Java... looping and iteration does the wrong thing with NULL and I have to check for NULL every time. Yet everyone, if given an empty list of things to shop for, will know NOT to go shopping. Yes, it was my fault. In retrospect, I see that my program would have been more robust had I not made assumptions about s, and written it as (when (seq s) ...) or perhaps (when (not (empty? s)) ...) Actually I don't think this is entirely your fault (modulo the fact that we need to understand our language semantics). I believe that this is due to a deep design flaw. You're not the only person to mis-handle an empty sequence. But I do think it's fair to pin at least some of the blame on the complexity of nil. Since nil can be used interchangeably with the concept of emptiness in so many circumstances, and was interchangeable in the initial context of my function, it was all too easy to rely on that behavior. Tim Daly Literate Software -- 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
Re: Rich Hickey: Simple Made Easy from Strange Loop 2011
On Fri, 2011-10-21 at 15:41 -0400, David Nolen wrote: Just because we have dynamic types does not give us the freedom to not consider them. If all of these dynamics types and all of the tests respected nil in its many meanings then (when s ..., (when (seq s)..., (when (empty? s)..., would not be an issue. (when s...) would just work. Clearly express a consideration about the types at play. Clojure was supposed to transparently substitute things like sequences and vectors everywhere that lisp used lists. That would be true if nil was respected but is not true now and this complicates the code without apparent benefit, in my opinion. In lisp you can ask what the type is (e.g. by calling consp, vectorp, etc) but these type-specific predicates are relatively rarely used. In fact, when they are used then you are struggling with data-level issue that could probably be abstracted away (e.g. a code smell). Clojure is a great language but the nil handling is, in my opinion, a design flaw. It forces the introduction of (empty?...) and an awareness of the data types into view unnecessarily. Tim Daly Literate Software -- 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
Re: Rich Hickey: Simple Made Easy from Strange Loop 2011
Rich,
My apologies that what I have said about nil punning came across
as criticism directed at you. That was not intentional. I have
the highest respect for your design work. You're doing an amazing
job and I continue to learn from you.
I understand the lazy vs empty issue and I think you made a good
tradeoff. I'm just bemoaning the fact that nil-punning is really
vital in keeping data-type issues out of my lisp life and that
won't work in Clojure.
Ultimately this is cured by deep learning of the language semantics.
I still have a way to go.
Tim Daly
Literate Software
On Fri, 2011-10-21 at 17:03 -0400, Rich Hickey wrote:
This message is not specifically in reply to Tim, but to the thread in
general.
It can be very difficult to enumerate (or even remember :) all of the
contending tradeoffs around something like Clojure's nil handling.
The is no doubt nil punning is a form of complecting. But you don't
completely remove all issues merely by using empty collections and empty?,
you need something like Maybe and then things get really gross (IMO, for a
concise dynamic language).
I like nil punning, and find it to be a great source of generalization and
reduction of edge cases overall, while admitting the introduction of edges in
specific cases. I am with Tim in preferring CL's approach over Scheme's, and
will admit to personal bias and a certain comfort level with its (albeit
small) complexity.
However, it couldn't be retained everywhere. In particular, two things
conspire against it. One is laziness. You can't actually return nil on rest
without forcing ahead. Clojure old timers will remember when this was
different and the problems it caused. I disagree with Mark that this is
remains significantly complected, nil is not an empty collection, nil is
nothing.
Second, unlike in CL where the only 'type' of empty collection is nil and
cons is not polymorphic, in Clojure conj *is* polymorphic and there can only
be one data type created for (conj nil ...), thus we have [], {}, and empty?.
Were data structures to collapse to nil on emptying, they could not be
refilled and retain type.
At this point, this discussion is academic as nothing could possibly change
in this area.
The easiest way to think about is is that nil means nothing, and an empty
collection is not nothing. The sequence functions are functions of collection
to (possibly lazy) collection, and seq/next is forcing out of laziness. No
one is stopping you from using rest and empty?, nor your friend from using
next and conditionals. Peace!
Rich
On Oct 21, 2011, at 4:25 PM, daly wrote:
On Fri, 2011-10-21 at 15:41 -0400, David Nolen wrote:
Just because we have dynamic types does not give us the freedom to not
consider them.
If all of these dynamics types and all of the tests respected nil
in its many meanings then
(when s ...,
(when (seq s)...,
(when (empty? s)...,
would not be an issue. (when s...) would just work.
Clearly express a consideration about the types at play.
Clojure was supposed to transparently substitute things like sequences
and vectors everywhere that lisp used lists. That would be true if nil
was respected but is not true now and this complicates the code without
apparent benefit, in my opinion.
In lisp you can ask what the type is (e.g. by calling consp, vectorp,
etc) but these type-specific predicates are relatively rarely used.
In fact, when they are used then you are struggling with data-level
issue that could probably be abstracted away (e.g. a code smell).
Clojure is a great language but the nil handling is, in my opinion,
a design flaw. It forces the introduction of (empty?...) and an
awareness of the data types into view unnecessarily.
Tim Daly
Literate Software
--
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
--
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
Re: Rich Hickey: Simple Made Easy from Strange Loop 2011
In the Simple-Made-Easy talk Rich raises the question of long term use. In particular, he mentions the issue of maintenance and change. In order to change software you need to understand the program. Unfortunately most people equate understanding the program as being equivalent to what the function does. What it also has to mean is why the function does it. In order to write a program that lives, that is, one that can be maintained and changed you need to capture why the code exists and why it is written that way. The best solution I have found is called Literate Programming. The LP idea is that you write the program for the programmer rather than the machine. You should be able to sit and read a book that explains the program, including the why. The real code is in the document but the text explaining the program is the focus. I would encourage you to look at Lisp in Small Pieces. It is a literate program, a book, that contains a complete lisp system with the interpreter and compiler but it is written to be read. Tim Daly The hardest part of literate programming is the documentation On Thu, 2011-10-20 at 09:01 -0700, Alex Miller wrote: The video is up: http://www.infoq.com/presentations/Simple-Made-Easy Places to watch for comments (or vote if you like): - http://news.ycombinator.com/item?id=3135185 - http://www.reddit.com/r/programming/comments/lirke/simple_made_easy_by_rich_hickey_video/ - http://www.dzone.com/links/simple_made_easy_by_rich_hickey.html -- 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
Re: android / mobile help
I have the android build cycle down to a single command that creates an installable apk file. If I do this on a machine with a web server I can put the apk file into a directory with a web page link. So all that would be needed is a form that has a build button on it and downloads the updated link. I also have a keyboard/mouse (I'm using an Asus tablet) so I can edit the files. The only missing link is a good ssh/x11 app that will let me do the emacs editing. Tim Daly On Fri, 2011-09-16 at 13:36 -0400, David Nolen wrote: On Fri, Sep 16, 2011 at 1:24 PM, Raoul Duke rao...@gmail.com wrote: hi, i dream of having a remote repl onto e.g. android so that i can try to reduce the write-push-run-test-debug-repeat cycle time. pretty please, does anybody have insights / experience / git hub forks / ideas about this? getting to a point where i can do code updates more easily, in fragments, would be so much better than the current molasses android developer situation, i gotta hopoe... many thanks. Have you considered using ClojureScript instead? David -- 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 -- 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
jsfiddle development app
http://jsfiddle.net/g105b/Z4TFh/ It would be interesting to develop Clojure code this way 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
Re: Swarming experiment at Conj?
On Thu, 2011-09-08 at 23:36 +0200, Brian Marick wrote: TL;DR: I have an idea for an after-hours coding experiment at the Conj. Interested? I'm at ALE2011 in Berlin. Jason Ayers gave an interesting presentation. He works for Cincom, a maker of Smalltalk. They wondered what would happen if 8 people programmed together on the same problem (instead of one or two). They set up an experiment in which 8 people on 8 computers could each have their own interface to the same Smalltalk image. (That meant that any change Person X made to a method in the system would be instantly available to everyone else once the compiler accepted it. It'd also be picked up by the continuous testing system.) They gave the team a problem to solve and a set of steps to work through (patterned after the way wolf packs hunt and kill prey). Actually, I'd pattern it after Hickey's ants demo. Each ant (aka developer) that leaves the nest creates a git branch. They can wander (aka hack) on the branch. Returning to the nest causes a merge. Hickey's overall ant control scheme could be used as-is to coordinate 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
Re: Clojure for Android
I have written several android apps so I can help with some questions. Unfortunately I am completely swamped otherwise. If you make it a project on Github that would be useful. Tim Daly On Tue, 2011-08-16 at 22:33 -0700, Paul deGrandis wrote: I'd consider taking this. I've worked a little bit behind the scenes to get Clojure to run better for me personally on android. Recently, I've been working to get ClojureScript to work well for SL4A (Scripting Layer for Android). I wanted to try to get a native Clojure package working for SL4A, but given that the above works pretty well, I need some sort of real motivation to continue the work. Paul // OhPauleez http://www.pauldee.org/blog On Aug 16, 7:31 am, James Swift ja...@3dengineer.com wrote: http://dev.clojure.org/display/design/Android+Support Issues Needs a motivated owner This topic gets a regular mention but I thought it might be worth asking again if it's ever likely to get the 'motivated owner' ? Given that 'reach' was a primary reason for the development of ClojureScript shouldn't the reach of Android encourage someone to go for it? I only wish I was capable of doing it myself :) James. -- 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
Re: Stanford AI Class
Ng's course on machine learning is online. I've already taken it. You need a background in probability. Tim Daly On Tue, 2011-08-16 at 08:52 -0700, ax2groin wrote: The NYTimes article on the class also mentions two other classes being offered for free: * Machine Learning, by Andrew Ng * Introductory course on database software, by Jennifer Widom I'm not sure of the official website for either of these, but the Machine Learning class sounds promising and didn't have a required textbook the way the AI class does. -- 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
