[JOB] Rewe Digital in Cologne, Germany (English-speaking team)

[Tj Gabbour]

Hi!

Rewe Digital has a couple Clojure jobs in Cologne, Germany. To add to their 
5-person English speaking team. Afterwards, they plan to grow a second 
Clojure team.

Rewe is a major German supermarket & tourism chain. About three years ago, 
they formed an "internal startup." Currently it has ~100 devs total, across 
JVM languages. (Including, I believe, Kotlin.) Managers confirmed to me 
that the Clojure team is considered highly effective.

Feel free to ask me any questions, or email Emil Yessenamanov 
. (I'm not compensated by Rewe; just want to help spread 
Clojure. Remote work is currently unavailable. Happy to answer any 
questions, including regarding critiques, compensation, etc.)


All the best,
  Tj

-- 
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: Origin for Clojure using the term 'vector' instead of 'array'?

[Tj Gabbour]

Yep:

https://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html
https://docs.oracle.com/javase/7/docs/api/java/util/Vector.html

“The Vector class implements a growable array of objects. Like an array, it 
contains components that can be accessed using an integer index. However, 
the size of a Vector can grow or shrink as needed to accommodate adding and 
removing items after the Vector has been created.”



On Saturday, October 3, 2015 at 9:32:13 AM UTC+2, Gary Verhaegen wrote:
>
> For people with a C/Java-style background, array typically designates a 
> contiguous piece of memory that has been allocated at once, is thus 
> fixed-size, and can be accessed randomly (i.e. by index). Vectors are 
> typically structures or objects at a higher level, that still present a 
> random-access collection, but can also for example change size.
>
> With that Background, Clojure's choice makes perfect sense. Please also 
> consider that Clojure does not use vector instead of array, but in addition 
> to; see make-array, geta, seta, et al.
>
> On Saturday, 3 October 2015, Mars0i  
> wrote:
>
>> I have no idea about the official reason, but outside of certain 
>> programming languages that use "array" for one-dimensional data structures, 
>> an array often has two (or more) dimensions.  In R, for example, arrays can 
>> have an arbitrary number of dimensions.  Honestly, when I'm away from Java 
>> for a while and then encounter the term "array" in Java, I have to stop and 
>> remember that it's 1-D, or check some documentation, because "array" 
>> doesn't automatically mean 1-D to me.
>>
>> On the other hand, I believe that vectors are always one-dimensional, as 
>> in linear algebra.
>>
>> So maybe Rich Hickey just decided that "vector" was a better, less 
>> ambiguous name.
>>
>> -- 
>> 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.
>>
>

-- 
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: [ANN] LispCast Single Page Applications with ClojureScript and Om

[Tj Gabbour]

 

I asked to purchase it last Tuesday to coincide with my rare vacation, and 
Eric happily obliged. Everyone’s different so YMMV; but using Kathy 
Sierra’s terms  I feel 
more of a “badass,” having gained a couple “superpowers”: 

   - able to participate in conversations about Om/React.js 


   - got over the initial hump of making (and understanding without nagging 
   confusion) an eloquent single-page app 


Educational techniques I’d like to steal when writing docs and mentoring: 

   - Be upfront about gotchas, so learners aren’t stuck for hours 
   experimenting/googling for the right incantation. (Many stay “backend 
   programmers” because of all the mindless incidental complexity that web 
   programming entailed. This isn’t necessarily a commitment to ignorance; 
   could be a decision to learn other fulfilling things in their limited 
   lives.) 


   - When asking the learner to code, make it incremental so they can focus 
   on one idea at a time. (One chunk in an expert’s mind can be 2, 10 or 1000 
   chunks in a learner’s.) Yet make it safe to go on a limb when inspiration 
   strikes. (This course is very careful to let you easily revert to a Known 
   Safe State at each step.) 


   - A high road to gamification is when the learner helps someone, even if 
   just fictionally. (The low road appeals to base urges of accumulating 
   points; which maybe reflects a fantasy that their work has the same effect 
   on their bank account.) After all, many programmers are insulated from 
   users by Scrum Masters, Product Owners, Sales… not to mention those 
   programmers who secretly feel their jobs are unnecessary 
   . For many, helping even an 
   obviously fictional person is still a step up. 


   - Slightly offtopic, but his free lesson on eval 
    is 
   by far the best, most demystifying presentation I’ve personally seen. Found 
   it more fun than watching Sussman implement it at the blackboard 
   
.
 
   (And Sussman is a tough act to beat.) 



On Friday, September 18, 2015 at 12:15:08 AM UTC+2, Eric Normand wrote:
>
> Hello, Clojurists!
>
> I've been working hard on my new course *LispCast Single Page 
> Applications with ClojureScript and Om 
> .* It's an 
> interactive course teaching the basics of building an application from the 
> ground up. It's finished and it goes on sale on Monday, September 21. If 
> you get on the mailing list 
> , I'll 
> let you know when the sale starts and *you'll get a discount code*. It 
> will be $64 dollars and the sale will be 10% off. That's $57.60. The sale 
> will last 48 hours.
>
> LispCast courses combine animations, screencasts, exercises, code, and 
> more into a complete teaching package. I'm really happy to add *Single 
> Page Applications* to the lineup. I've been incredibly proud of the 
> progress ClojureScript has made to its development experience. Less than a 
> year ago, the Clojure survey 
>  showed that 63% of 
> people thought it was hard to bring up a REPL and 42% thought debugging was 
> too hard. There hasn't been a survey since that one, but with all of the 
> work to get to a 1.7 release (including official REPLs on different 
> platforms), it's looking so much better. I started the course back in June 
> and things have stabilized a lot even since then. Thanks to everyone who 
> worked on it.
>
> If you've been waiting to learn ClojureScript, things are really quite 
> comfortable now. If you want to learn ClojureScript, please check out 
> *LispCast 
> Single Page Applications with ClojureScript and Om 
> .*
>
> Rock on!
> Eric
>

-- 
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.

Hiring? Collecting job/hiring descriptions for this weekend’s ClojureBridge

[Tj Gabbour]

Hi! 


 This weekend we’ll host a ClojureBridge workshop in Solingen (Cologne/Bonn 
region of Germany). 


