This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (22)
- # beginners (28)
- # boot (8)
- # cider (9)
- # cljs-dev (1)
- # cljs-site (3)
- # cljsjs (6)
- # cljsrn (6)
- # clojure (20)
- # clojure-germany (3)
- # clojure-russia (16)
- # clojure-uk (6)
- # clojurescript (106)
- # datascript (9)
- # datomic (19)
- # devcards (4)
- # dirac (42)
- # docker (4)
- # emacs (3)
- # hoplon (89)
- # jobs-rus (1)
- # keechma (6)
- # lein-figwheel (1)
- # leiningen (1)
- # luminus (11)
- # off-topic (1)
- # om (1)
- # om-next (1)
- # onyx (19)
- # other-languages (37)
- # parinfer (1)
- # proton (1)
- # reagent (9)
- # rethinkdb (17)
- # rum (2)
> And doesn't literate programming suffer from the same problem as other documentation, that it isn't checked and therefore is incorrect a lot of the time? @borkdude Currently re-watching Tim Daly’s presentation “Literate Programming in the Large,” on his over 1M LoC Common Lisp codebase, which he views as over 1M LoC literate LaTeX : https://youtu.be/Av0PQDVTP4A?t=20m30s Basically claims you need someone enforcing the paradigm of writing a book, willing to reject people’s pull requests. (At 20:30 mins the video.)
In 'Coders at work' it appeared to me that Seibel asked every programmer: do you ever use literate programming?
But a lot just said: no, not really. Maybe at the time of writing the book it was something Seibel considered himself a lot (he has also written a book on Common Lisp).
But yes, it would make a lot of sense to do it that way, it preserves all the information you would ever need about the code. But it also requires a lot more effort, so you have to estimate the lifespan of that software and see if it's worth it.
Thanks! Re-reading those parts of Coders at Work now; I totally forgot that Seibel frequently asked about it.
One part of Seibel's interest may be that he majored in English and did some work in journalism http://www.gigamonkeys.com/resume/
I suspect the idea of literate programming should maybe be updated for modern tech (video's more feasible, etc).
@tjg: Daly says the goal of your company is to write a book (not just some code). Are you saying the goal should be to make a movie?
Yeah definitely, though I think the problem with text is, part of today’s programming is visiting websites.
(For example: “Visit this webpage for auth; click this, that & the other thing...” Those webpages change, which a video can make apparent.)
Also, it’s good when a programmer walks me through the code and it fails on my machine, so when you’re watching the video, you see us googling & troubleshooting with some annoyance.
yes, video could capture things that you don't see in text, like: "well, we just guestimated the amount of memory needed here, change it if it doesn't work" kind of vibes 😉
I quickly checked yesterday & didn't see anything.. complicated because an actor shares the name.
Thought: "do you want to treat your program as a living organism or like a text that is subject to mathematical analysis (with all the distractions of the mathematical analyser)?"
Interesting! Maybe at first a living organism; then play the analyzer and attack my past self’s work. (Eventually hardening the code with layers of constraint like type annotations?)
> “Bugs” have what he called a “virtuous” character. > > Describing the basis for his theory of “problem solving by debugging almost-right plans,” Sussman asked, “How much time has each of us spent tracking down some bug in a computer program, and electronic device, or a mathematical proof? At times it may seem that a bug is at best a nuisance, or at worst a disaster. Has it ever occurred to you that bugs are manifestations of powerful strategies of creative thinking? That, perhaps, creating and removing bugs are necessary steps in the normal process of solving a problem? Recent research at the MIT AI Laboratory indicates that his is precisely the case.” -- Peterson, “Newton's Clock: Chaos In The Solar System”
I'm at a coffee bar and had this humorous thought: type driven development is like writing all the names on the coffee cups at Starbucks before all the customers come
writing something with
foldl is still easier for me in Clojure than in Haskell, despite the errors and type messages
*Main Data.String Data.List> let reduced = foldl (\(acc,name) -> acc + length name) 0 filtered <interactive>:52:43: Couldn't match expected type ‘[Char] -> (t, [a])’ with actual type ‘Int’ Relevant bindings include name :: [a] (bound at <interactive>:52:28) acc :: t (bound at <interactive>:52:24) reduced :: (t, [a]) (bound at <interactive>:52:5) Possible cause: ‘length’ is applied to too many arguments In the second argument of ‘(+)’, namely ‘length name’ In the expression: acc + length name
I tend to get overwhelmed with this kind of output instead of helped by seeing an example fail horribly