Re: How to speed up Clojure Training for New Recruitment

[Julian]

Thanks Jay, 

Those articles are indeed inspirational. I was just wondering - back from 
your TW days - would the arguments in those articles make sense for a TW 
consultant to present to a client?

Cheers, Julian

On Tuesday, 19 June 2012 01:22:34 UTC+10, Jay Fields wrote:
>
>
> learning curve, and training time be reduced for new recruits ? Also how 
> do you pitch it to the management ? 
>  
> I'd read this for inspiration on how to talk to mgmt. Perhaps I'd even 
> suggest they read it. http://www.paulgraham.com/avg.html 
> Related: http://www.paulgraham.com/icad.html
>
> Cheers, Jay
>

-- 
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: Standard alias for partial?

[Vinzent]

Why it has to be reader macro? I don't see any reason.

среда, 20 июня 2012 г., 0:56:15 UTC+6 пользователь Jay Fields написал:
>
> I'd actually like to see %(...) become (partial ...), as I think 
> people associate % with anonymous functions. Which is why I chose (% 
> ...), as it's close to what I wish we had. 
>
> I get your point though, and I don't disagree. But, this does keep 
> coming up, so I think a shorter syntax for partial would be nice, 
> whether it's %(), #&() or whatever. 
>
> Cheers, Jay 
>
> On Tue, Jun 19, 2012 at 2:52 PM, Timothy Baldridge  
> wrote: 
> >> uh, it's going to do what you expect... 
> >> 
> >> user=>  (def % partial) 
> >> #'user/% 
> >> user=> (map #(inc %) [1 2 3]) 
> >> (2 3 4) 
> > 
> > My point was that you have overloaded the meaning of the % symbol. If 
> > someone says "what does % mean in clojure". You can say "it's 
> > shorthand for the first argument in the shorthand version of the 
> > anonymous function definition.", now you have to say "well it depends 
> > on the scope" 
> > 
> > Please, don't ever take reader macros and re-define them out of scope 
> > to mean something else. It just confuses people and makes the code 
> > harder to read. 
> > 
> > Timothy 
> > 
> > -- 
> > 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: A tutorial for how to setup your clojure development environment for: Emacs, Leiningen and Linux.

[Chris Zheng]

I was using textmate and a repl for the longest time because I was put off 
by the intricacies of emacs.. and then I found this:

https://github.com/overtone/emacs-live

and the tutorial that recommended it

http://www.vijaykiran.com/2012/01/11/web-application-development-with-clojure-part-1/

It's great. I'm completely sold on emacs.. On any computer, I install 
emacs, install lein, run one command: 

$ git clone https://github.com/overtone/emacs-live ~/emacs.d 

Now I have everything I need to develop in clojure like hinting, 
autocomplete and docs. Most importantly, it has a black background and 
fluro text by default. NO CUSTOMISATIONS!

I remember how difficult it was for me as a complete newbie coming into the 
language. Thinking in a functional style was hard enough, let alone trying 
to get swank working and then frustrating over every aspect of emacs 
banging my head against the wall would have been more productive.

It was so frusting because I just wanted something that worked and a bunch 
of tutorials that showed me how to get started. Things like autocomplete 
and documentation are essential for learning the concepts quickly. Its only 
recently that a spate of them has come out for the joe programmer and its 
really good to see that happening. 

My 2 cents:
 - New users don't want complication. Give them one 'product' to start off 
with and then slowly introduce them to more concepts later

 - Videos and Tutorials are a must. Its not about showing off about "look 
how short I can make my code man"... Its about helping others see a new way 
to think about the problem. The only way to do that besides sitting down 
with them is through tutorials. Longer tutorials and demonstrations that 
work through a complete problem are more helpful than short ones that are 
demonstrating the 'feature.. Hats off in particular to Brian Marick 
(http://vimeo.com/19404746), Chas Emerick 
(http://www.youtube.com/watch?v=VVd4ow-ZcX0), and Phil Hagelburg 
(https://peepcode.com/products/functional-programming-with-clojure) for 
taking the time to show the world how they worked through a 'real-world' 
problem.

So basically, if a 'lead clojure evangelist' can either 'officially' or 
'unofficially' recommend ONE emacs setup, along with a bunch of 
videos/tutorials that demonstrate how to code and how fast it is to design 
and code using the repl. Then that be enough to get people at least 
interested. 

Expanding on that idea, If there were a set of peepcode-like 1 to 1.5h 
tutorials for clojure and its libraries (an episode on ring, an episode on 
agents futures and watches, an episode on incanter, an episode on writing a 
dsl, an episode on aleph..., an episode on writing a clojurescript 
application and also doing 'play-by-play' videos with top clojure 
developers), I'm sure newbies are going to take up the language much faster 
because they will have the crutches to allow them to explore the clojure 
landscape without worrying about how to go about entering text into 
a arcane text-editor.

-- 
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: memoization of an no-arg fn that returns a map?makes sense?

[Maik Schünemann]

Memoization of a no arg function sounds silly but maybe a deref is what you
are looking for. The first time you access it it is computed the next times
it is just there
 Am 19.06.2012 13:47 schrieb "Jim - FooBar();" :

> Ok we've established that accessing records fields is much faster than
> using regular maps...what will happen though if we create a memoized fn
> that simply returns the map? will records still be faster? also if some of
> they keys in the map point to other functions do they need to be memoized
> as well?
>
> Jim
>
> --
> 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+unsubscribe@**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: Standard alias for partial?

[Joel Ericson]

Only case I can see where it doesn't "work".
user=> (def % partial)
#'user/%
user=> (map #(% + %) [1 2 3]) ;trying to use #(% + %) instead of #(partial
+ %)
ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn
user/eval2/fn--3 (NO_SOURCE_FILE:2)

; (Also: my first post in this group. :))

On Tue, Jun 19, 2012 at 8:41 PM, Jay Fields  wrote:

> uh, it's going to do what you expect...
>
> user=>  (def % partial)
> #'user/%
> user=> (map #(inc %) [1 2 3])
> (2 3 4)
>
>
> On Tue, Jun 19, 2012 at 2:33 PM, Jim - FooBar(); 
> wrote:
> > On 19/06/12 19:32, Timothy Baldridge wrote:
> >>
> >> That works until you try to use the shorthand for anonymous functions:
> >>
> >> (map #(inc %) [1 2 3]) ; what's this going to do?
> >>
> >> Timothy
> >
> >
> > Thank you! :-)
> >
> > Jim
> >
> >
> > --
> > 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: Standard alias for partial?

[Joel Ericson]

I propose using ☃. I don't think it has any other uses yet. ;)

On Tue, Jun 19, 2012 at 8:57 PM, Joel Ericson  wrote:

> Only case I can see where it doesn't "work".
>
> user=> (def % partial)
> #'user/%
> user=> (map #(% + %) [1 2 3]) ;trying to use #(% + %) instead of #(partial
> + %)
> ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn
> user/eval2/fn--3 (NO_SOURCE_FILE:2)
>
> ; (Also: my first post in this group. :))
>
>
> On Tue, Jun 19, 2012 at 8:41 PM, Jay Fields  wrote:
>
>> uh, it's going to do what you expect...
>>
>> user=>  (def % partial)
>> #'user/%
>> user=> (map #(inc %) [1 2 3])
>> (2 3 4)
>>
>>
>> On Tue, Jun 19, 2012 at 2:33 PM, Jim - FooBar(); 
>> wrote:
>> > On 19/06/12 19:32, Timothy Baldridge wrote:
>> >>
>> >> That works until you try to use the shorthand for anonymous functions:
>> >>
>> >> (map #(inc %) [1 2 3]) ; what's this going to do?
>> >>
>> >> Timothy
>> >
>> >
>> > Thank you! :-)
>> >
>> > Jim
>> >
>> >
>> > --
>> > 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: A tutorial for how to setup your clojure development environment for: Emacs, Leiningen and Linux.

[László Török]

+1, I had the same experience as Chris, lot of frustration until I found
Emacs-live
On Jun 20, 2012 1:54 PM, "Chris Zheng"  wrote:

> I was using textmate and a repl for the longest time because I was put off
> by the intricacies of emacs.. and then I found this:
>
> https://github.com/overtone/emacs-live
>
> and the tutorial that recommended it
>
>
> http://www.vijaykiran.com/2012/01/11/web-application-development-with-clojure-part-1/
>
> It's great. I'm completely sold on emacs.. On any computer, I install
> emacs, install lein, run one command:
>
> $ git clone https://github.com/overtone/emacs-live ~/emacs.d
>
> Now I have everything I need to develop in clojure like hinting,
> autocomplete and docs. Most importantly, it has a black background and
> fluro text by default. NO CUSTOMISATIONS!
>
> I remember how difficult it was for me as a complete newbie coming into
> the language. Thinking in a functional style was hard enough, let alone
> trying to get swank working and then frustrating over every aspect of
> emacs banging my head against the wall would have been more productive.
>
> It was so frusting because I just wanted something that worked and a bunch
> of tutorials that showed me how to get started. Things like autocomplete
> and documentation are essential for learning the concepts quickly. Its only
> recently that a spate of them has come out for the joe programmer and its
> really good to see that happening.
>
> My 2 cents:
>  - New users don't want complication. Give them one 'product' to start off
> with and then slowly introduce them to more concepts later
>
>  - Videos and Tutorials are a must. Its not about showing off about "look
> how short I can make my code man"... Its about helping others see a new way
> to think about the problem. The only way to do that besides sitting down
> with them is through tutorials. Longer tutorials and demonstrations that
> work through a complete problem are more helpful than short ones that are
> demonstrating the 'feature.. Hats off in particular to Brian Marick (
> http://vimeo.com/19404746), Chas Emerick (
> http://www.youtube.com/watch?v=VVd4ow-ZcX0), and Phil Hagelburg (
> https://peepcode.com/products/functional-programming-with-clojure) for
> taking the time to show the world how they worked through a 'real-world'
> problem.
>
> So basically, if a 'lead clojure evangelist' can either 'officially' or
> 'unofficially' recommend ONE emacs setup, along with a bunch of
> videos/tutorials that demonstrate how to code and how fast it is to design
> and code using the repl. Then that be enough to get people at least
> interested.
>
> Expanding on that idea, If there were a set of peepcode-like 1 to 1.5h
> tutorials for clojure and its libraries (an episode on ring, an episode on
> agents futures and watches, an episode on incanter, an episode on writing a
> dsl, an episode on aleph..., an episode on writing a clojurescript
> application and also doing 'play-by-play' videos with top clojure
> developers), I'm sure newbies are going to take up the language much faster
> because they will have the crutches to allow them to explore the clojure
> landscape without worrying about how to go about entering text into
> a arcane text-editor.
>
>  --
> 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: Wildcards in Leiningen Dependencies Versions

[Murtaza Husain]

Phil, Tasillo thanks for the reply. The plugin is very helpful.


On Tuesday, June 19, 2012 11:52:41 AM UTC+5:30, Tassilo Horn wrote:
>
> Phil Hagelberg  writes: 
>
> >> Does leiningen support wildcards in dependencies version numbers ? I 
> >> would usually like to use the latest version for some library, and it 
> >> would be nice if I can indicate it by using a wildcard, so tat I dont 
> >> need to keep checking if a new version has been released. 
> > 
> > You can do this, but it's not a good idea: 
> > https://github.com/technomancy/leiningen/wiki/Repeatability 
>
> I did use that, and as Phil points out ran into maven dependency issues. 
> My motivation was mainly that it's convenient when you get dependency 
> updates "for free", and I am pretty optimistic that my stuff usually 
> won't break if foobar-0.1.0 is updated to foobar-0.2.0. 
>
> Because of the dependency issues I stopped using version ranges, and in 
> the meantime I discovered the leiningen outdated plugin at 
>
>   https://github.com/ato/lein-outdated 
>
> Using that, running "lein outdated" tells you what dependencies have 
> received updates (on maven central, clojars, whatever you use), and you 
> can easily adjust versions and check if your project works with the new 
> versions, too.  That's about as convenient as version ranges, and it has 
> the added benefit of you knowing exactly what you've updated in case an 
> update really breaks something. 
>
> Bye, 
> Tassilo 
>

-- 
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: How to speed up Clojure Training for New Recruitment

[Jay Fields]

That's a complicated question. I think consultants* are incentivized
to present new technologies to clients and convince them it's the
right choice.** However, I don't think it ends up being the right
choice for the company on most occasions. I wish that weren't true,
but I believe that's the most common case.

If a client is already using Clojure, and wants to bring a consultancy
in, that's great for the consultancy. However, if a (traditionally
Java) client wants to bring in a consultancy, they are not likely to
be able to support any application written in Clojure. There will
definitely be exceptions; however, I think the general rule holds.

Adopting a language is tough and requires deep organizational
commitment. If a client is willing to make that commitment, great! If
not, you're likely going to fail - sooner or later. The most
interesting technical project I ever worked on was 75% abandoned when
our team left, as the in house devs were not able to support it. Part
of that was due to the way the client structured the contract;
however, the technology choice also contributed to that outcome.

I do believe that Clojure provides an advantage. I use it every day,
partly for that reason. However, you need the people around that can
support it, or it needs to be 'complete' - meaning zero maintenance. A
good example could be building a prototype.

* my statements are generalized to all consultancies, none of my
comments reflect opinions that only apply TW.
** given current consulting models. It doesn't have to be this way.

On Wed, Jun 20, 2012 at 7:53 AM, Jay Fields  wrote:
> That's a complicated question. I think consultants* are incentivized to
> present new technologies to clients and convince them it's the right
> choice.** However, I don't think it ends up being the right choice for the
> company on most occasions. I wish that weren't true, but I believe that's
> the most common case.
>
> If a client is already using Clojure, and wants to bring a consultancy in,
> that's great for the consultancy. However, if a (traditionally Java) client
> wants to bring in a consultancy, they are not likely to be able to support
> any application written in Clojure. There will definitely be exceptions;
> however, I think the general rule holds.
>
> Adopting a language is tough and requires deep organizational commitment. If
> a client is willing to make that commitment, great! If not, you're likely
> going to fail - sooner or later. The most interesting technical project I
> ever worked on was 75% abandoned when our team left, as the in house devs
> were not able to support it. Part of that was due to the way the client
> structured the contract; however, the technology choice also contributed to
> that outcome.
>
> I do believe that Clojure provides an advantage. I use it every day, partly
> for that reason. However, you need the people around that can
>
> * my statements are generalized to all consultancies, none of my comments
> reflect opinions that only apply TW.
> ** given current consulting models. It doesn't have to be this way.
>
>
> On Jun 20, 2012, at 7:37 AM, Julian wrote:
>
> Thanks Jay,
>
> Those articles are indeed inspirational. I was just wondering - back from
> your TW days - would the arguments in those articles make sense for a TW
> consultant to present to a client?
>
> Cheers, Julian
>
> On Tuesday, 19 June 2012 01:22:34 UTC+10, Jay Fields wrote:
>>
>>
>> learning curve, and training time be reduced for new recruits ? Also how
>> do you pitch it to the management ?
>>
>> I'd read this for inspiration on how to talk to mgmt. Perhaps I'd even
>> suggest they read it. http://www.paulgraham.com/avg.html
>> Related: http://www.paulgraham.com/icad.html
>>
>> Cheers, Jay
>
>
> --
> 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

source of functions

[Rogier Peters]

Hi,

With all the higher-order functions in the new reducers, I was
wondering if it is possible to print a generated function, like using
(source f).

This doesn't work:
user=> (defn f[x] (fn[y] (+ y x)))
#'user/f
user=> (def plus5 (f 5))
#'user/plus5
user=> (source plus5)
Source not found
nil



-- 
Rogier Peters
rogier@twitter, flickr, delicious

-- 
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: source of functions

[Phil Hagelberg]

On Wed, Jun 20, 2012 at 8:13 AM, Rogier Peters  wrote:
> With all the higher-order functions in the new reducers, I was
> wondering if it is possible to print a generated function, like using
> (source f).

You need serializable-fn for that:

https://github.com/technomancy/serializable-fn

-Phil

-- 
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: source of functions

[Ambrose Bonnaire-Sergeant]

This might possible in CLJS (?), but I don't think you can recover the
source in Clojure.

Thanks,
Ambrose

On Wed, Jun 20, 2012 at 11:13 PM, Rogier Peters wrote:

> Hi,
>
> With all the higher-order functions in the new reducers, I was
> wondering if it is possible to print a generated function, like using
> (source f).
>
> This doesn't work:
> user=> (defn f[x] (fn[y] (+ y x)))
> #'user/f
> user=> (def plus5 (f 5))
> #'user/plus5
> user=> (source plus5)
> Source not found
> nil
>
>
>
> --
> Rogier Peters
> rogier@twitter, flickr, delicious
>
> --
> 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: How to speed up Clojure Training for New Recruitment

[Andy Coolware]

> Oh, and I also believe training is mostly a waste of resources. Training is 
> pushing information.

It really depends how it is constructed. If it is a domain knowledge -
this is just a info push. If this is a skill to be acquired -  I have
seen many hands on dedicated labs very effective.

Now in terms of Clojure - training seem to be a bad word. It is more
an exercise and practice what is needed. Like getting a "black belt".
I say give them koans and 4clojure problems to solve (individually),
week of time  and this will lay out a good foundation. Speaking from
own experience - a month ago I did not know what Clojure is - now I am
fairly fluent at basic level.

A.

-- 
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: clojurescript crate library fails on non-nested list of tags

[Sean Neilan]

(Sorry it took me a while to respond.)

I can do that. But, that crashes when I pass that list into another
crate/html function.

I think I'll write a patch for this.

On Sun, Jun 10, 2012 at 12:44 AM, Dave Sann  wrote:

> probably something like:
>
> (map crate/html (list [:div.class1] [:div.class2]))
>
> untested.
>
> If you want to modify the dom in the process - then you could use doseq.
>
> D
>
>
>
>
> On Sunday, 10 June 2012 13:54:28 UTC+10, Sean Neilan wrote:
>>
>> Hey All,
>>
>> I was wondering if anybody has a work-around for doing a list of tags
>> like this:
>> (crate/html (list [:div.class1] [:div.class2]))
>>
>> Because it causes the browser repl to hang up & gives
>> Uncaught [:div.class1] is not a valid tag name.
>>
>> If I have a single div as the root, it works just fine.
>>
>> -Sean
>>
>>  --
> 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: clojurescript crate library fails on non-nested list of tags

[Sean Neilan]

Actually,
(crate/html [:div] [:div]) works! I don't need to put all the elements into
a list!

Nevermind!

On Wed, Jun 20, 2012 at 4:03 PM, Sean Neilan  wrote:

> (Sorry it took me a while to respond.)
>
> I can do that. But, that crashes when I pass that list into another
> crate/html function.
>
> I think I'll write a patch for this.
>
>
> On Sun, Jun 10, 2012 at 12:44 AM, Dave Sann  wrote:
>
>> probably something like:
>>
>> (map crate/html (list [:div.class1] [:div.class2]))
>>
>> untested.
>>
>> If you want to modify the dom in the process - then you could use doseq.
>>
>> D
>>
>>
>>
>>
>> On Sunday, 10 June 2012 13:54:28 UTC+10, Sean Neilan wrote:
>>>
>>> Hey All,
>>>
>>> I was wondering if anybody has a work-around for doing a list of tags
>>> like this:
>>> (crate/html (list [:div.class1] [:div.class2]))
>>>
>>> Because it causes the browser repl to hang up & gives
>>> Uncaught [:div.class1] is not a valid tag name.
>>>
>>> If I have a single div as the root, it works just fine.
>>>
>>> -Sean
>>>
>>>  --
>> 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: A tutorial for how to setup your clojure development environment for: Emacs, Leiningen and Linux.

[John Gabriele]

On Jun 18, 10:23 pm, Chris Zheng  wrote:
> I was using textmate and a repl for the longest time because I was put off
> by the intricacies of emacs.. and then {snip}

> Now I have everything I need to develop in clojure like hinting,
> autocomplete and docs. Most importantly, it has a black background and
> fluro text by default. NO CUSTOMISATIONS!

Sometimes you need to spend time with an editor + repl to see the
value in something more sophisticated.

Also, I suppose sometimes you end up sticking with the editor + repl
anyway. :)

> {snip}
> So basically, if a 'lead clojure evangelist' can either 'officially' or
> 'unofficially' recommend ONE emacs setup, along with a bunch of
> videos/tutorials that demonstrate how to code and how fast it is to design
> and code using the repl. Then that be enough to get people at least
> interested.

People are very opinionated about their editor/IDE. I think the Getting
+Started docs are good --- they separate:

  * if you want just Emacs plus the repl, here you go (clojure-mode
readme)
  * if you want Emacs + inferior-lisp, do this (this doc needs work)
  * if you want Emacs + swank/slime, do this (swank-clojure readme)

and of course also info on Eclipse, Clooj, and other editors/ide's as
well.

But I certainly agree with you that screencasts/videos/tutorials for
each of those are very useful. Categorized links to such presentations
are just what wiki's are good at providing. I don't know what the
attitude is toward links like that on the confluence wiki, but I hope
they're welcomed. It's not so bad keeping links on wiki's up to date.
Now keeping full docs coherent in wikis is another matter ... :)

---John

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

correctness / error checking for Clojure

[cperkins]

Awhile back I read a short essay by Olin Shivers (*) wherein he observed 
that static typing could help the compiler optimize code for the best 
performance, check the code for correctness/consistency and also provided a 
bit of documentation to the interface of a function.  This one activity, 
static typing, provides all three benefits.

But when I revisit the idea with my Rich Hickey inspired glasses on I think 
"*is that really a good thing? Isn't it complecting these three things? 
Needlessly?  And perhaps not doing any one of those tasks as well or as 
simply as a something dedicated to one task might*?".  

So taking up the task of insuring correctness/consistency but leaving aside 
static typing as is typically practiced.   How can we best catch errors and 
inconsistencies in our code before our end users do? How can we do this 
better than any competing system (like Haskell)? How quickly can errors be 
caught - run time, compile time, edit time? 

I don't have answers.  I think unit testing has a role, but it's 
interesting to try and imagine something that doesn't need unit testing.   
Does design-by-contract have a role?  Static types and type inference? How 
about instead of merely types, using *units* -- like inches and centimeters 
-- instead of simply using numbers?  How about interval ranges -- perhaps 
array reference is limited (at edit time or at compile time) to the range 
of 0 to (1- array-length), and any variable passed as an array index must 
be inferred to be within that range or an error is thrown by the 
correctness checker. And shouldn't the context of a conditional change a 
variables type? Example: (when (< 1 x 6) ) outside that statement 
xmight just be known to be a number, but inside the body of the 
when the correctness checker knowns it is greater than 1 and less than 6.  

I mostly work in Common Lisp and I started a small library to do 
consistency checks based on the usual notion of types.  Used some macros to 
declare the types succinctly and then collapse back to normal defun.  But I 
stopped work on it partly because I realized that static types aren't 
necessarily what I want. What I want is error and consistency checks that I 
can perform whenever desired and require the minimum amount of extra work 
to leverage (ideally zero extra work). 

Anyway, if anyone has done work in this area or has interesting ideas, etc. 
I'd love to discuss them.  

Thanks,

Chris


(*) I can't find this essay now, hopefully I'm not mis-remembering or 
mis-attributing it.

-- 
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: correctness / error checking for Clojure

[Jack Moffitt]

> So taking up the task of insuring correctness/consistency but leaving aside
> static typing as is typically practiced.   How can we best catch errors and
> inconsistencies in our code before our end users do? How can we do this
> better than any competing system (like Haskell)? How quickly can errors be
> caught - run time, compile time, edit time?

Dialyzer (a tool widely used in Erlang) may provide some ideas in this
direction. It can be used to infer types and to check for type
violations, in some cases without any annotations.

I don't think it's quite what you want, but like I said, perhaps more
food for thought.

More interesting is the work Kostis et al have done with Purity
(http://user.it.uu.se/~kostis/Papers/purity.pdf) which uses static
analysis to determine whether functions are referentially transparent
in order to have user-defined guard functions for Erlang's pattern
matching.

If you look at the other tools he and his colleagues have made
(http://www.erlang-factory.com/upload/presentations/347/Kostis.pdf)
you'll see that the Clojure community has already been busy along the
same lines (test.generative, the various semi-automated refactoring
tools, etc).

jack.

-- 
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: correctness / error checking for Clojure

[Ambrose Bonnaire-Sergeant]

Hi Chris,

Many of your ideas are already implemented in Typed Racket.

For using the context of following the current branch to refine the type,
see occurrence typing (paper, "Logical Types For Untyped Languages").

Typed Racket combines static checks and runtime contracts in a very cool
way. You can statically type check *untyped* code by declaring types for
the interfaces to untyped land. Typed land will treat it statically, and
the untyped boundary will be checked at runtime.

I'm currently in progress with Typed Clojure, which boils down to taking
everything relevant from Typed Racket and adapting it to Clojure, plus some
extra stuff for "ad-hoc object" maps, multimethods, protocols, JVM
integration etc.

https://github.com/frenchy64/typed-clojure

My literature review should bring you up to speed with the relevant
details. Typed Clojure is the subject of my undergraduate honours
dissertation.
http://cloud.github.com/downloads/frenchy64/papers/lit-review%20(1).pdf

Happy to elaborate if needed.

Thanks,
Ambrose

On Thu, Jun 21, 2012 at 11:55 AM, cperkins wrote:

> Awhile back I read a short essay by Olin Shivers (*) wherein he observed
> that static typing could help the compiler optimize code for the best
> performance, check the code for correctness/consistency and also provided a
> bit of documentation to the interface of a function.  This one activity,
> static typing, provides all three benefits.
>
> But when I revisit the idea with my Rich Hickey inspired glasses on I
> think "*is that really a good thing? Isn't it complecting these three
> things? Needlessly?  And perhaps not doing any one of those tasks as well
> or as simply as a something dedicated to one task might*?".
>
> So taking up the task of insuring correctness/consistency but leaving
> aside static typing as is typically practiced.   How can we best catch
> errors and inconsistencies in our code before our end users do? How can we
> do this better than any competing system (like Haskell)? How quickly can
> errors be caught - run time, compile time, edit time?
>
> I don't have answers.  I think unit testing has a role, but it's
> interesting to try and imagine something that doesn't need unit testing.
> Does design-by-contract have a role?  Static types and type inference? How
> about instead of merely types, using *units* -- like inches and
> centimeters -- instead of simply using numbers?  How about interval ranges
> -- perhaps array reference is limited (at edit time or at compile time) to
> the range of 0 to (1- array-length), and any variable passed as an array
> index must be inferred to be within that range or an error is thrown by the
> correctness checker. And shouldn't the context of a conditional change a
> variables type? Example: (when (< 1 x 6) ) outside that statement
> x might just be known to be a number, but inside the body of the when the
> correctness checker knowns it is greater than 1 and less than 6.
>
> I mostly work in Common Lisp and I started a small library to do
> consistency checks based on the usual notion of types.  Used some macros to
> declare the types succinctly and then collapse back to normal defun.  But I
> stopped work on it partly because I realized that static types aren't
> necessarily what I want. What I want is error and consistency checks that I
> can perform whenever desired and require the minimum amount of extra work
> to leverage (ideally zero extra work).
>
> Anyway, if anyone has done work in this area or has interesting ideas,
> etc. I'd love to discuss them.
>
> Thanks,
>
> Chris
>
>
> (*) I can't find this essay now, hopefully I'm not mis-remembering or
> mis-attributing it.
>
> --
> 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

[ANN] clojure.java.jdbc 0.2.3 available on Maven Central

[Sean Corfield]

Just two changes in this release:

* as-str now treats a.b as two identifiers separated by . so quoting
produces [a].[b] instead of [a.b]

This was a bug that I'm kind of surprised no one had tripped over yet.
I fell over it as soon as I tried to build a DSL on top of the
library.

* Add :connection-uri option
[JDBC-34](http://dev.clojure.org/jira/browse/JDBC-34)

This was added in response to an observation by Chas Emerick about the
lack of any way to create a connection directly from a raw connection
URL and the DriverManager.

The next "big" release will add a new, more functional API (query,
execute!, insert!, update!, delete! etc). The jury is still out on a
simple DSL for common SQL operations. You can see a hint of where I'm
going in this repo: https://github.com/seancorfield/jsql

Clarification (based on some off-list comments I've received): I have
no intention of trying to shoehorn something like Korma or ClojureQL
into java.jdbc. Any DSL that gets added will be simple and only
intended to deal with common cases - and with an easy way to drop down
to SQL itself. The main thrust is to get an API i place that doesn't
rely on dynamic variables.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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