If you’re interested in potentially hiring participants, please feel free 
to send the relevant info to me. I’ll happily print and offer your 
description to those who express interest! 

   - If you wish, I can have a graphic designer typeset your description 
   elegantly before printing. 


   - English and/or German is fine. (Our workshop announcement 
   http://www.clojurebridge.org/events/2015-06-12-solingen-germany was in 
   English.) 


   - If you have a Code of Conduct (like my team 
   https://gist.github.com/tjg/554a81d6975262ed0ea0), or sponsor events 
   like ClojureBridge, please tell me and I’ll emphasize your commitment to 
   diversity! 


Feel free to email me off-list and I’ll happily answer any questions you 
have. 


Thanks!

  Tj 

-- 
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: [ANN] Time-Bombed Open License - thoughts?

[Tj Gabbour]

For those confused like I was, the correct link is https://coopsource.org

(FWIW, I found your entire wall of text very interesting, as it was 
sensible and contains points almost never mentioned. Could've read a longer 
version.)


On Sunday, June 7, 2015 at 6:09:25 PM UTC+2, Alan Moore wrote:

 Agreed. Code is almost beside the point in my mind. I'm not so much 
 promoting a license as promoting a way of doing business, an alternative to 
 the VC funded startup or too short lived/pivoting businesses that leave 
 customers in the lurch. Fairness, resiliency and other factors of a 
 business are far more important than code. The license is just a way of 
 maintaining agency in the work product, a means to an end, not the goal 
 itself.

 I didn't mention many aspects of the effort being undertaken - I cut out 
 whole sections of my email as it was already too long. Yes, we intend to 
 provide many valuable services and artifacts beyond just code. Extensive 
 documentation, support, consulting services, third party integrations and 
 many other things that make software worth buying.

 We also intend to target non-utility, non-platform markets/domains where 
 few OSS projects care to go. In this way we do not so much compete with OSS 
 but compliment it instead. If we can organize ourselves to efficiently 
 target many such markets then we stand a chance of being the only or most 
 reliable competitor.

 Also, there are advantages to being a cooperative that I won't go into but 
 I will say that we will be re-thinking many basic assumptions in software 
 engineering practices because we feel there are efficiencies to be gained 
 that would otherwise be impossible in more traditional organizations or 
 even with OSS.

 Again, my apologies for the verbosity. I could literally write a book on 
 this subject. I do not expect many on this list to like this approach, most 
 of you are not our target developer audience but there may be one or two 
 who see the value proposition and might be curious.

 I suggest any further discussion related to my comments be taken off-list. 
 This is after all the Clojure list :-)

 See www.coopsource.com for contact details, including a link to our 
 dedicated mailing list. Our Twitter handle is @coopsource.

 Take care.

 Alan
 -- 
 *Whatever you can do, or dream you can do, begin it. Boldness has genius, 
 power, and magic in it. Begin it now.* - *Goethe*

 On Jun 7, 2015, at 6:10 AM, Daniel Kersten dker...@gmail.com 
 javascript: wrote:

 One thing worth pointing out is that OSS needn't be free as in beer.

 I've paid for OSS SaaS products because I don't want to host and admin 
 them myself, for example.

 If your service provides something above and beyond what the source 
 provides (and the OSS freedom), then you *may* still have a business. Maybe.

 On Sun, 7 Jun 2015 10:42 Alan Moore kahun...@coopsource.org javascript: 
 wrote:

 Fergal,

 *Warning* - Wall of text ahead! If you think OSS works perfectly fine the 
 way it is today feel free to press delete now...

 I've been holding back commenting on this thread to see where it would 
 go. It is nice to see everyone's take on the need for (or not) a solution 
 to the lack of an OSS business model. From what I can tell, there really 
 isn't a business model in OSS at all. Almost by definition, the market 
 for OSS is a failed market. What other industry/market exists where the 
 price of goods is $0?

 Freedom issues aside, when you give away the fruits of your hard labor 
 you are doing just that, giving it away and that in no way constitutes a 
 sale. The Free Rider problem is alive and well, that is just human nature. 
 I would love to live in a world where this isn't true and I actively work 
 towards a future when we can all just work on whatever scratches our itch, 
 but so far we are not there yet.

 Of course, ancillary to the lack of a price/valuation for the code 
 itself, companies still make money by various other means given the 
 environment created by the OSS they give away. I doubt that Clojure or any 
 other OSS project has ever made any significant cash flow just giving away 
 code. Conferences, books, consulting services, freemium, value added Closed 
 Source/Dual License products and all the rest make up the difference 
 (hopefully!) Sometimes just the marketing visibility generated by giving 
 away code is enough to cover the costs of producing it. In that way, OSS 
 can be accounted for as a marketing give away from which other revenue 
 and goodwill will flow. This is obvious stuff we all know.

 To be perfectly honest, I am not a fan of the GPL or any other viral 
 license. I do not believe code needs to be free. Code is code, an 
 inanimate artifact of human labor. Everyone is free to give theirs away - I 
 think this is admirable and altruistic behavior that we need more of. I'm 
 very grateful that Rich and all the rest of the Clojure developers, 
 contributors, library authors, etc. are giving 

Re: ANN: Hildebrand 0.2.2

[Tj Gabbour]

Slightly OT, but wow, slowly reading your blogpost because it's terribly 
pleasant to read! :) Like, a high amusement-to-clause ratio.

(I think this should influence my own tech writing.)


On Tuesday, June 2, 2015 at 2:20:59 AM UTC+2, Moe Aboulkheir wrote:

 First time caller.

 Hildebrand is an asynchronous pure-Clojure (i.e. no Java AWS dependencies, 
 etc.) DynamoDB client written on top of httpkit.  I've been developing it 
 for a while now, and have used it in production, but hadn't gotten around 
 to telling anyone about it. 

 http://github.com/nervous-systems/hildebrand

 I wrote a circuitous blog post about it: 
 https://nervous.io/clojure/aws/dynamo/hildebrand/2015/06/08/hildebrand/ 
 (apparently in the future), which is more informative.

  As this is the first public release, I'll just rattle off some high 
 points:

  - Intuitive, consistent and total data representation of Dynamo schemas, 
 items, filters, update specifications, etc.
  - Support for arbitrarily nested lists and maps in Dynamo items, has 
 support for set types
  - Paginated/stepped query  scan with core.async channels
  - It could possibly perform decently

 Take care,
 Moe



-- 
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: Education on Dynamic Binding

[Tj Gabbour]

I wonder whether it's been dropped because of threads. (If I understand 
correctly, you have to remember to tell the thread to inherit dynamic 
bindings. Which may be difficult if you have a framework creating threads 
as an implementation detail...)

On Wednesday, May 27, 2015 at 4:01:29 AM UTC+2, andy.c...@fundingcircle.com 
wrote:

 This page on Jira says that dynamic binding should be documented as The 
 Clojure Way to do error handling. Was this ever done? I managed to find a 
 few blog posts discussing approach but nothing official.

 http://dev.clojure.org/display/design/Error+Handling

 Cheers,
 Andy


-- 
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: Clojure needs a web framework with more momentum

[Tj Gabbour]

 

