limist's comments

Back in the late 2000's I looked around for the right tool for my Ph.D. dissertation and quickly ruled out Word, Libre (or Open Office) Writer, or any wysiwyg tool, because they 1) lacked fast, easy ways to work at the structural (tree) level of the document, which is important when you have many sections and subsections to organize thoughts and arguments; 2) couldn't do mathematical notation well; 3) didn't integrate well with the reference management tool I was using then, Mendeley.

As an Emacs lover, I soon found Org, and it was (and remains) the perfect tool, for working in plain text — which will never be obsolete, and works easily with git or version control. Then and now, nothing could match Org speed and flexibility: structural editing (creating nodes, moving nodes, promote/out-dent a node, demote/in-dent a node) was and is fundamental to Org (unlike Markdown etc), and it's ridiculously easy to reorganize thinking and writing as you go. You can export to LaTeX (or HTML) and customize formatting as needed, while also including code blocks from multiple languages. Integration with BibTeX was tight, and made handling hundreds of references easy.

Where other writing tools for complex documents previously made me cringe and cuss, Org makes writing a pure joy, freeing the mind to work entirely on content and its structure.

James Randi has been caught outright lying and is not to be relied on:

https://www.telegraph.co.uk/culture/film/film-news/11270453/...

http://zthoughtcriminal.blogspot.com/2013/04/randis-involvem...

Character (integrity, drive to learn & improve) and skills that you respect or admire. Then shared values and life situation: the startup should be the #1 priority for everyone on the core (full-time) founding team. Missing any of those requirements increases the risk of failure.

Unfortunately for those without a wide/deep network of college friends, former colleagues, etc. it's hard to judge character and skills without a previous friendship or shared work environment, etc. If you're forced to evaluate a potential co-founder in the absence of shared history, work on something small together for a few days/weeks and see how it goes.

Another thing to do in all cases is to discuss downside/failure scenarios right up-front, and see if there's a sense of openness and fairness. Check out the books The Founder's Dilemmas and Slicing Pie for structuring the conversations, as they give vital ideas and precedents around formalizing the founders' relationships. It's much easier to chat about failure and equity before real work starts, and I've seen many times that it flushes out assumptions and behaviors that you won't want on your team (assuming you're the reasonable and fair one :-).

Shameless plug: more examples of literate Clojure in Emacs here, https://github.com/limist/literate-programming-examples

It's not bad - I read this book a while ago to boost my Python-fu. But it left me feeling like most software/language books - unsatisfied, i.e. here are the pieces (syntax), here are a few (boring, trivial) ways to put the pieces together, etc. To give a really strong CS foundation, SICP still rules. :)

Short answer: There's a mix of people, and a few are students (college or graduate school). Some are remote coders. Some are doing startups. And some quit their jobs to come to Berlin. :)

Depends which page you're referring to.

The article/link above makes the price clear, and also why we charge - we keep things simple and don't do the recruiting model.

The homepage doesn't mention price nor mentors; we wanted to keep it short. We'll likely add the price there.

Both the price and prior mentors (some are very likely to return) are clear on the offer landing page: http://hackerretreat.com/batch-next/ The exact lineup of mentors is TBD because we want to be sure to bring in people that participants want/need. You can judge from our past mentors, and our posts, what the caliber of mentors generally is.

Thanks for the compliment. We certainly enjoy socializing, but effective learning and working take precedence, and we expect an atmosphere of "enthusiastic intensity" at HRet.

The people at MSV have been cool with us. And while they certainly want to have visibility for their program, they've given us all the freedom we need in using their space.

Yep, they target a different audience. They're more for beginners who want an apprenticeship in coding. Whereas Hacker Retreat is for intermediate and advanced coders who have their own projects, and want to learn and apply advanced techniques.

No. There's no product showroom there, just a cafe on the ground floor. Hacker Retreat is happening in the space above, where MSV's incubated startups usually are. They agreed to let us use the space in between their startup rounds.

Thanks! We think at least a few people from our last Fall batch would agree to that. We're intending more people to say that when this next session/batch is done.

Yup, we know...boy do we know. :) Rationally, and per our FAQ, we considered ditching it because the economics are marginal or worse. But neither Jose nor I could let the idea die. We hope the latest version hits the right combination of OK economics, and strong benefits for everyone involved.

Thanks! Short answer is, it depends. If we get really strong interest and commitment (like 20 people who will definitely be there), we'll do another batch in the Fall/Winter. Someway or somehow, space will be conjured up again and we'll make it happen. :)

One idea your question brought to mind is a form/list of people who really want to come and do it, just at a later date. Will set that up...

I'd have to disagree - the math is important, and lays a foundation for functional/declarative programming. One major lesson of Chapter 1 (where the math is most evident) is conceptually tying math (and its notations) with functional, declarative programming. Math still shows up in Chapters 2 (e.g. generic operations, polar vs. rectangular coordinate system math) and 3 (streams). It can't be skipped over without missing a lot of lessons.

Much better to have a REPL handy - like order-of-magnitude better. :) The further in the book you go, the more you need to write, run, tinker and test to check your understanding(s).

Yep, it would be fun to do that for code - we're thinking of different models and timings for Hacker Retreat. Consider sub'ing to our email list to stay in touch, thanks.

As a coding-vacation? Or as something that blends well with remote work?

We've adjusted the format of the current Hacker Retreat to accommodate people working (remotely, on their startup, etc) - 20% of your time is committed to learning, the rest of the time is up to you. The time-span is over 2 months minimum. We're currently taking applications for the Batch-02 starting in May/June.

Super-compressed, 1-2 week retreats are something we've thought about, especially for advanced topics like data science and functional programming...may do it later, but not this summer.

Good question - when I got to that part, I couldn't get the picture language to run either and just wrote code that I compared with other online solutions. I just took a look at the MIT Press website for their SICP code: http://mitpress.mit.edu/sicp/code/index.html

...but don't see the code needed there to draw graphics. Eli's online solution did, I believe, manage to get graphics working with a non-MIT-Scheme Scheme. But it's not necessary to have running code here to get the benefits of the exercises (unlike later in Chapter 3 and 4!).

I'd be curious to know the answer to this as well - I have not come across anything comparable w/ Haskell and the like, yet.

Cool idea, will be curious to see how it goes (don't own iStuff so can't directly participate).

Live remote video-learning, I've found, tends to require a good friend of comparable skill level to work. If you discover that strangers can make this work sustainably, that's definitely interesting and important.