First of all, I apologize to the group for any unfriendliness in my 
response. (Which may be poisonous to this group’s culture, I don’t know. 
Unfortunately, many old frustrations of mine were triggered, when I felt my 
question was given an uncharitable interpretation.) 

The term “pull request” hides a lot of complexity. (Some point out 
https://modelviewculture.com/pieces/what-your-open-source-culture-really-says-part-one
 
it means “Go fuck yourself.”) Nothing is merely a pull request; it is 
someone's valuable time spent in contemplation and action. 

 If we were in a team, here’s some things we might discuss: 

   - How to support each other? (Given varying 
   skills/confidence/energy/power.) 
   - What is our ultimate goal? (“Documentation” almost never is one. It’s 
   just a tactic.) 
   - What is our audience? (Why do we wish to serve them, and how?) 
   - What is our process for improving quality/effectiveness? (After-action 
   reviews, building institutional knowledge…) 
   - Who are external partners, and how do they think? (We’ve mentioned 
   Clojurewerkz and The Clojure.org 14.) 


 So when we’re evaluating contributing to clojure-docs.org: 

   - Should we add metrics to show us how many people read 
   clojure-docs.org, as a first step to gauging effectiveness? 
   - What do you think about the content there, and how would you make it 
   far better? (Pictures? Examples? Literary structure?) 


 When we’re evaluating contributing to clojure.org: 

   - Examples of our intended audience, and what problems do they have? 
   - How to best work with the strengths of The Clojure.org 14’s 
   conservativism? 
   - Clojure’s uses are diverse; how do we represent its core? Might it be 
   entirely appropriate to have a sparse site, more or less like it is now? 
   Because the real entry-points should be around emerging clusters like 
   React.js libs? 


 These may seem like lots of things to think about, but so is writing 100 
good lines of debugged code. 

*are any restrictions that should be put on a documentation site?*


Yes, depending on what you want to avoid. 

For example, I hear PHP suffered from misleading and messy community docs… 
though it was very useful for my (basic) purposes. 

But once we agree there need to be restrictions, what can we do to mitigate 
the downsides? For example, raising barriers to entry can lead to 
intimidation. But you can mitigate it by being supportive and offering 
mentoring. Or simply being proactively honest and apologetic about it. 

I hope I didn't misunderstand your points?

-- 
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: [ANN] Instaparse 1.4.0

[Tj Gabbour]

Great to hear!

This week I wasted half a day over some silly error which should've been 
caught quickly. Mistakenly believed the input suddenly turned complex, 
requiring a complicated grammar.

My personal postmortem discovered a bias — I thought, Cool, let's whip out 
Instaparse! Let's paint a happy little grammar tree... And so deluded 
myself away from simply investigating the problem. :)


On Wednesday, May 6, 2015 at 10:56:57 AM UTC+2, puzzler wrote:

 Instaparse 1.4.0 is now deployed to clojars and available to use in 
 leiningen projects by adding [instaparse 1.4.0] to your project file. 

 Instaparse is a convenient way to generate parsers from context-free 
 grammars.

 The new release features an improved algorithm for handling complex nested 
 negative lookaheads, and the ability to print out a trace of what your 
 parser is doing.

 Instaparse: https://github.com/engelberg/instaparse
 Description of new tracing feature: 
 https://github.com/Engelberg/instaparse/blob/master/docs/Tracing.md


-- 
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: Clojure needs a web framework with more momentum

[Tj Gabbour]

On Wednesday, May 6, 2015 at 11:12:58 PM UTC+2, Andy Fingerhut wrote:

 Maybe you are not aware of the history, but clojure-doc.org exists 
 specifically because someone who spoke out loudly and repeatedly against 
 CAs took the time to create it, and it _only_ requires a Github account and 
 creating a pull request.


 That response does not respect people’s limited time. Examples from my own 
brief experience: 

   - Had to run some Ruby server… the instructions of which are currently 
   in a dead link 
   
https://github.com/clojuredocs/guides/blob/master/cds/blob/master/README-tools.md.
 
   
   - Had to fix a problem https://github.com/clojuredocs/guides/issues/143 
   with that Ruby server’s markdown lib. 
   - Weekly+ releases were jarring when I was used to rapid release cycles. 

 You’re advocating a course of action whose predictable effect is to eat up 
unexpected hours of helpful people’s time. Probably triggering Impostor 
Syndrome in half of them because it’s supposed to be raly easy… 

People need to make rational decisions on time allocation. They should be 
cautioned that clojure-doc.org vs clojuredocs.org is a highly confusing 
situation, which will impact the effectiveness of their efforts. Docs are 
about empathy, which means discussions should show empathy. 

This whole discussion is such a headache… With all the attempted shaming 
for not contributing, when many of us spend massive amounts of time 
contributing, and are merely trying to assess pitfalls from the morass of 
half-truths… 
  

-- 
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: Clojure needs a web framework with more momentum

[Tj Gabbour]

On Wednesday, May 6, 2015 at 9:15:53 PM UTC+2, Andy Fingerhut wrote:

 I am not 'in the know' on decisions regarding clojure.org.

 [...]

What I find more interesting than the portion of Sean Corfield's post that 
 you chose to quote, was this one (emphasis added by me):


  

To clarify, because I detect an implication in your words: I never said the 
part I “*chose to quote*” was the most “*interesting*”. It was merely the 
one which I wished clarification on. (The answer affects a planned action 
of mine.) 

Good to hear Alex Miller spends much time on documentation. Others, like 
Kathy Sierra, not only do so, but under infinitely worse conditions. I 
respect them all. 

Personally, I allocate much time on technical docs too. I’m participating 
in Clojurebridge soon, not to mention the private mentoring where I write 
“class notes” most days a week. I’m behind on them; here’s my backlog of 
classes to illustrate: 

   - suddenly jumped from machine language http://www.catonmat.net/c/76625 
   to get high-level perspective: 
  - class where I explained data (used Clojure datastructures, as it’s 
  the clearest) 
  - class where I explained code (used a simple lisp, and basically 
  explained an evaluator) 
   - class on I/O: polling vs. interrupts vs. hybrid; memory mapped vs. 
   port mapped 
   - class introducing C: lldb, offered choice of texts 
   - class explaining “what’s a sourcecode file”: inodes 

(And the task requires skills like a certain kind of brevity; reaching down 
into underlying concepts; visual details like non-intimidating typefaces, 
etc.)

Admittedly, for the Clojure community, I only contributed this doc: 
http://clojure-doc.org/articles/cookbooks/strings.html … after which I 
decided to allocate my time to efforts which (hopefully) help people more 
than liberating programmers from technological drudgery. 

Anyway, I retract my tiny question; I’ll just privately ask people I know.

-- 
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: Clojure needs a web framework with more momentum

[Tj Gabbour]

On Wednesday, May 6, 2015 at 6:34:15 PM UTC+2, Sean Corfield wrote:

 The issue has been raised several times and is pretty much always shut 
 down by those in charge. It was a huge struggle just to have the Getting 
 Started page updated to remove complexity and point at the wiki instead 
 (although the wiki is also _horrible_ from the point of view of new users).


 Did they ever articulate reasons? (Even if vague/brief?)

-- 
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: A more flexible versio of - ?

[Tj Gabbour]

I really like: https://github.com/jdevuyst/fletching-macros

It's nice because you can use it with plain arrows... as little exceptions.


On Tuesday, May 5, 2015 at 4:09:55 AM UTC+2, Frank Siler wrote:


 On May 4, 2015, at 1546, Kaiyin Zhong kindl...@gmail.com javascript: 
 wrote: 

  Wouldn't be nice to have something like: 

 See also Swiss Arrows: 
 https://github.com/rplevy/swiss-arrows 

 Great article on “hard to Google” forms in Clojure: 

 https://yobriefca.se/blog/2014/05/19/the-weird-and-wonderful-characters-of-clojure/
  

 Frank`

-- 
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: anybody here who use emacs to edit closure? is emacs lisp a good starting point to learn closure?

[Tj Gabbour]

Hi!

This highly depends on what’s most effective for you. If I were your tutor 
[1], I’d hear “but i wanna to start from emacs and emacs lisp,” and take 
that as a strong indicator that this path (first exploring Emacs) might be 
effective for you. 

Useful to probe more deeply into two threads: your interest in Emacs and 
interest in Clojure. Why you find these interesting. (For example, do you 
find Emacs a pleasant, customizable environment to live in?) 

A couple lessons which seem transferable are: a) getting used to 
parens/brackets as delimiting code/data units, and b) getting used to an 
environment you can interactively change while it runs. 

But I really don’t know. I've only written small Emacs Lisp programs. 
(Unlike say Bozhidar, who also responded.)

All the best, 
   Tj 

 [1] I tutor someone in computing, so that’s a common frame of reference. 
(But it’s limited since I haven’t tutored many. Like a tailor who knows 
only a few body types.) 
 

On Saturday, April 4, 2015 at 4:00:03 AM UTC+2, mnz...@gmail.com wrote:

 i am about to use emas and start to learn emacs lisp, would the study of 
 emacs lisp help to learn clojure, both of them are lisp dialect, so would 
 it take a long time to swich from emacs lisp to clojure?
 i just want to learn clojure, but i wanna to start from emacs and emacs 
 lisp, is that an effective way to master lisp and the great editor emacs? 
 or it's better to start from clojure and some other ide directly?
 need some suggestions and advices:)


-- 
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: anybody here who use emacs to edit closure? is emacs lisp a good starting point to learn closure?

[Tj Gabbour]

Oh, and I'd try to figure out if this theory has any merit: do things like 
paredit and yasnippet help you intuitively think in terms of manipulating 
structure rather than text? Because in Clojure, you're constantly 
transforming and pushing around units of data.

On Saturday, April 4, 2015 at 11:45:10 AM UTC+2, Tj Gabbour wrote:

 Hi!

 This highly depends on what’s most effective for you. If I were your tutor 
 [1], I’d hear “but i wanna to start from emacs and emacs lisp,” and take 
 that as a strong indicator that this path (first exploring Emacs) might be 
 effective for you. 

 Useful to probe more deeply into two threads: your interest in Emacs and 
 interest in Clojure. Why you find these interesting. (For example, do you 
 find Emacs a pleasant, customizable environment to live in?) 

 A couple lessons which seem transferable are: a) getting used to 
 parens/brackets as delimiting code/data units, and b) getting used to an 
 environment you can interactively change while it runs. 

 But I really don’t know. I've only written small Emacs Lisp programs. 
 (Unlike say Bozhidar, who also responded.)

 All the best, 
Tj 

  [1] I tutor someone in computing, so that’s a common frame of reference. 
 (But it’s limited since I haven’t tutored many. Like a tailor who knows 
 only a few body types.) 
  

 On Saturday, April 4, 2015 at 4:00:03 AM UTC+2, mnz...@gmail.com wrote:

 i am about to use emas and start to learn emacs lisp, would the study of 
 emacs lisp help to learn clojure, both of them are lisp dialect, so would 
 it take a long time to swich from emacs lisp to clojure?
 i just want to learn clojure, but i wanna to start from emacs and emacs 
 lisp, is that an effective way to master lisp and the great editor emacs? 
 or it's better to start from clojure and some other ide directly?
 need some suggestions and advices:)



-- 
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: How to get a list of changes in Datomic

[Tj Gabbour]

Hi!

If I understand correctly... consider something like the following:

(let [log (d/log (db/conn))
  my-tx 123456789123456]
  (- (d/tx-range log my-tx (inc my-tx))
   seq
   pprint))

You get a bunch of datoms and transaction ID.

You can access a datom's fields with: :e :a :v :tx :added.

At first, the datoms look depressing because attributes look like 74 instead 
of :mouse/name. So use(d/ident db 74) to get :mouse/name. (You might like 
to make a little util which turns these datoms into a nice map or record. 
Records are nice because they seem to print fields in the :e :a :v :tx 
:added order you declare.)

FWIW, you may see two datoms where the entities are the same, but :added is 
different. That's because you changed something; the entity's old value was 
retracted and the new value was added.

Hope this helps,

 Tj



On Saturday, December 27, 2014 7:57:51 PM UTC+1, rogergl wrote:

 I would like to replay all changes since a specific timestamp.  It seems 
 as if I can get all transactions with 

 (q '[:find ?t :where 
  [_ :db/txInstant ?t]
  ] (db conn))

 Using as-of would allow me to replay the state at a given point in time. 
 But that would replay the complete state and not just the changes.

 Is it possbile to get just the changes for a specific transaction ?

 I tried 

   (q '[:find ?c ?n  :where 
  [?tx :db/txInstant g]
  [?c :db/txInstant ?n ?tx]] (db conn))

 to test if I can get back a result for a specific transaction. That did 
 not work although 
 http://dict.leo.org/ende/index_de.html#/search=althoughsearchLoc=0resultOrder=basicmultiwordShowSingle=on
  g 
 was a value from the first query.

 Regards
   Roger



-- 
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: Do you like the Clojure syntax?

[Tj Gabbour]

Hi,

Random thought from a very tired person. :)

Programmers manipulate tiny pieces of reality, so tiny that quantum effects 
come into play. [1]

Many of us (unknowingly) train our visual senses to help us calculate these 
strange manipulations with less strain. Maybe if we train it on too narrow 
a range of notations, it's harder to extend this training to slightly 
perturbed ones. [2]

Lisp + Paredit helps me train kinesthetic parts too. The effects are maybe 
too submerged for me to introspect [3], but Lisp is oddly close to things 
my hands manipulate in normal life. I commonly hold groups of things. Those 
things may be delimited by enclosing objects; between them may lie 
empty-looking space.

(Of course, in daily life I'm not causing things to suddenly blink out of 
existence or be enclosed. But my body seems to adjust to the concept fine.)

Lisp representation may just be symbolic, but manipulating it isn't only 
like text editing. It lends itself to structure editing. [4]

BTW, this post isn't about Lisp is better than language X. If someone like 
likes X better than Lisp, then cheers.


All the best,
  Tj


[1] 
http://physics.stackexchange.com/questions/11567/is-quantum-physics-used-in-manufacturing-cpus

[2] Given that Lisp syntax isn't merely aesthetic, but radically simplifies 
some things, it should often be worth the retraining.

BTW, programming languages are artificial sorts of languages. Humans have 
enormous difficulty with them compared to natural language; if anyone 
claims that C-like languages are easier for humans to compute than Lisp, 
ask for scientific studies. Or simply email Chomsky and ask him.

[3] It's likely good that we have limits to introspection, because 
otherwise we probably couldn't function as well. I suppose this is when 
people start using mystical terms like intuition.

[4] I vaguely hear manipulating Java under Eclipse may be more advanced 
than Paredit, due to greater engineering effort. But this shouldn't affect 
the analysis.


On Saturday, August 17, 2013 12:47:09 AM UTC+2, frye wrote:

 Oh thanks Steven. I've lately been thinking about human cognition, 
 intelligence, etc. So boning up on my Chomsky, Kurzweil, and so on. 

 Remember that the original lisp syntax only had a few core features: 
 homoiconicity, first-class functions, recursion, garbage collection, etc. 
 But from this core, the most advance language features have been easily 
 added. Indeed, we're seeing this in real time, in Clojure: immutable data, 
 lazy sequences, concurrent programming with STM, etc. Now, while 
 theoretically possible, I don't think it's really feasible to implement 
 many of these features in Cobol or Pascal - languages from the same era. 
 Even Java has made a very clumsy attempt at closures, etc. But these other 
 languages can't compete with the LISP approach, I think because of their 
 syntax design. 

 The human species still has an extremely limited understanding of how 
 consciousness (ie cognition) works. My suspicion though, is that aspect's 
 like the simplicity of lisp's syntax is what keeps it at the bleeding edge 
 of computer science and our notions of computation. As limited as that is. 


 Tim Washington 
 Interruptsoftware.ca / Bkeeping.com 



 On Fri, Aug 16, 2013 at 5:00 PM, Steven Degutis 
 sbde...@gmail.comjavascript:
  wrote:

 Great point Tim. When I first realized that most problems and solutions 
 are language-agnostic, I started downplaying the importance of syntax. But 
 now I think they're like apples and oranges. Sure, semantics and syntax 
 live together, but one's not more important than the other. They're both 
 important to get right, for different reasons.

 For instance, while function calls in Ruby are (typically) semantically 
 similar to in Clojure, destructuring arguments in Ruby is much more limited 
 than in Clojure, and in Clojure it's much more easily readable as well as 
 more powerful. This is only a syntax thing though, but it's a powerful 
 player in the feature-set.


 On Fri, Aug 16, 2013 at 12:27 PM, Timothy Washington 
 twas...@gmail.comjavascript:
  wrote:

 I think it's a mistake to discount the importance of syntax to a 
 language. Human beings, as a species is heavily symbolic. Think of ancient 
 cave paintings, to pictograms, to scripts. We use these symbols to 
 communicate with each other, our outside world, and our abstract thoughts. 
 Whether it's written / spoken language, or math or music notation, we need 
 these symbols - it's a human thing. Dolphins or monkeys, while very 
 intelligent, do not, by themselves, use these written symbols to 
 communicate with each other. 

 And I think it follows then, that the design of the syntax itself is 
 important. It's certainly true that abstract concepts (of computation in 
 this case) are the motive for using any given syntax. But the syntax 
 impacts and facilitates the kinds of ideas we can have, the ease with which 
 we can communicate them with each other, 

Re: October Barnstorming in Europe

[Tj Gabbour]

That is very exciting. Will talk with my usergroup. I'd personally really 
love a discussion on what we've been up to in promoting Clojure locally, 
and what your thoughts are.

For instance, I'm no longer enthusiastic about coming up with a talk (which 
goes in one ear and out the other), but rather trying increasingly gonzo 
things at (say) NoSQL user groups. Like announcing that the attendees need 
to avert some sudden crisis by investigating data... which just happens to 
be in my laptop's Datomic instance. Or explore how my dinky fruit stand 
illegally collects customer data and mines it with Cascalog, because I 
dream of one day triumphing over Walmart. If nothing else, people hopefully 
find it an amusing evening, because Clojure is fun.

(And it seems hard to really describe the experience of dynamism, with a 
static talk. Of course, we also do more conventional workshops.)


All the best,
  Tj

On Tuesday, July 30, 2013 10:59:14 PM UTC+2, stuart@gmail.com wrote:

 Michael Nygard [1] and Stu Halloway [2] will be in Europe for much of
 October.  We are speaking at a bunch of conferences [3], [4], [5], and
 [6] and hope to see some of you there.

 Since we are already on the road, we thought it would be a good
 opportunity to turn this into a barnstorming tour, working with teams
 who are looking for help with Clojure, ClojureScript, and/or Datomic.
 If you would like to have us work with your team, pricing is as
 follows:

 * Free for user group talks
 * $1500 for a 90 minute talk
 * $5000 for a day of training or consulting
 * $0 for travel expenses (we are already there!)

 Our prepared materials are summarized at [7] and [8], or feel free to 
 request
 specific topics.

 If you are interested in scheduling a meeting, please send an email to
 in...@thinkrelevance.com javascript:, subject line: October 
 Barnstorming.
 Includes in the body of the message the kind of event you are
 interested in, as well as possible dates and locations.

 Regards,
 Michael and Stu

 [1] http://thinkrelevance.com/team/members/stuart-halloway
 [2] http://thinkrelevance.com/team/members/michael-nygard
 [3] http://euroclojure.com/2013/
 [4] http://reaktordevday.fi/2013/
 [5] http://gotocon.com/berlin-2013/
 [6] http://gotocon.com/amsterdam-2013/upcomingevents/
 [7] https://github.com/stuarthalloway/presentations/wiki
 [8] https://github.com/mtnygard/presentations/wiki



-- 
-- 
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: [pre-ANN] test2, the last Clojure testing framework

[Tj Gabbour]

Interesting; these arguments sound oddly like those surrounding Common 
Lisp's loop macro. When reading Midje's docs, I got the weird impression 
Brian was aware of the history of non-lispy macros.

Taken straight from 
http://www.gigamonkeys.com/book/loop-for-black-belts.html :

(loop repeat 5 
  for x = 0 then y
  and y = 1 then (+ x y)
  collect y) == (1 1 2 3 5)


Note:

   - Keywords
   - Infix
   - Updating-machinery is textually close to declaration
   - Of course, the arrow to describe output, which motivates Midje.


I'm not sure how Midje obscures your debugging?

Personally, I have strong positive opinions of loop and Midje. I believe 
that I can show people Midje tests, and they're very clear. To the extent 
that lack of composition/flexibility becomes a problem, I can incur the 
cost of an occasional rewrite; or if I can foresee the complexity becoming 
a problem, I'll do something else more appropriate. My attraction towards 
Lisp lies in clarity; I can often spend a bit of virtuousness to gain this, 
and not notice the cost.

(Disclaimer: my Clojure use isn't nearly as complex as yours; I don't get 
to use it as much as I'd wish. So maybe I'm missing something.)


All the best,
  Tj

On Tuesday, June 11, 2013 2:27:03 AM UTC+2, tbc++ wrote:

  It might surprise you to know that there are actual human beings with 
 feelings who write the software you slam.

 You are right. And I apologize for my strong words. For the goals that 
 Midje strives for, it is an excellent library. 

 My reaction is more against the ideas behind Midje (from the docs): I 
 believe you should have the same reaction to test suites written like that: 
 a slavish adherence to Lisp style in tests incorrectly exalts purity over 
 user-friendliness. 

 I disagree strongly with this assertion. I wish to see my tests in the 
 same language as my code. Midje succeeds in reaching the goals that it sets 
 forth. I can write tests, top-to-bottom, left-to-right. But at the expense 
 of debugging power, and intuitiveness. 

 It may be harder to read:

 (is (= (foo 1) 42))

 But even a beginner programmer in Clojure can parse and understand it. 

 I think the ideals Midje enspouses may be more applicable in other 
 languages, and IMO they are not needed in Clojure. 

 These are all my own, highly biased, opinions. I congratulate you, Brian, 
 on a well written, mature, library. I simply question the premise. 

 Timothy


 On Mon, Jun 10, 2013 at 5:30 PM, Brian Marick 
 mar...@exampler.comjavascript:
  wrote:


 On Jun 10, 2013, at 9:20 AM, Timothy Baldridge 
 tbald...@gmail.comjavascript: 
 wrote:
  Midje on the other hand, is a massive pile of macros and DSLs that so 
 complicate your code that advanced tests are insanely hard to debug. ... 
 And I can't tell you how many dozens of hours I've lost trying to figure 
 out why Midje doesn't like my test results.

 It might surprise you to know that there are actual human beings with 
 feelings who write the software you slam.

 Before people spend dozens of hours being frustrated, I suggest they post 
 to the Midje mailing list. I try to be reasonably responsive, and I have a 
 good track record helping people with their problems.

 
 Latest book: /Functional Programming for the Object-Oriented Programmer/
 https://leanpub.com/fp-oo

 --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.comjavascript:
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com javascript:
 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+u...@googlegroups.com javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.





 -- 
 “One of the main causes of the fall of the Roman Empire was that–lacking 
 zero–they had no way to indicate successful termination of their C 
 programs.”
 (Robert Firth) 


-- 
-- 
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: keys maps ... gak

[Tj Gabbour]

Hi Ray,

Perhaps this?


user (let [desired-entity-names (set (map entity-names [:model :project]))]
(select #(desired-entity-names (:entity %))
query-parts))
#{{:entity Model,   :main-query select * from model where ...} 
  {:entity Project, :main-query select * from project where ...}}


All the best,
  Tj

On Friday, May 31, 2013 10:18:09 PM UTC+2, mond wrote:

 Sometimes its just so frustrating when you know you are close but just 
 cannot get that last little bit ... so I am appealing again for more newbie 
 support 

 I have a map for some names:

 user= (def entity-names {:project Project :model Model})

 Which I then reference in a set of maps:

 user= def query-parts #{{:entity (entity-names :project )
 :main-query select * from project where ... }
{:entity (entity-names :model )
 :main-query select * from model where ... }})

 This query-parts is actually a large set. It will form the basis of 
 execution and sometimes I want to execute a smaller set of the queries.

 So I want to be able to filter it based on a subset of the entity names, 
 for example just :model.

 user= (select #(= (:model entity-names) (:entity %)) query-parts)
 #{{:entity Model, :main-query Model Query}}

 So that works great.

 But I would like a list of entities (:model :project :foo :bar) that 
 represents a subset of the complete set of query parts.

 So I just (sic!) need some advice on how to run this select over a list of 
 entity names rather than just the one shown above.

 I'm ashamed to say that I have spent an hour on this already so this is my 
 white flag. I hope you can help.

 Thanks

 Ray



-- 
-- 
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: Good Clojure style?

[Tj Gabbour]

Really? You may of course be right; but double-checking [1], I see:
* it removed the couple of magic numbers, the original post's most
  substantive technical criticism

* it has a much larger and better docstring

I don't want to come across as zealot-y (who likes that?); it's just my 
opinion and could be wrong! Just seemed that the first example wouldn't 
pass tech review unscathed; but when I dug deeper into the context, I found 
the second and it seemed that would reasonably pass.


To Devil's Advocate myself, there are critiques I personally see:
* Maybe cells is better named living-cells, or documented as such?

* cells starts off being the subject... but each neighbor becomes
  the subject. There is a cleverness in this. Maybe a brief comment
  would be apropos.

* mapcat and frequencies are fairly uncommon to use


But to Devil's Advocate my Devil's Advocate, it's in a book which explains 
these things. So the impact of the cleverness or suboptimal naming is a bit 
diminished. Maybe the authors didn't want to belabor the point, due to the 
sharp edge between being explanatory and plodding. And I actually have used 
mapcat and even frequencies, in my tiny helper scripts before I started 
using Clojure for production.

YMMV!


All the best,
  Tj

[1] 
https://github.com/clojurebook/ClojureProgramming/blob/7521bcfb52cdf7e598bca3c4e7860d795a67992c/ch03-game-of-life/src/com/clojurebook/collections/life.clj#L122


On Monday, April 15, 2013 8:40:58 AM UTC+2, edw...@kenworthy.info wrote:

 I'm sorry but that's not true. The version over the page hasn't been 
 re-factored 'into a nicer version' it's been re-factored into a more 
 generic version to support, for example, hexagonal grids.

 On Saturday, 13 April 2013 23:12:59 UTC+1, Tj Gabbour wrote:

 Hi,

 The text explains the elegant aspects of it; and then in the next page, 
 they refactor it into a nicer version which was 40% docstring. [1]

 So this is like critiquing the readability of someone's first draft. :)


 All the best,
   Tj

 [1] 
 https://github.com/clojurebook/ClojureProgramming/blob/7521bcfb52cdf7e598bca3c4e7860d795a67992c/ch03-game-of-life/src/com/clojurebook/collections/life.clj#L122


 On Wednesday, April 10, 2013 7:27:58 PM UTC+2, edw...@kenworthy.infowrote:

 So, page 143 of Clojure Programming has an implementation of Conway's 
 Life:

   (defn step
   Yields the next state of the world
   [cells]
   (set (for [[loc n] (frequencies (mapcat neighbours cells))

 :when (or (= n 3) (and (= n 2) (cells loc)))]

 loc))) 

 The book claims this to be an elegant implementation'.

 Now it's been a long while since I wrote code to put food on the table - 
 but back then if I saw C or C++ code written like this I would describe it 
 as obfuscated - the sort of thing I would expect to see in the (now 
 defunct?) annual obfuscated C competition. It's concise and rather clever, 
 certainly, but hardly self-documenting: it's not very clear what it's doing 
 at all- with a couple of magic numbers thrown in for good measure. Rather 
 arcane in fact.

 Is it just me? Is this considered to be good Clojure code and I'm just 
 hopelessly out of touch and need to get with the programme?




  

-- 
-- 
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: Good Clojure style?

[Tj Gabbour]

BTW, in the case of frequencies, I did find it weird at first. But also 
suspiciously useful. I think the reason is... in Clojure, I really feel how 
I'm constantly moving things from datastructure to datastructure. (Duh, 
that's what I constantly do in any language...) So we can imagine that a 
useful operation is to map data to simple numbers somehow. What would that 
operation be? Perhaps it's frequencies, which simply associates each datum 
with its count.

It's like learning a vocabulary of words like partition, frequencies... 
These things have technical meanings which may not correspond with everyday 
meanings. (frequencies typically evokes something wave- or hardware-like. 
Or one of those boring math class things people suffered through? But when 
you look at the word, it's at least about how frequently something occurs.)

Of course, I use emacs, so after a few times pressing M-., which jumps to 
the docstring, it gets burned into my mind... Like suspicious jargon which 
becomes natural because you're constantly saying it.


All the best,
  Tj

BTW: I recall sitting in a mall waiting for someone, depressed/angry upon 
realizing that to get anything done (without ugly code), I'd probably 
have to understand partitioning of potentially infinite sequences, enough 
to use it naturally without mental effort... and for some reason my mind 
wasn't obliging. So I closed my eyes on the mall couch and half-dreamt of 
infinite sequences... imagining the infinite sequences implicit in most 
languages' for-loops, generally constrained before they have a chance to 
become their own logical consequences... and then imagined some visual 
metaphors for chunking down these fellows into partitions...

Yeah, it's a different point of view, and may require some dark mental 
process before it's like, Duh, just take some elements off that partition 
of infinite sequences... But I recall when I learned a for-loop to this 
extent; it was a far less pleasant experience. People forget their learning 
process, which seems to be a natural part of mastery. That's why few 
masters can articulate a path to mastery well enough to be good teachers... 
and why we expect things closely related to our masteries to be obvious 
faster.


On Monday, April 15, 2013 10:12:22 AM UTC+2, Tj Gabbour wrote:

 Really? You may of course be right; but double-checking [1], I see:


-- 
-- 
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: Good Clojure style?

[Tj Gabbour]

I've always been awful at finding my keys, and rarely remembered if 
yesterday's events were really three days ago. :) Being told to accomplish 
rote tasks is gloomy, and I have to figure out how to internally motivate 
myself. I've met many like me. Who knows the interpretation? Maybe a 
charitable one is that we live with our heads in the clouds.

(Why enjoy things like Clojure? Because puzzle-solving mostly-pointless 
incidental complexity is a glum way to spend time.)

Only when I become old, will this become anecdotal evidence for my whole 
age category. :) Sorry fellows, I'll poison the well for you!


On Saturday, April 13, 2013 3:31:53 PM UTC+2, Brian Marick wrote:
 TL;DR: Opinions about unproductive older programmers is ahead of the 
science. 

Yes, when testing the cognitive effects of aging, it may even be better to 
mentally replace tests with microbenchmarks, which are typically not 
used to explore deeper but make a naive point as-is. 

And age with ageism (drawing the parallel to gender and race, which 
offers a host of other interpretations of such microbenchmarks, like test 
scores going down if you're self-conscious that yours will be used to 
represent your entire classification, or the unfortunate phenomenon of 
internalized oppression).

Take the young man's game quote; many would not only find young 
questionable, but man's. Even if there were cognitive differences between 
the genders, where females outperform males on verbal ability, that did not 
keep Shakespeare and Gabriel García Márquez from being great authors. 
Perhaps the same goes for age; if there are indeed cognitive differences, 
those may be much slighter than commonly supposed.

All the best,
  Tj


PS: Sometimes when I mention my thoughts on these subjects, accidental 
controversy erupts and pollutes the conversation. So I will be conservative 
and bow out. Thanks for listening.

On Saturday, April 13, 2013 3:31:53 PM UTC+2, Brian Marick wrote:


 On Apr 12, 2013, at 1:18 PM, Softaddicts 
 lprefo...@softaddicts.cajavascript: 
 wrote: 

  The average career length of a programmer is 8 years in the US (2003 
 survey) and 
  the main reason invoked by those that left is their perceived lack of 
 productivity. 

 TL;DR: Opinions about unproductive older programmers is ahead of the 
 science. 

 -- 

 I gave - or was supposed to give - a keynote on Cheating Decline: How to 
 program well for a really long time. I actually only had two slides on the 
 topic because I concluded, after a fair amount of reading, that there's 
 really no solid evidence that there is a meaningful decline over a normal 
 working life. (Same goes for mathematicians, by the way, despite G. H. 
 Hardy calling math a young man's game.) 

 Various cognitive abilities do decline, including the ones you mentioned, 
 but the declines are small for younger old people. For example, the 
 Whitehall II longitudinal study of British civil servants would lead a 45 
 year old to expect a bit less than 4% decline in reasoning (timed tests 
 of pattern matching, induction, etc.) over the next decade. Somewhat less 
 than that for the memory category. Then the next decade would show about 
 5% decline. It's not until 65-70 that a decade shows as much as a 10% 
 decline. 

 From this, I do *not* conclude the unproductive older programmer is a 
 myth. The tests are simple, they disallow interactions between abilities 
 that might matter for more complex tasks, etc. As a pessimist, and someone 
 who thinks he has every neurological symptom he ever reads about, I'm 
 inclined to think there is meaningful decline - that's why I chose the 
 topic for my talk: to see if I could find something useful to me. 

 (The second of two slides was my conclusion that the evidence for anything 
 being able to slow down or reverse decline is too weak to suggest anything 
 other than what you should already be doing to be healthy in general. That 
 weakness applies to brain exercise web sites, unless your goal is to get 
 better at the narrow tasks they have you practice. The thing you want, far 
 transfer to complex tasks, hasn't been demonstrated.) 

 For those who want to fret over symptoms, here are some: 

 What gets better with age: 
 * vocabulary (though recall may be slower) 
 * narrative ability 

 What stays the same: 
 * sustained attention (vigilance over time) 
 * knowledge of facts 
 * knowledge of how to do something 

 (Some of) What gets worse: 
 * divided attention: ability to follow a TV program and a conversation at 
 the same time. 
 * task switching (including at fine granularity) 
 * episodic memory (Where did I park my car? Which tab has the test 
 file?) 
 * choice overload: older people are disproportionately hampered by having 
 too many choices. (As a result, they may fail to seek out relevant 
 information. Also: oldsters are more liable to defer making a choice.) 
 * the tying of facts to their context. (So, for example, long-known facts 
 may seem to be 

Tips for a Clojure workshop, for people who don't use emacs?

[Tj Gabbour]

Hello!

I am helping run a Clojure workshop for a company's employees. (We will use 
Quil to program Conway's Game of Life, in pairs or small teams. We'll first 
show people how to use a cheatsheet of Clojure forms, which they can cut  
paste and mold; and give them a repo with a basic framework for programming 
Game of Life.)

They will generally use: vim, Sumblime Text, TextMate.

I'm sure my concerns are a bit overblown, but I'd like to at least 
visualize myself helping participants have a tight edit-run-debug cycle, if 
they wish. Hopefully something nicer than pasting code into a terminal's 
REPL, and more interactive than constantly running from the commandline. 
Any tips?


Thank you!
 Tj


PS: I'll try out fireplace.vim and Sublime Text's REPL.

-- 
-- 
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: Tips for a Clojure workshop, for people who don't use emacs?

[Tj Gabbour]

Thank you, good points! I lacked the imagination to seriously consider 
load-file. :) I'll practice using it.

Definitely will buy Brian Marick's book. [1] Pleasantly surprised to look 
through clojure-doc.org; probably confused it earlier with clojuredocs.org. 
:)


All the best,
  Tj

[1] Coincidentally, this week I'll be discussing Midje — very positively — 
at the local Clojure meeting group. I'd suspected that Clojure's 
unit-testing story was less than top-notch, but I was wrong — Midje easily 
dealt with everything I threw at it.


On Saturday, April 13, 2013 3:25:56 PM UTC+2, Wolodja Wentland wrote:

 On Sat, Apr 13, 2013 at 04:46 -0700, Tj Gabbour wrote: 
  I am helping run a Clojure workshop for a company's employees. (We will 
 use 
  Quil to program Conway's Game of Life, in pairs or small teams. We'll 
 first 
  show people how to use a cheatsheet of Clojure forms, which they can cut 
  
  paste and mold; and give them a repo with a basic framework for 
 programming 
  Game of Life.) 
  
  They will generally use: vim, Sumblime Text, TextMate. 
  
  I'm sure my concerns are a bit overblown, but I'd like to at least 
 visualize 
  myself helping participants have a tight edit-run-debug cycle, if they 
 wish. 
  Hopefully something nicer than pasting code into a terminal's REPL, and 
 more 
  interactive than constantly running from the commandline. Any tips? 

 vim, at least, supports Clojure development quite nicely. Take a look at: 

 http://clojure-doc.org/articles/tutorials/vim_fireplace.html 

 to learn how to set it up. So you could prepare the environment for vim 
 (as 
 you already have done for Emacs) and make it easier for vim users to learn 
 the 
 actual language. I am not sure about Sublime Text or TextMate though, but 
 a 
 short query on google revealed at least: 

 http://wbond.net/sublime_packages/package_control and 
 https://github.com/wuub/SublimeREPL 

 The equivalent for TextMate seems to be no longer maintained, but you 
 might be 
 able to dig up something. 

 All that being said: I wouldn't necessarily focus too much on these 
 specific 
 tools (also /not/ Emacs), but simply show them how to load files in the 
 lein2 
 nrepl and take it from there. That way they can edit Clojure files with a 
 tool of their choice  and concentrate on learning the actual language 
 rather 
 than the tooling. It would still be nice if you installed the 
 respective syntax files for various editors beforehand so that syntax 
 highlighting and indentation works (maybe even paredit) as expected. 

 I can recommend Brian's jp-oo book [0] as a good example of this style of 
 teaching (and in general as well). 

 [0] https://leanpub.com/fp-oo 
 -- 
 Wolodja bab...@gmail.com javascript: 

 4096R/CAF14EFC 
 081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC 


-- 
-- 
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: Good Clojure style?

[Tj Gabbour]

Hi,

The text explains the elegant aspects of it; and then in the next page, 
they refactor it into a nicer version which was 40% docstring. [1]

So this is like critiquing the readability of someone's first draft. :)


All the best,
  Tj

[1] 
https://github.com/clojurebook/ClojureProgramming/blob/7521bcfb52cdf7e598bca3c4e7860d795a67992c/ch03-game-of-life/src/com/clojurebook/collections/life.clj#L122


On Wednesday, April 10, 2013 7:27:58 PM UTC+2, edw...@kenworthy.info wrote:

 So, page 143 of Clojure Programming has an implementation of Conway's Life:

   (defn step
   Yields the next state of the world
   [cells]
   (set (for [[loc n] (frequencies (mapcat neighbours cells))

 :when (or (= n 3) (and (= n 2) (cells loc)))]

 loc))) 

 The book claims this to be an elegant implementation'.

 Now it's been a long while since I wrote code to put food on the table - 
 but back then if I saw C or C++ code written like this I would describe it 
 as obfuscated - the sort of thing I would expect to see in the (now 
 defunct?) annual obfuscated C competition. It's concise and rather clever, 
 certainly, but hardly self-documenting: it's not very clear what it's doing 
 at all- with a couple of magic numbers thrown in for good measure. Rather 
 arcane in fact.

 Is it just me? Is this considered to be good Clojure code and I'm just 
 hopelessly out of touch and need to get with the programme?




  

-- 
-- 
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.