Re: Type annonations in clojure.instant/print-date result in speedup of 3

[Andy Fingerhut]

Thanks for checking, Alexander.  I have created ticket CLJ-1277 with a
patch that improves the performance of the case you found, as well as for
java.sql.Timestamp printing that also had reflection in it nearly identical
to what you found.

http://dev.clojure.org/jira/browse/CLJ-1277

Feel free to create an account on JIRA and vote for it, if you want to help
draw attention to it:

http://dev.clojure.org/jira/secure/Signup!default.jspa

You can also click the "Watch" link (after logging in) if you want to be
emailed of updates to the ticket's status.  I can make no promises on when
or if that might happen.

Andy


On Wed, Oct 9, 2013 at 10:47 AM, Alexander Kiel wrote:

> Hi Andy,
>
> http://dev.clojure.org/jira/browse/CLJ-1080 has not the same type hints
> as I propose. You can see my patch here:
>
> https://github.com/alexanderkiel/clojure/compare/instant-type-hints
>
> I have an additional type hint at thread-local-utc-date-format and I use
> java.text.DateFormat instead of java.text.SimpleDateFormat at utc-format.
>
> Alex
>
> Am Mittwoch, 9. Oktober 2013 18:49:32 UTC+2 schrieb Andy Fingerhut:
>>
>> Could you take a look at the patch on ticket CLJ-1080 and see if it
>> contains all of the improvements you mention?  Let me know if it doesn't,
>> and we can look at combining your improvements into that patch.
>>
>> 
>> http://dev.clojure.org/jira/**browse/CLJ-1080
>>
>> Andy
>>
>>
>> On Wed, Oct 9, 2013 at 8:57 AM, Alexander Kiel  wrote:
>>
>>> Hi,
>>>
>>> I have a web service returning edn representations containing many
>>> java.util.Date values. Using a profiler, one Hot Spot is inside the
>>> clojure.instant/print-date function. The relevant reflections warnings are:
>>>
>>> Reflection warning, 
>>> instant.clj:172:20
>>> - reference to field get can't be resolved.
>>> Reflection warning, instant.clj:174:15 - call to format can't be
>>> resolved.
>>> Reflection warning, instant.clj:174:5 - call to write can't be
>>> resolved.
>>>
>>> Adding a ^ThreadLocal annotation to thread-local-utc-date-**format and
>>> a ^java.text.DateFormat to utc-format resolves all reflection warnings.
>>>
>>> I tested the speedup with
>>>
>>> (time (let [d (java.util.Date.)] (doseq [_ (range 10)] (pr-str
>>> d
>>>
>>> which takes about 1500 ms without the type annotations and about 500 ms
>>> with type annotations.
>>>
>>> A single web service access is speeded up from about 350 ms to 250 ms.
>>> The response contains about 3000 java.util.Date values.
>>>
>>> I could create a pull request if that would help. But I like to discuss
>>> the change first. I have no CA so I use Clojure instead of Clojure Dev.
>>>
>>> Alex
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@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+u...@**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+u...@**googlegroups.com.
>>>
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>
>>  --
> --
> 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.
>

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

Re: Regarding http://clojuredocs.org

[Mark Engelberg]

Sometimes, it's also useful to be able to take things out.  I keep seeing
people get confused by clojuredocs references to contrib libraries that
have completely different names now.

-- 
-- 
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: Regarding http://clojuredocs.org

[Andy Fingerhut]

For all but the few functions and macros added to Clojure since 1.3,
ClojureDocs can be as actively maintained as people choose to update it.  I
add new facts that come to my attention there every so often, e.g.:

http://clojuredocs.org/clojure_core/clojure.core/subs
http://clojuredocs.org/clojure_core/clojure.core/read
http://clojuredocs.org/clojure_core/clojure.core/sorted-set-by

I'm not saying this is an ideal situation, but it isn't terrible, either.
There is also clojure-doc.org which is updated quite often, although it has
a different focus than ClojureDocs.org.

The Clojure Cheatsheet pointing at clojuredocs.org was my choice.  It
didn't seem terribly useful to have the links point at the
Autodoc-generated documentation, because I am pretty sure those are not
much more than the doc strings, which are available much more quickly in
the cheat sheet pop-up tool tips.

Andy


On Wed, Oct 9, 2013 at 9:21 PM, Bruce Wang  wrote:

>
>
>
> On Thu, Oct 10, 2013 at 1:44 PM, Mark Engelberg 
> wrote:
>
>> On Tue, Oct 8, 2013 at 9:55 PM, Bruce Wang  wrote:
>>
>>> The official docs is at http://clojure.org/documentation,
>>> http://clojure.github.io/clojure/
>>>
>>>
>>>
>> Sure, but the nice thing about clojuredocs is that it includes examples
>> for most of the functions and for a while, it was updated more frequently
>> than the regular documentation site.
>>
>> For example, I noticed the other day that in the main documentation site,
>> in the java interop section, there isn't much discussion about the
>> possibility of annotating functions of up to four arguments with primitive
>> types.  The fib example still shows the old way of handling primitives.
>> Where is one to learn these details?  Similarly, I noticed that the only
>> documentation about reducers is still a link to the original blog posts
>> which outline the idea, but are by no means thorough.  It would be great to
>> get back to having an active documentation repository for community
>> contributions.
>>
>
> Yep, you are right, I didn't realise The Clojure Cheatsheet[1] is actually
> pointing to clojuredocs.org
>
> [1]
> http://jafingerhut.github.io/cheatsheet-clj-1.3/cheatsheet-tiptip-cdocs-summary.html
>
>
>
> --
> simple is good
> http://brucewang.net
> http://twitter.com/number5
>
> --
> --
> 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.
>

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

Question about vector-of

[Mark Engelberg]

(def a (conj (vector-of :long) 1 2 3)
(inc (a 1))

Is Clojure smart enough to figure out that (a 1) is a primitive long and
call the fast primitive version of inc?

-- 
-- 
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: Regarding http://clojuredocs.org

[Bruce Wang]

On Thu, Oct 10, 2013 at 1:44 PM, Mark Engelberg wrote:

> On Tue, Oct 8, 2013 at 9:55 PM, Bruce Wang  wrote:
>
>> The official docs is at http://clojure.org/documentation,
>> http://clojure.github.io/clojure/
>>
>>
>>
> Sure, but the nice thing about clojuredocs is that it includes examples
> for most of the functions and for a while, it was updated more frequently
> than the regular documentation site.
>
> For example, I noticed the other day that in the main documentation site,
> in the java interop section, there isn't much discussion about the
> possibility of annotating functions of up to four arguments with primitive
> types.  The fib example still shows the old way of handling primitives.
> Where is one to learn these details?  Similarly, I noticed that the only
> documentation about reducers is still a link to the original blog posts
> which outline the idea, but are by no means thorough.  It would be great to
> get back to having an active documentation repository for community
> contributions.
>

Yep, you are right, I didn't realise The Clojure Cheatsheet[1] is actually
pointing to clojuredocs.org

[1]
http://jafingerhut.github.io/cheatsheet-clj-1.3/cheatsheet-tiptip-cdocs-summary.html



-- 
simple is good
http://brucewang.net
http://twitter.com/number5

-- 
-- 
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: Regarding http://clojuredocs.org

[Mark Engelberg]

On Tue, Oct 8, 2013 at 9:55 PM, Bruce Wang  wrote:

> The official docs is at http://clojure.org/documentation,
> http://clojure.github.io/clojure/
>
>
>
Sure, but the nice thing about clojuredocs is that it includes examples for
most of the functions and for a while, it was updated more frequently than
the regular documentation site.

For example, I noticed the other day that in the main documentation site,
in the java interop section, there isn't much discussion about the
possibility of annotating functions of up to four arguments with primitive
types.  The fib example still shows the old way of handling primitives.
Where is one to learn these details?  Similarly, I noticed that the only
documentation about reducers is still a link to the original blog posts
which outline the idea, but are by no means thorough.  It would be great to
get back to having an active documentation repository for community
contributions.

-- 
-- 
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: GSoC Report: CinC, port of the clojure compiler in clojure

[Mikera]

Good point Timothy - 100% agreed on the value of hard facts / benchmarks.

Though I think it's still useful to have some discussions first, in order 
to determine where to start / what to benchmark / where the problems are 
likely to be hiding. Good research should start with an understanding of 
the relevant issues, some hypotheses to test and a sensible experimental 
design - ideally before you start collecting too much data.

Also we shouldn't underestimate the value of sharing the wisdom and 
intuition gained from many years of optimising code on the JVM, which I'm 
sure many people around here can contribute :-)

On Wednesday, 9 October 2013 21:39:33 UTC+8, tbc++ wrote:
>
> One of the problems with these sort of discussions is the total lack of 
> hard facts. Words such as "could do this" or "doesn't do that" when 
> referring to HotSpot are very rarely backed up by actual benchmarks, or ASM 
> printouts. I would imagine that any serious attempt at an optimization 
> layer will be prefixed by lots of research into where the current compiler 
> fails, and what the proper enhancements should be. 
>
> Timothy
>
>
> On Wed, Oct 9, 2013 at 6:29 AM, Mikhail Kryshen 
> 
> > wrote:
>
>> Nicola Mometto > writes:
>>
>> > I don't think that's what Mike was talking about.
>> > Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an
>> > "public long invokePrim()" method.
>> >
>> > When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim
>> > instead of invoke.
>> >
>> > If we redefine (defn x [] "") then y won't work because the new version
>> > of x doesn't implement IFn$L, we'd need to recompile y too.
>>
>> Actually I am talking about the same problem.  For virtual calls the JIT
>> compiler can determine that only one implementation of the method is
>> being used, inline the call and perform object explosion, effectively
>> removing boxing of primitives.  When new implementation becomes
>> available it dynamically recompiles affected bytecode.  I don't know if
>> the current implementation does this for invokedynamic calls, but there
>> is a potential.  It just does not feel right to invent a whole new
>> complex optimization layer on the Clojure side until we fully use the
>> optimization capabilities of the JVM.
>>
>> --
>> Mikhail
>>
>
>
>
> -- 
> “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: [ANN] Public Early Access Program for Cursive, the IntelliJ-based Clojure IDE

[Colin Fleming]

Yeah, that's on my list to do very shortly - it'll make starting debug
REPLs much easier, too, as well as allowing saved configurations for
various remote servers.

Cheers,
Colin


On 9 October 2013 19:13,  wrote:

> Oh thanx, didn't see it up there. I guess there are million things you
> have in mind for this IDE, but speaking of REPL, I think that starting a
> REPL should not be a project level feature, but be exposed as one type of
> Run Configurations since its classpath (and maybe some other settings) can
> vary accross project's modules, or even module's profiles, so its good to
> have few REPL configurations. Of course, one can argue that this has to be
> developed with Leiningen support in mind, since it has profiles and
> subprojects (via lein-sub), so maybe this isn't trivially to design...
>
> Anyway, good work.
>
> -Vjeran
>
>
> On Tuesday, October 8, 2013 11:10:33 PM UTC+2, Colin Fleming wrote:
>
>> Hi Vjeran,
>>
>> Thanks! I'm glad you're liking it. The namespace in the current REPL is
>> displayed at the top of the window, in the REPL tab name.
>>
>> Cheers,
>> Colin
>>
>>
>> On 9 October 2013 07:52,  wrote:
>>
>>> Congratulations!
>>>
>>> EAP looks promising - its already much better than La Clojure. I don't
>>> know if this is intentionally done so, or is it some problem with Windows
>>> or whatever, but local nREPL session doesn't display current namespace
>>> which is very helpful of course. I had to use *ns* occasionaly to recall
>>> where I am.
>>>
>>> Anyway, great work.
>>>
>>> -Vjeran
>>>
>>>
>>>
>>  --
> --
> 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.
>

-- 
-- 
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: GSoC Report: CinC, port of the clojure compiler in clojure

[Mikera]

On Wednesday, 9 October 2013 20:29:46 UTC+8, Mikhail Kryshen wrote:

> Nicola Mometto > writes: 
>
> > I don't think that's what Mike was talking about. 
> > Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an 
> > "public long invokePrim()" method. 
> > 
> > When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim 
> > instead of invoke. 
> > 
> > If we redefine (defn x [] "") then y won't work because the new version 
> > of x doesn't implement IFn$L, we'd need to recompile y too. 
>
> Actually I am talking about the same problem.  For virtual calls the JIT 
> compiler can determine that only one implementation of the method is 
> being used, inline the call and perform object explosion, effectively 
> removing boxing of primitives.  When new implementation becomes 
> available it dynamically recompiles affected bytecode.  I don't know if 
> the current implementation does this for invokedynamic calls, but there 
> is a potential.  It just does not feel right to invent a whole new 
> complex optimization layer on the Clojure side until we fully use the 
> optimization capabilities of the JVM. 
>

The JVM is certainly amazing at optimising virtual calls (to be expected 
since that's the usual calling convention for majority of Java OOP code)

Clojure currently doesn't use virtual calls for functions however: that's 
part of the problem here. It pretty much always emits invokeinterface calls 
(via IFn and IFn's primitive variants). invokeinterface is slower than 
invokevirtual in many cases. They can certainly perform the same in cases 
where the JIT can eliminate the possibility of multiple implementations, 
but that's probably not going to be the case for IFn :-)

So part of making Clojure faster / making the most of the JVM should 
probably involve finding ways to use invokevirtual (or invokespecial) 
instead of invokeinterface where possible.

P.S. in the name of having some real performance data and to reassure 
myself that my knowledge of JVM behaviour is roughly correct, I made a 
quick caliper microbenchmark in Java to demonstrate the difference between 
interface and virtual dispatch:

 0% Scenario{vm=java, trial=0, benchmark=Interface} 13.04 ns; σ=0.19 ns @ 
10 trials
50% Scenario{vm=java, trial=0, benchmark=Virtual} 7.39 ns; σ=0.26 ns @ 10 
trials

benchmarkns linear runtime
Interface 13.04 ==
  Virtual  7.39 =

vm: java
trial: 0

Test code here for those interested:

https://github.com/mikera/vectorz/blob/develop/src/test/java/mikera/vectorz/performance/InterfaceVsVirtualBenchmark.java


-- 
-- 
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: How to type hint a String array?

[Qiu Xiafei]

Thanks, Jim.


On Wed, Oct 9, 2013 at 9:27 PM, Jim - FooBar(); wrote:

> On 09/10/13 14:12, Jim - FooBar(); wrote:
>
>> ps: also, non-primitive arrays are hinted like this if I'm not mistaken:
>> #^"[Ljava.lang.String;"
>>
>
> actually you can use both #^ & ^ in regular 'defn'
>
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to 
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>

-- 
-- 
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: Teaching Clojure to students (how ?)

[Denis Labaye]

Show interactive programing with the REPL.

For example implementing a data transformation function incrementally in
the REPL.

By starting with an example of input.
And successively bringing it closer to the final output. (Threading macros
work great for that).

I showed it to a few java developers who knew only TDD (or worst `public
static void main`).
Most of them were very impressed

On Oct 6, 2013 12:01 AM, "bernardH"  wrote:
>
> Hi all,
>
> I intend to (ab)use my authority as a teacher to enlighten unsuspecting
students
> about Clojure.
>
> On the plus side, I may give them insights that they did not even know
> they needed. On the minus side, I cannot expect (all of) them to be
> curious about Clojure.
>
> Hence, I want to make a "demand driven" introduction.
>
> My goal is to :
> 1. identify what novelties Clojure brings to the table to Java developers
>- homoiconicity : macros
>  - syntaxing sugar (e.g ->, cond)
>  - programming paradigms as libraries
>- core.logic
>- core.async
>- dynamic typing
>- simple concurrency handling :
>  - immutable data structures
>  - ref
>  - atoms
>  - STM
>- open-ended dynamic dispatching (protocols, namespaced vs. monkey
patching)
>- multiple dispatching (multimethods)
>- maps instead of classes (no privacy & accessors needed thx to
>  dynamic typing and immutable data) and composable libraries instead
>  of frameworks.
>
> 2. For as many of those features as possible, I'd like to find a minimal
use case that will be :
>- genuinely interesting (so that they find it beliveable that they
>  might actually want to solve a similar problem)
>
>- complex (if possible hard!) / tedious to solve in Java (I will
provide the Java code)
>
>- simple (if possible easy) to solve in Clojure.
>
>
> The idea being that they would conclude from :
> 1. that the want to solve these problems
> 2. that Java won't help them much but Clojure would help them a lot
>
> (+ 1. 2.) →
> 3. They want to learn Clojure ! ☺
>
> I'd be most grateful for any help, either to complete/amend my list in
1., or to provide ideas for 2.
>
>
> Best Regards,
>
> B.
>
> --
> --
> 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.

-- 
-- 
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: [ANN] Show the latest version of the library on your Github README page

[Alexander Yakushev]

The inability to select the text in SVG comes from  tag limitations. 
The following two ways of embedding SVG image into the webpage allows 
selecting text in both Webkit browsers and Firefox (in the latter via 
double-clicking and then right-click->Copy):

https://clojars.org/leiningen/latest-version.svg"; 
type="image/svg+xml">
https://clojars.org/leiningen/latest-version.svg"; 
type="image/svg+xml" />

Unfortunately, Github supports neither of them in its READMEs/wikis. So it 
can be used only when you have direct access to page's HTML, for instance 
on your own website or Github Pages.

Perhaps the inclusion of  on Github might be lobbied someday, but 
I'm afraid not in the foreseeable future.

On Wednesday, October 9, 2013 11:47:37 PM UTC+2, Christopher Allen wrote:
>
> Thank you for this!
>
> What could be done to make the text highlightable/copyable?
>
> On Tuesday, October 8, 2013 6:25:07 AM UTC-7, Alexander Yakushev wrote:
>>
>> Have you ever felt annoyed to update the README after you released a new 
>> version of your project? Have your users ever struggled to make the older 
>> version work because you forgot to update that README? Suffer no more, 
>> because Clojars has just the right medicine for you.
>>
>> From now on, you can append */latest-version.svg* to your artefact's 
>> link, which will resolve to an image that shows the latest version of your 
>> project. Then you can embed this image in your README, or Wiki, or wherever 
>> else you like. A couple examples:
>>
>> https://clojars.org/leiningen/latest-version.svg
>> https://clojars.org/com.palletops/pallet-cli/latest-version.svg
>>
>> The only downside of using this feature is that the user can't just 
>> select and copy the dependency line anymore. Although Webkit-based browsers 
>> support text selection in SVGs (and Firefox's support for one is on the 
>> way) it works only when opening the single image, but not when the image is 
>> embedded into the page. But I hope it can be worked around somehow in 
>> future.
>>
>> Thanks to Nelson Morris and Phil Hagelberg for pushing this out!
>>
>

-- 
-- 
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: [ANN] Show the latest version of the library on your Github README page

[Christopher Allen]

Thank you for this!

What could be done to make the text highlightable/copyable?

On Tuesday, October 8, 2013 6:25:07 AM UTC-7, Alexander Yakushev wrote:
>
> Have you ever felt annoyed to update the README after you released a new 
> version of your project? Have your users ever struggled to make the older 
> version work because you forgot to update that README? Suffer no more, 
> because Clojars has just the right medicine for you.
>
> From now on, you can append */latest-version.svg* to your artefact's 
> link, which will resolve to an image that shows the latest version of your 
> project. Then you can embed this image in your README, or Wiki, or wherever 
> else you like. A couple examples:
>
> https://clojars.org/leiningen/latest-version.svg
> https://clojars.org/com.palletops/pallet-cli/latest-version.svg
>
> The only downside of using this feature is that the user can't just select 
> and copy the dependency line anymore. Although Webkit-based browsers 
> support text selection in SVGs (and Firefox's support for one is on the 
> way) it works only when opening the single image, but not when the image is 
> embedded into the page. But I hope it can be worked around somehow in 
> future.
>
> Thanks to Nelson Morris and Phil Hagelberg for pushing this out!
>

-- 
-- 
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: boolean java interopt puzzle/bug?!

[Pablo Nussembaum]

  
  
Thanks for the help and clarifications. 
My problem is that I'm working on a tool, as a part of my thesis, to
randomly execute annotated java classes to try discover its
behavior.
So if a class has a (b|B)oolean field and I read its value using
reflection it returns (using Field.get()) a Boolean that for clojure
will be always false.

In order to solve this issue I created the follow fn:

(defn- get-val 
  [^java.lang.reflect.Field f instance] 
  (let [value (.get f instance)]
    (if (instance? java.lang.Boolean value) 
  (boolean value)
  value)))
 
Thanks and regards,
-- 
Bauna


On 10/06/2013 10:57 PM, Andy Fingerhut
  wrote:


  There is also this page on ClojureDocs that might
shed some light on this quirk:

    http://clojuredocs.org/clojure_core/clojure.core/if
  
  

On Sun, Oct 6, 2013 at 6:14 PM, Rob
  Browning 
  wrote:
  
Gary Trakhman 
  writes:
  
  > Clojure's false and true are Boolean/FALSE and
  Boolean/TRUE, and for speed
  > reasons (I think) anything that checks for truthiness
  uses java's ==, which
  > will fail on any new Boolean object.  Usually, this
  isn't a problem, but
  > sometimes it is.  You can see that this assumption is
  pervasive by looking
  > at the implementations of 'true?' and 'false?', which
  use identical? and
  > the check for != Boolean.FALSE in
  > https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L2569
  

...and further, my understanding is that the Boolean
constructors are
more or less considered a mistake, and you should
effectively never
use them.  For example:

  http://rayfd.me/2007/01/17/the-evil-boolean-constructors/

Hope this helps
--
Rob Browning
rlb @defaultvalue.org
and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0
39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8
D377 8C7E 73A4
  

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

  


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


  




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

Re: Teaching Clojure to students (how ?)

[Sean Corfield]

Another very useful "getting started" plugin is lein-try:

https://github.com/rkneufeld/lein-try

Then you can do stuff like:

lein try [quil "1.6.0"]

;; taken from the quil getting started wiki:
(use 'quil.core)
(sketch :setup (fn [] (background 20) (ellipse 50 50 80 80)) :title
"The moon delights the night")

and you're off to the races without even needing a project created or
worrying about editing dependencies.

Sean

On Mon, Oct 7, 2013 at 8:12 PM, John Gabriele  wrote:
> On Monday, October 7, 2013 4:28:57 AM UTC-4, Phillip Lord wrote:
>>
>> Lee Spector  writes:
>>
>> > Also IMHO (just trying to deflect some flames here) the Clojure
>> > ecosystem currently lacks the ideal environment for this.
>>
>> Tend to agree with this also. As nice as leiningen is, Clojure seems to
>> inherit from Java bulky projects. Compare these two hello worlds:
>>
>> (println "hello world")
>>
>> to
>>
>> #!/usr/bin/python
>> print( "hello world" )
>>
>> Both equivalently simple, up and till the point you actually try to run
>> them. The best I came up with is...
>>
>> java -jar ~/.m2/repository/org/clojure/clojure/1.5.1/clojure-1.5.1.jar
>> hello_world.clj
>>
>> which, of course, depends on me having installed leiningen and used it.
>>
>
> For new users who want to get their feet wet right on the first day, I'd
> suggest this (after they make sure they've got Java installed):
>
>  #. Download `lein`, drop it into your ~/bin, and `chmod +x` it if
> necessary,
>  #. `lein version` (so it installs and thus creates ~/.lein directory (see
> next step))
>  #. `touch ~/.lein/profiles.clj`, and into that file put `{:user {:plugins
> [[lein-exec "0.3.1"]]}}` (or whatever the current version of [lein-exec] is
> when you're reading this. :) )
>
> [lein-exec]: https://github.com/kumarshantanu/lein-exec
>
> Now you can create your "hello world" about as simply as with P{erl,ython}:
>
>  #. create a ~/wherever/foo.clj file,
>  #. into it goes `(println "hi")`, then
>  #. run it in the prescribed way: `lein exec foo.clj`.
>
> -- 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
> ---
> 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.



-- 
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
--- 
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: ▶ Datomic: up and running - YouTube

[Jernau]

Thanks for the nice complement mimmo!

When I created the screencast I announced it in the Datomic group, but I 
didn't think to do it here too. Though because I introduce the database via 
a TDD Clojure project, hopefully it's relevant (and useful) for folks here 
as well.

Cheers, 
James

On Wednesday, October 9, 2013 9:56:17 AM UTC+2, Magomimmo wrote:
>
> Another very nice and useful screencast by James Trunk. Everything become 
> easy to understand when he explains it.   
>
> mimmo 
>
> https://www.youtube.com/watch?v=ao7xEwCjrWQ

-- 
-- 
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: Type annonations in clojure.instant/print-date result in speedup of 3

[Alexander Kiel]

Hi Andy,

http://dev.clojure.org/jira/browse/CLJ-1080 has not the same type hints as 
I propose. You can see my patch here:

https://github.com/alexanderkiel/clojure/compare/instant-type-hints

I have an additional type hint at thread-local-utc-date-format and I use 
java.text.DateFormat instead of java.text.SimpleDateFormat at utc-format.

Alex

Am Mittwoch, 9. Oktober 2013 18:49:32 UTC+2 schrieb Andy Fingerhut:
>
> Could you take a look at the patch on ticket CLJ-1080 and see if it 
> contains all of the improvements you mention?  Let me know if it doesn't, 
> and we can look at combining your improvements into that patch.
>
> http://dev.clojure.org/jira/browse/CLJ-1080
>
> Andy
>
>
> On Wed, Oct 9, 2013 at 8:57 AM, Alexander Kiel 
> > wrote:
>
>> Hi,
>>
>> I have a web service returning edn representations containing many 
>> java.util.Date values. Using a profiler, one Hot Spot is inside the 
>> clojure.instant/print-date function. The relevant reflections warnings are:
>>
>> Reflection warning, 
>> instant.clj:172:20
>>  
>> - reference to field get can't be resolved.
>> Reflection warning, instant.clj:174:15 - call to format can't be 
>> resolved.
>> Reflection warning, instant.clj:174:5 - call to write can't be 
>> resolved.
>>
>> Adding a ^ThreadLocal annotation to thread-local-utc-date-format and 
>> a ^java.text.DateFormat to utc-format resolves all reflection warnings.
>>
>> I tested the speedup with 
>>
>> (time (let [d (java.util.Date.)] (doseq [_ (range 10)] (pr-str 
>> d
>>
>> which takes about 1500 ms without the type annotations and about 500 ms 
>> with type annotations.
>>
>> A single web service access is speeded up from about 350 ms to 250 ms. 
>> The response contains about 3000 java.util.Date values.
>>
>> I could create a pull request if that would help. But I like to discuss 
>> the change first. I have no CA so I use Clojure instead of Clojure Dev.
>>
>> Alex
>>
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

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

Go block and call back functions

[Gary Zhao]

Hello

I'm wondering where the call back function will run in a go block. For 
example, if I use http-kit asynchronous mode, I will register a call back 
function. If I call http/get within a goroutine, will the callback run in 
the same goroutine or an arbitrary thread?

Also, since goroutine can't be blocked, I'm wondering what kinds of tasks 
are good to do in goroutine. http-kit sounds ok since it's non-blocking, 
but how about mongodb, redis operations etc.

Thanks
Gary

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

London Clojure opportunities

[David Shroder]

I hold my hands up immediately and make it clear I am a recruiter! Please 
before you automatically assume I am a typical recruiter and block me from 
any correspondence ever take a look at my linkedin profile! 

I am engaged on a search for Clojure and Clojurescript developers for 
central London and I am keen to speak to London based (or those willing to 
be based in London) Clojure developers. You do not need to have developed 
commercially in Clojure previously, but if you haven't you should have a 
code repository full to the brim with Clojure code.

Regardless if the opportunity is not right for you, I am always keen to 
speak to Clojure developers. I work almost exclusively in the Clojure 
market and I am always interested to learn more about Clojurians!

Dave

david.shroder@nicollcurtin,com
0207 397 0195

-- 
-- 
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: Type annonations in clojure.instant/print-date result in speedup of 3

[Andy Fingerhut]

Could you take a look at the patch on ticket CLJ-1080 and see if it
contains all of the improvements you mention?  Let me know if it doesn't,
and we can look at combining your improvements into that patch.

http://dev.clojure.org/jira/browse/CLJ-1080

Andy


On Wed, Oct 9, 2013 at 8:57 AM, Alexander Kiel wrote:

> Hi,
>
> I have a web service returning edn representations containing many
> java.util.Date values. Using a profiler, one Hot Spot is inside the
> clojure.instant/print-date function. The relevant reflections warnings are:
>
> Reflection warning, 
> instant.clj:172:20
> - reference to field get can't be resolved.
> Reflection warning, instant.clj:174:15 - call to format can't be
> resolved.
> Reflection warning, instant.clj:174:5 - call to write can't be
> resolved.
>
> Adding a ^ThreadLocal annotation to thread-local-utc-date-format and
> a ^java.text.DateFormat to utc-format resolves all reflection warnings.
>
> I tested the speedup with
>
> (time (let [d (java.util.Date.)] (doseq [_ (range 10)] (pr-str
> d
>
> which takes about 1500 ms without the type annotations and about 500 ms
> with type annotations.
>
> A single web service access is speeded up from about 350 ms to 250 ms. The
> response contains about 3000 java.util.Date values.
>
> I could create a pull request if that would help. But I like to discuss
> the change first. I have no CA so I use Clojure instead of Clojure Dev.
>
> Alex
>
> --
> --
> 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.
>

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

Type annonations in clojure.instant/print-date result in speedup of 3

[Alexander Kiel]

Hi,

I have a web service returning edn representations containing many 
java.util.Date values. Using a profiler, one Hot Spot is inside the 
clojure.instant/print-date function. The relevant reflections warnings are:

Reflection warning, 
instant.clj:172:20
 
- reference to field get can't be resolved.
Reflection warning, instant.clj:174:15 - call to format can't be 
resolved.
Reflection warning, instant.clj:174:5 - call to write can't be resolved.

Adding a ^ThreadLocal annotation to thread-local-utc-date-format and 
a ^java.text.DateFormat to utc-format resolves all reflection warnings.

I tested the speedup with 

(time (let [d (java.util.Date.)] (doseq [_ (range 10)] (pr-str d

which takes about 1500 ms without the type annotations and about 500 ms 
with type annotations.

A single web service access is speeded up from about 350 ms to 250 ms. The 
response contains about 3000 java.util.Date values.

I could create a pull request if that would help. But I like to discuss the 
change first. I have no CA so I use Clojure instead of Clojure Dev.

Alex

-- 
-- 
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: [ANN] Grenchman, for running Clojure code quickly

[John D. Hume]

On Wed, Oct 9, 2013 at 2:32 AM, Zack Maril  wrote:

> How does this vary from flatland/drip?
> -Zack
>

Grenchman connects to a JVM-with-nrepl you previously launched. Repeated
invocations from the command line will hit that same JVM, potentially
building up state over time, and Grenchman knows nothing of the JVM's
lifecycle.

Drip is a JVM "pre-launcher," so every time you run drip (with the same
classpath), you're running in a fresh JVM, with no state hanging around
from previous invocations.

-- 
-- 
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: GSoC Report: CinC, port of the clojure compiler in clojure

[Timothy Baldridge]

One of the problems with these sort of discussions is the total lack of
hard facts. Words such as "could do this" or "doesn't do that" when
referring to HotSpot are very rarely backed up by actual benchmarks, or ASM
printouts. I would imagine that any serious attempt at an optimization
layer will be prefixed by lots of research into where the current compiler
fails, and what the proper enhancements should be.

Timothy


On Wed, Oct 9, 2013 at 6:29 AM, Mikhail Kryshen  wrote:

> Nicola Mometto  writes:
>
> > I don't think that's what Mike was talking about.
> > Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an
> > "public long invokePrim()" method.
> >
> > When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim
> > instead of invoke.
> >
> > If we redefine (defn x [] "") then y won't work because the new version
> > of x doesn't implement IFn$L, we'd need to recompile y too.
>
> Actually I am talking about the same problem.  For virtual calls the JIT
> compiler can determine that only one implementation of the method is
> being used, inline the call and perform object explosion, effectively
> removing boxing of primitives.  When new implementation becomes
> available it dynamically recompiles affected bytecode.  I don't know if
> the current implementation does this for invokedynamic calls, but there
> is a potential.  It just does not feel right to invent a whole new
> complex optimization layer on the Clojure side until we fully use the
> optimization capabilities of the JVM.
>
> --
> Mikhail
>



-- 
“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: How to type hint a String array?

[Jim - FooBar();]

On 09/10/13 14:12, Jim - FooBar(); wrote:
ps: also, non-primitive arrays are hinted like this if I'm not 
mistaken: #^"[Ljava.lang.String;"


actually you can use both #^ & ^ in regular 'defn'

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 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: How to go about 'proving' why dynamically typed languages are better.

[Softaddicts]

I hate "quirks", too many things to achieve, less time remaining, less
brain estate to remember quirks :)

Luc P.


> Oh!
> 
> I don't hate JavaScript ;-)
> 
> I'm not a Clojure programmer, (and not a ClojureScript programmer). But I
> usually program in C#, Java, PHP and JavaScript. I know Lisp, Ruby and

> Python, but I don't "work" with them, only toy projects.
> 
> I found JavaScript the most flexible programming language (less ceremony
> than Ruby or Python), and combined with Node.js at server, browsers at

> client, JSON for messaging, and TDD, it shines!
> 
> Any quirk on JS language is easy to circumvent (ie. using module pattern,
> build and exercised with TDD), and IMO, it pays a lot to use it.
> 
> Angel "Java" Lopez
> @ajlopez
> 
> 
> 
> On Wed, Oct 9, 2013 at 9:26 AM, Softaddicts 
> wrote:
> 
> > Yeah but I hate JavaScript so no wonder it's not on the list.
> > I do however code in ClojureScript and avoid JS interop like
> > the plague as much as possible :)
> >
> > I had to deal too much with browser based GUIs before things like JQuery
> >
> > and similar things came to life or because the back end framework did not
> > allow me to use something more brilliant than plain JS... it got me
> > disgusted
> > pretty much.
> >
> > ClojureScript has changed my approach to browser based apps but
> > w/o JS as much as possible, now I can conceal my app logic in the
> > browser while using the back end as a resource provider.
> >
> > No more Dr Jekyll and Mr Hide syndrom...
> >
> > Luc P.
> >
> >
> > > And JavaScript is missing (OK, "a dozen scripting language")
> > > But today, JavaScript is very important in the picture.
> > > Even Clojure has ClojureScript
> > >
> > >
> > > On Wed, Oct 9, 2013 at 8:36 AM, Dennis Haupt 

> > wrote:
> > >
> > > > especially haskell & scala are missing in your list :)
> > > > as long as you haven't at least seen haskell, you haven't seen the
> > creme
> > > > de la creme of statically typed languages
> > > >
> > > >
> > > > 2013/10/9 Softaddicts 
> > > >
> > > >> Let's see:
> > > >>
> > > >> strong data typing:
> > > >>
> > > >> Fortran
> > > >> Cobol
> > > >> Pl/1
> > > >> Pascal
> > > >> C/C++
> > > >> Java
> > > >> C#
> > > >> Ruby
> > > >>
> > > >> à la carte data typing or no data typing at all:
> > > >>
> > > >> Basic (more or less depending on the implementation)
> > > >> Lisp
> > > >> Clojure
> > > >> A dozen assemblers
> > > >> A dozen scripting languages
> > > >>
> > > >> And I probably forgot some while excluding the ones I worked with
> > > >> (Algol, Simula, GPSS, ...) in academic projects. I used the above ones
> > > >> on real projects at work and not small projects.
> > > >>
> > > >> Lets keep SQL out of the picture, it's an exaggeration to call this a
> > > >> programming
> > > >> language.
> > > >>
> > > >> Still prefer less data typing or no typing at all :)
> > > >>
> > > >> Luc P.
> > > >>
> > > >>
> > > >> > let's see...
> > > >> > really used:
> > > >> > sql
> > > >> > java
> > > >> > javascript
> > > >> > basic
> > > >> > pascal/delphi
> > > >> > scala
> > > >> >
> > > >> > experimented with:
> > > >> > logo (some old language intended to teach people to make their first
> > > >> steps)
> > > >> > haskell
> > > >> > kotlin
> > > >> > clojure
> > > >> >
> > > >> > seen in action:
> > > >> > php
> > > >> > groovy
> > > >> >
> > > >> > still prefer smart static typing :D
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > 2013/10/9 Nando Breiter 
> > > >> >
> > > >> > >
> > > >> > >> The best explanation of these misunderstandings I've come across
> > is
> > > >> "What
> > > >> > >> to Know Before Debating Type Systems":
> > > >> > >>
> > > >> > >> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
> > > >> > >>
> > > >> > >>
> > > >> > > I have learned quite a lot from reading this article and following
> > > >> this
> > > >> > > discussion, particularly that "type" and "type checking" is much
> > more
> > > >> > > nuanced and complex than I have understood until now, and that the
> > > >> terms
> > > >> > > "static" and "dynamic" expand into a much larger range of issues
> > upon
> > > >> close
> > > >> > > examination, such as the difference between explicitly declaring
> > > >> types (as
> > > >> > > in Java) and implicitly inferring types from code context. Quoting
> > > >> from the
> > > >> > > article:
> > > >> > >
> > > >> > > *Many programmers approach the question of whether they prefer
> > static
> > > >> or
> > > >> > > dynamic types by comparing some languages they know that use both
> > > >> > > techniques. This is a reasonable approach to most questions of
> > > >> preference.
> > > >> > > The problem, in this case, is that most programmers have limited
> > > >> > > experience, and haven’t tried a lot of languages. For context,
> > here,
> > > >> six or
> > > >> > > seven doesn't count as “a lot.”*
> > > >> > > *
> > > >> > > *
> > > >> > >
> > > >> > > So I can say I prefer dynamic typing, but the reasons are more

Re: How to go about 'proving' why dynamically typed languages are better.

[Angel Java Lopez]

Oh!

I don't hate JavaScript ;-)

I'm not a Clojure programmer, (and not a ClojureScript programmer). But I
usually program in C#, Java, PHP and JavaScript. I know Lisp, Ruby and
Python, but I don't "work" with them, only toy projects.

I found JavaScript the most flexible programming language (less ceremony
than Ruby or Python), and combined with Node.js at server, browsers at
client, JSON for messaging, and TDD, it shines!

Any quirk on JS language is easy to circumvent (ie. using module pattern,
build and exercised with TDD), and IMO, it pays a lot to use it.

Angel "Java" Lopez
@ajlopez



On Wed, Oct 9, 2013 at 9:26 AM, Softaddicts wrote:

> Yeah but I hate JavaScript so no wonder it's not on the list.
> I do however code in ClojureScript and avoid JS interop like
> the plague as much as possible :)
>
> I had to deal too much with browser based GUIs before things like JQuery
>
> and similar things came to life or because the back end framework did not
> allow me to use something more brilliant than plain JS... it got me
> disgusted
> pretty much.
>
> ClojureScript has changed my approach to browser based apps but
> w/o JS as much as possible, now I can conceal my app logic in the
> browser while using the back end as a resource provider.
>
> No more Dr Jekyll and Mr Hide syndrom...
>
> Luc P.
>
>
> > And JavaScript is missing (OK, "a dozen scripting language")
> > But today, JavaScript is very important in the picture.
> > Even Clojure has ClojureScript
> >
> >
> > On Wed, Oct 9, 2013 at 8:36 AM, Dennis Haupt 
> wrote:
> >
> > > especially haskell & scala are missing in your list :)
> > > as long as you haven't at least seen haskell, you haven't seen the
> creme
> > > de la creme of statically typed languages
> > >
> > >
> > > 2013/10/9 Softaddicts 
> > >
> > >> Let's see:
> > >>
> > >> strong data typing:
> > >>
> > >> Fortran
> > >> Cobol
> > >> Pl/1
> > >> Pascal
> > >> C/C++
> > >> Java
> > >> C#
> > >> Ruby
> > >>
> > >> à la carte data typing or no data typing at all:
> > >>
> > >> Basic (more or less depending on the implementation)
> > >> Lisp
> > >> Clojure
> > >> A dozen assemblers
> > >> A dozen scripting languages
> > >>
> > >> And I probably forgot some while excluding the ones I worked with
> > >> (Algol, Simula, GPSS, ...) in academic projects. I used the above ones
> > >> on real projects at work and not small projects.
> > >>
> > >> Lets keep SQL out of the picture, it's an exaggeration to call this a
> > >> programming
> > >> language.
> > >>
> > >> Still prefer less data typing or no typing at all :)
> > >>
> > >> Luc P.
> > >>
> > >>
> > >> > let's see...
> > >> > really used:
> > >> > sql
> > >> > java
> > >> > javascript
> > >> > basic
> > >> > pascal/delphi
> > >> > scala
> > >> >
> > >> > experimented with:
> > >> > logo (some old language intended to teach people to make their first
> > >> steps)
> > >> > haskell
> > >> > kotlin
> > >> > clojure
> > >> >
> > >> > seen in action:
> > >> > php
> > >> > groovy
> > >> >
> > >> > still prefer smart static typing :D
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > 2013/10/9 Nando Breiter 
> > >> >
> > >> > >
> > >> > >> The best explanation of these misunderstandings I've come across
> is
> > >> "What
> > >> > >> to Know Before Debating Type Systems":
> > >> > >>
> > >> > >> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
> > >> > >>
> > >> > >>
> > >> > > I have learned quite a lot from reading this article and following
> > >> this
> > >> > > discussion, particularly that "type" and "type checking" is much
> more
> > >> > > nuanced and complex than I have understood until now, and that the
> > >> terms
> > >> > > "static" and "dynamic" expand into a much larger range of issues
> upon
> > >> close
> > >> > > examination, such as the difference between explicitly declaring
> > >> types (as
> > >> > > in Java) and implicitly inferring types from code context. Quoting
> > >> from the
> > >> > > article:
> > >> > >
> > >> > > *Many programmers approach the question of whether they prefer
> static
> > >> or
> > >> > > dynamic types by comparing some languages they know that use both
> > >> > > techniques. This is a reasonable approach to most questions of
> > >> preference.
> > >> > > The problem, in this case, is that most programmers have limited
> > >> > > experience, and haven’t tried a lot of languages. For context,
> here,
> > >> six or
> > >> > > seven doesn't count as “a lot.”*
> > >> > > *
> > >> > > *
> > >> > >
> > >> > > So I can say I prefer dynamic typing, but the reasons are more
> > >> personal,
> > >> > > and molded by my development experience.
> > >> > >
> > >> > > --
> > >> > > --
> > >> > > 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 

Re: How to type hint a String array?

[Jim - FooBar();]

From the 1.3 docs:


;; Currently Clojure does not permit type hints of arrays, e.g. ^ints as
;; argument types or return types in a definterface.  This may be enhanced
;; later.

Jim

ps: also, non-primitive arrays are hinted like this if I'm not mistaken: 
#^"[Ljava.lang.String;"



On 09/10/13 13:55, Qiu Xiafei wrote:
Clojure provide built-in type hint for primitive types such as: ^ints, 
^doubles, but how to type hint an array of arbitrary Class?

The following way dosn't work, too:

user=> (definterface MyInterface
  #_=>  (^"[Ljava.lang.String" method1 []))
user.MyInterface
user=> (.method1 (reify MyInterface (^"[Ljava.lang.String;" method1 
[this] )))


CompilerException java.lang.NoClassDefFoundError: [Ljava/lang/String, 
compiling:(NO_SOURCE_PATH:1:11)




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


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

How to type hint a String array?

[Qiu Xiafei]

Clojure provide built-in type hint for primitive types such as: ^ints,
^doubles, but how to type hint an array of arbitrary Class?
The following way dosn't work, too:

user=> (definterface MyInterface
  #_=>  (^"[Ljava.lang.String" method1 []))
user.MyInterface
user=> (.method1 (reify MyInterface (^"[Ljava.lang.String;" method1 [this]
)))

CompilerException java.lang.NoClassDefFoundError: [Ljava/lang/String,
compiling:(NO_SOURCE_PATH:1:11)



thanks!

-- 
-- 
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: GSoC Report: CinC, port of the clojure compiler in clojure

[Mikhail Kryshen]

Nicola Mometto  writes:

> I don't think that's what Mike was talking about.
> Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an
> "public long invokePrim()" method.
>
> When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim
> instead of invoke.
>
> If we redefine (defn x [] "") then y won't work because the new version
> of x doesn't implement IFn$L, we'd need to recompile y too.

Actually I am talking about the same problem.  For virtual calls the JIT
compiler can determine that only one implementation of the method is
being used, inline the call and perform object explosion, effectively
removing boxing of primitives.  When new implementation becomes
available it dynamically recompiles affected bytecode.  I don't know if
the current implementation does this for invokedynamic calls, but there
is a potential.  It just does not feel right to invent a whole new
complex optimization layer on the Clojure side until we fully use the
optimization capabilities of the JVM.

-- 
Mikhail


pgpKVfcWvSsNF.pgp
Description: PGP signature

Re: How to go about 'proving' why dynamically typed languages are better.

[Softaddicts]

Yeah but I hate JavaScript so no wonder it's not on the list.
I do however code in ClojureScript and avoid JS interop like
the plague as much as possible :)

I had to deal too much with browser based GUIs before things like JQuery

and similar things came to life or because the back end framework did not
allow me to use something more brilliant than plain JS... it got me disgusted
pretty much.

ClojureScript has changed my approach to browser based apps but
w/o JS as much as possible, now I can conceal my app logic in the
browser while using the back end as a resource provider.

No more Dr Jekyll and Mr Hide syndrom...

Luc P.


> And JavaScript is missing (OK, "a dozen scripting language")
> But today, JavaScript is very important in the picture.
> Even Clojure has ClojureScript
> 
> 
> On Wed, Oct 9, 2013 at 8:36 AM, Dennis Haupt  wrote:
> 
> > especially haskell & scala are missing in your list :)
> > as long as you haven't at least seen haskell, you haven't seen the creme
> > de la creme of statically typed languages
> >
> >
> > 2013/10/9 Softaddicts 
> >
> >> Let's see:
> >>
> >> strong data typing:
> >>
> >> Fortran
> >> Cobol
> >> Pl/1
> >> Pascal
> >> C/C++
> >> Java
> >> C#
> >> Ruby
> >>
> >> à la carte data typing or no data typing at all:
> >>
> >> Basic (more or less depending on the implementation)
> >> Lisp
> >> Clojure
> >> A dozen assemblers
> >> A dozen scripting languages
> >>
> >> And I probably forgot some while excluding the ones I worked with
> >> (Algol, Simula, GPSS, ...) in academic projects. I used the above ones
> >> on real projects at work and not small projects.
> >>
> >> Lets keep SQL out of the picture, it's an exaggeration to call this a
> >> programming
> >> language.
> >>
> >> Still prefer less data typing or no typing at all :)
> >>
> >> Luc P.
> >>
> >>
> >> > let's see...
> >> > really used:
> >> > sql
> >> > java
> >> > javascript
> >> > basic
> >> > pascal/delphi
> >> > scala
> >> >
> >> > experimented with:
> >> > logo (some old language intended to teach people to make their first
> >> steps)
> >> > haskell
> >> > kotlin
> >> > clojure
> >> >
> >> > seen in action:
> >> > php
> >> > groovy
> >> >
> >> > still prefer smart static typing :D
> >> >
> >> >
> >> >
> >> >
> >> > 2013/10/9 Nando Breiter 
> >> >
> >> > >
> >> > >> The best explanation of these misunderstandings I've come across is
> >> "What
> >> > >> to Know Before Debating Type Systems":
> >> > >>
> >> > >> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
> >> > >>
> >> > >>
> >> > > I have learned quite a lot from reading this article and following
> >> this
> >> > > discussion, particularly that "type" and "type checking" is much more
> >> > > nuanced and complex than I have understood until now, and that the
> >> terms
> >> > > "static" and "dynamic" expand into a much larger range of issues upon
> >> close
> >> > > examination, such as the difference between explicitly declaring
> >> types (as
> >> > > in Java) and implicitly inferring types from code context. Quoting
> >> from the
> >> > > article:
> >> > >
> >> > > *Many programmers approach the question of whether they prefer static
> >> or
> >> > > dynamic types by comparing some languages they know that use both
> >> > > techniques. This is a reasonable approach to most questions of
> >> preference.
> >> > > The problem, in this case, is that most programmers have limited
> >> > > experience, and haven’t tried a lot of languages. For context, here,
> >> six or
> >> > > seven doesn't count as “a lot.”*
> >> > > *
> >> > > *
> >> > >
> >> > > So I can say I prefer dynamic typing, but the reasons are more
> >> personal,
> >> > > and molded by my development experience.
> >> > >
> >> > > --
> >> > > --
> >> > > 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

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

Re: How to go about 'proving' why dynamically typed languages are better.

[Softaddicts]

That's what I said earlier, I need to find some type to dive into it.
As far as Scala is concerned, it's not on my list of items to learn.
Too Java-ish to me and clunky. It's not because you mix all the latest
features in a single language that the result is a significant landmark.


It took a significant amount if time to Haskell designers to think about

feature set, it's not the same caliber at all.
 
Before choosing Clojure for our product, I looked at it and rejected it and
still have no regrets doing so.

Java in it's future releases will follow on the same slippery road of feature
aggregation w/o coherency, the "let's please everyone" approach
never led to anything exceptional.

It makes only things more confusing thanks to these guys...
 
http://search.dilbert.com/search?p=R&srid=S3-USESD01&lbc=dilbert&w=marketing%20idea&url=http%3a%2f%2fdilbert.com%2fstrips%2fcomic%2f1999-02-06%2f&rk=7&uid=203834662&sid=2&ts=custom&rsc=YmDLFs%3as9q%3aosTfU&method=and&isort=date&view=list&filter=type%3acomic

Luc P.

> especially haskell & scala are missing in your list :)
> as long as you haven't at least seen haskell, you haven't seen the creme de
> la creme of statically typed languages
> 
> 
> 2013/10/9 Softaddicts 
> 
> > Let's see:
> >
> > strong data typing:
> >
> > Fortran
> > Cobol
> > Pl/1
> > Pascal
> > C/C++
> > Java
> > C#
> > Ruby
> >
> > à la carte data typing or no data typing at all:
> >
> > Basic (more or less depending on the implementation)
> > Lisp
> > Clojure
> > A dozen assemblers
> > A dozen scripting languages
> >
> > And I probably forgot some while excluding the ones I worked with
> > (Algol, Simula, GPSS, ...) in academic projects. I used the above ones
> > on real projects at work and not small projects.
> >
> > Lets keep SQL out of the picture, it's an exaggeration to call this a
> > programming
> > language.
> >
> > Still prefer less data typing or no typing at all :)
> >
> > Luc P.
> >
> >
> > > let's see...
> > > really used:
> > > sql
> > > java
> > > javascript
> > > basic
> > > pascal/delphi
> > > scala
> > >
> > > experimented with:
> > > logo (some old language intended to teach people to make their first
> > steps)
> > > haskell
> > > kotlin
> > > clojure
> > >
> > > seen in action:
> > > php
> > > groovy
> > >
> > > still prefer smart static typing :D
> > >
> > >
> > >
> > >
> > > 2013/10/9 Nando Breiter 
> > >
> > > >
> > > >> The best explanation of these misunderstandings I've come across is
> > "What
> > > >> to Know Before Debating Type Systems":
> > > >>
> > > >> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/

> > > >>
> > > >>
> > > > I have learned quite a lot from reading this article and following this
> > > > discussion, particularly that "type" and "type checking" is much more
> > > > nuanced and complex than I have understood until now, and that the
> > terms
> > > > "static" and "dynamic" expand into a much larger range of issues upon
> > close
> > > > examination, such as the difference between explicitly declaring types
> > (as
> > > > in Java) and implicitly inferring types from code context. Quoting
> > from the
> > > > article:
> > > >
> > > > *Many programmers approach the question of whether they prefer static
> > or
> > > > dynamic types by comparing some languages they know that use both
> > > > techniques. This is a reasonable approach to most questions of
> > preference.
> > > > The problem, in this case, is that most programmers have limited

> > > > experience, and haven’t tried a lot of languages. For context, here,
> > six or
> > > > seven doesn't count as “a lot.”*
> > > > *
> > > > *
> > > >
> > > > So I can say I prefer dynamic typing, but the reasons are more
> > personal,
> > > > and molded by my development experience.
> > > >
> > > > --
> > > > --
> > > > 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.
> > > >
> > >
> > > --
> > > --
> > > 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...@

Re: Teaching Clojure to students (how ?)

[bernardH]

Thanks for all the feedback.
I had already made sure that LightTable is already installed, and the 
plug-in for eclipse (that they already use). But I don't expect too much 
trouble on this front as they are already somewhat proficient (with even 
some converts to the church of Emacs ☺).

Cheers,

B.

-- 
-- 
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: Teaching Clojure to students (how ?)

[Phillip Lord]

Laurent PETIT  writes:
> 2013/10/9 Phillip Lord 
>> A persistant REPL would be nice (although, of course, as most evaluative
>> programmers restart periodically to avoid a balked environment, it might
>> introduce problems as well).
>>
>> A nice simple environment is key, but with a good path to more complex
>> functionality, as they become familiar the environment. I'd love to have
>> an IDE with a "newbie" mode which took away all the nonsense, and then
>> slowly turned it on with a "here's a new feature" dialog. Guess that's
>> not going to happen any time soon!
>>
>
>
> A web based simplified development environment, but directly connected to
> github underneath, and with a never stopped VM for each student (can be
> snapshotted, though).
>
> When time comes to know better, switch to the editor/IDE of your choice and
> get all things back from the github repo (but the persistent VM).


Yeah, that's a nice idea. Wouldn't be too hard to get it to work.

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
--- 
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: How to go about 'proving' why dynamically typed languages are better.

[Angel Java Lopez]

And JavaScript is missing (OK, "a dozen scripting language")
But today, JavaScript is very important in the picture.
Even Clojure has ClojureScript


On Wed, Oct 9, 2013 at 8:36 AM, Dennis Haupt  wrote:

> especially haskell & scala are missing in your list :)
> as long as you haven't at least seen haskell, you haven't seen the creme
> de la creme of statically typed languages
>
>
> 2013/10/9 Softaddicts 
>
>> Let's see:
>>
>> strong data typing:
>>
>> Fortran
>> Cobol
>> Pl/1
>> Pascal
>> C/C++
>> Java
>> C#
>> Ruby
>>
>> à la carte data typing or no data typing at all:
>>
>> Basic (more or less depending on the implementation)
>> Lisp
>> Clojure
>> A dozen assemblers
>> A dozen scripting languages
>>
>> And I probably forgot some while excluding the ones I worked with
>> (Algol, Simula, GPSS, ...) in academic projects. I used the above ones
>> on real projects at work and not small projects.
>>
>> Lets keep SQL out of the picture, it's an exaggeration to call this a
>> programming
>> language.
>>
>> Still prefer less data typing or no typing at all :)
>>
>> Luc P.
>>
>>
>> > let's see...
>> > really used:
>> > sql
>> > java
>> > javascript
>> > basic
>> > pascal/delphi
>> > scala
>> >
>> > experimented with:
>> > logo (some old language intended to teach people to make their first
>> steps)
>> > haskell
>> > kotlin
>> > clojure
>> >
>> > seen in action:
>> > php
>> > groovy
>> >
>> > still prefer smart static typing :D
>> >
>> >
>> >
>> >
>> > 2013/10/9 Nando Breiter 
>> >
>> > >
>> > >> The best explanation of these misunderstandings I've come across is
>> "What
>> > >> to Know Before Debating Type Systems":
>> > >>
>> > >> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
>> > >>
>> > >>
>> > > I have learned quite a lot from reading this article and following
>> this
>> > > discussion, particularly that "type" and "type checking" is much more
>> > > nuanced and complex than I have understood until now, and that the
>> terms
>> > > "static" and "dynamic" expand into a much larger range of issues upon
>> close
>> > > examination, such as the difference between explicitly declaring
>> types (as
>> > > in Java) and implicitly inferring types from code context. Quoting
>> from the
>> > > article:
>> > >
>> > > *Many programmers approach the question of whether they prefer static
>> or
>> > > dynamic types by comparing some languages they know that use both
>> > > techniques. This is a reasonable approach to most questions of
>> preference.
>> > > The problem, in this case, is that most programmers have limited
>> > > experience, and haven’t tried a lot of languages. For context, here,
>> six or
>> > > seven doesn't count as “a lot.”*
>> > > *
>> > > *
>> > >
>> > > So I can say I prefer dynamic typing, but the reasons are more
>> personal,
>> > > and molded by my development experience.
>> > >
>> > > --
>> > > --
>> > > 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.
>> > >
>> >
>> > --
>> > --
>> > 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.
>> >
>> --
>> Softaddicts sent by ibisMail from my ipad!
>>
>> --
>> --
>> 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

Re: How to go about 'proving' why dynamically typed languages are better.

[Dennis Haupt]

especially haskell & scala are missing in your list :)
as long as you haven't at least seen haskell, you haven't seen the creme de
la creme of statically typed languages


2013/10/9 Softaddicts 

> Let's see:
>
> strong data typing:
>
> Fortran
> Cobol
> Pl/1
> Pascal
> C/C++
> Java
> C#
> Ruby
>
> à la carte data typing or no data typing at all:
>
> Basic (more or less depending on the implementation)
> Lisp
> Clojure
> A dozen assemblers
> A dozen scripting languages
>
> And I probably forgot some while excluding the ones I worked with
> (Algol, Simula, GPSS, ...) in academic projects. I used the above ones
> on real projects at work and not small projects.
>
> Lets keep SQL out of the picture, it's an exaggeration to call this a
> programming
> language.
>
> Still prefer less data typing or no typing at all :)
>
> Luc P.
>
>
> > let's see...
> > really used:
> > sql
> > java
> > javascript
> > basic
> > pascal/delphi
> > scala
> >
> > experimented with:
> > logo (some old language intended to teach people to make their first
> steps)
> > haskell
> > kotlin
> > clojure
> >
> > seen in action:
> > php
> > groovy
> >
> > still prefer smart static typing :D
> >
> >
> >
> >
> > 2013/10/9 Nando Breiter 
> >
> > >
> > >> The best explanation of these misunderstandings I've come across is
> "What
> > >> to Know Before Debating Type Systems":
> > >>
> > >> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
> > >>
> > >>
> > > I have learned quite a lot from reading this article and following this
> > > discussion, particularly that "type" and "type checking" is much more
> > > nuanced and complex than I have understood until now, and that the
> terms
> > > "static" and "dynamic" expand into a much larger range of issues upon
> close
> > > examination, such as the difference between explicitly declaring types
> (as
> > > in Java) and implicitly inferring types from code context. Quoting
> from the
> > > article:
> > >
> > > *Many programmers approach the question of whether they prefer static
> or
> > > dynamic types by comparing some languages they know that use both
> > > techniques. This is a reasonable approach to most questions of
> preference.
> > > The problem, in this case, is that most programmers have limited
> > > experience, and haven’t tried a lot of languages. For context, here,
> six or
> > > seven doesn't count as “a lot.”*
> > > *
> > > *
> > >
> > > So I can say I prefer dynamic typing, but the reasons are more
> personal,
> > > and molded by my development experience.
> > >
> > > --
> > > --
> > > 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.
> > >
> >
> > --
> > --
> > 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.
> >
> --
> Softaddicts sent by ibisMail from my ipad!
>
> --
> --
> 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.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" grou

Re: How to go about 'proving' why dynamically typed languages are better.

[Softaddicts]

Let's see:

strong data typing:

Fortran
Cobol
Pl/1
Pascal
C/C++
Java
C#
Ruby

à la carte data typing or no data typing at all:

Basic (more or less depending on the implementation)
Lisp
Clojure
A dozen assemblers
A dozen scripting languages

And I probably forgot some while excluding the ones I worked with
(Algol, Simula, GPSS, ...) in academic projects. I used the above ones
on real projects at work and not small projects.

Lets keep SQL out of the picture, it's an exaggeration to call this a 
programming
language.
  
Still prefer less data typing or no typing at all :)

Luc P.


> let's see...
> really used:
> sql
> java
> javascript
> basic
> pascal/delphi
> scala
> 
> experimented with:
> logo (some old language intended to teach people to make their first steps)
> haskell
> kotlin
> clojure
> 
> seen in action:
> php
> groovy
> 
> still prefer smart static typing :D
> 
> 
> 
> 
> 2013/10/9 Nando Breiter 
> 
> >
> >> The best explanation of these misunderstandings I've come across is "What
> >> to Know Before Debating Type Systems":
> >>
> >> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
> >>
> >>
> > I have learned quite a lot from reading this article and following this
> > discussion, particularly that "type" and "type checking" is much more
> > nuanced and complex than I have understood until now, and that the terms
> > "static" and "dynamic" expand into a much larger range of issues upon close
> > examination, such as the difference between explicitly declaring types (as
> > in Java) and implicitly inferring types from code context. Quoting from the
> > article:
> >
> > *Many programmers approach the question of whether they prefer static or
> > dynamic types by comparing some languages they know that use both
> > techniques. This is a reasonable approach to most questions of preference.
> > The problem, in this case, is that most programmers have limited
> > experience, and haven’t tried a lot of languages. For context, here, six or
> > seven doesn't count as “a lot.”*
> > *
> > *
> >
> > So I can say I prefer dynamic typing, but the reasons are more personal,
> > and molded by my development experience.
> >
> > --
> > --
> > 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.
> >
> 
> -- 
> -- 
> 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.
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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: Teaching Clojure to students (how ?)

[Phillip Lord]

John Gabriele  writes:
> Thanks Phil! Didn't know you could do that! Wrote up some notes on getting 
> it working: 
> 


That's useful!

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
--- 
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: How to go about 'proving' why dynamically typed languages are better.

[Dennis Haupt]

let's see...
really used:
sql
java
javascript
basic
pascal/delphi
scala

experimented with:
logo (some old language intended to teach people to make their first steps)
haskell
kotlin
clojure

seen in action:
php
groovy

still prefer smart static typing :D




2013/10/9 Nando Breiter 

>
>> The best explanation of these misunderstandings I've come across is "What
>> to Know Before Debating Type Systems":
>>
>> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
>>
>>
> I have learned quite a lot from reading this article and following this
> discussion, particularly that "type" and "type checking" is much more
> nuanced and complex than I have understood until now, and that the terms
> "static" and "dynamic" expand into a much larger range of issues upon close
> examination, such as the difference between explicitly declaring types (as
> in Java) and implicitly inferring types from code context. Quoting from the
> article:
>
> *Many programmers approach the question of whether they prefer static or
> dynamic types by comparing some languages they know that use both
> techniques. This is a reasonable approach to most questions of preference.
> The problem, in this case, is that most programmers have limited
> experience, and haven’t tried a lot of languages. For context, here, six or
> seven doesn't count as “a lot.”*
> *
> *
>
> So I can say I prefer dynamic typing, but the reasons are more personal,
> and molded by my development experience.
>
> --
> --
> 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.
>

-- 
-- 
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: How to go about 'proving' why dynamically typed languages are better.

[Nando Breiter]

>
>
> The best explanation of these misunderstandings I've come across is "What
> to Know Before Debating Type Systems":
>
> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
>
>
I have learned quite a lot from reading this article and following this
discussion, particularly that "type" and "type checking" is much more
nuanced and complex than I have understood until now, and that the terms
"static" and "dynamic" expand into a much larger range of issues upon close
examination, such as the difference between explicitly declaring types (as
in Java) and implicitly inferring types from code context. Quoting from the
article:

*Many programmers approach the question of whether they prefer static or
dynamic types by comparing some languages they know that use both
techniques. This is a reasonable approach to most questions of preference.
The problem, in this case, is that most programmers have limited
experience, and haven’t tried a lot of languages. For context, here, six or
seven doesn't count as “a lot.”*
*
*

So I can say I prefer dynamic typing, but the reasons are more personal,
and molded by my development experience.

-- 
-- 
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: Teaching Clojure to students (how ?)

[Laurent PETIT]

2013/10/9 Phillip Lord 

>
>
> Nando Breiter  writes:
> > To me, this begins to look more like a "user interface" issue than
> strictly
> > a programming issue. The folks who do interface design have a technique -
> > "pretend it's magic". What would the solution look like if it was
> "magic" (
> > setting all programming considerations aside for the moment) ?
>
>
> This is, indeed, the case. When teaching programming to new programmers
> the minimum of pain points is an important consideration. At the moment,
> clojure is quite hard to get going with.
>
> Of course, Java is a total pain to get going with also ("hello new
> programmer, this is an IDE -- just ignore most of it"), so this isn't
> the only consideration.
>
>
> > The student installs something  ... opens something ... and something
> just
> > works. How would you flesh that out?
>
>
> Someone else installs something for the student.
>
> A persistant REPL would be nice (although, of course, as most evaluative
> programmers restart periodically to avoid a balked environment, it might
> introduce problems as well).
>
> A nice simple environment is key, but with a good path to more complex
> functionality, as they become familiar the environment. I'd love to have
> an IDE with a "newbie" mode which took away all the nonsense, and then
> slowly turned it on with a "here's a new feature" dialog. Guess that's
> not going to happen any time soon!
>


A web based simplified development environment, but directly connected to
github underneath, and with a never stopped VM for each student (can be
snapshotted, though).

When time comes to know better, switch to the editor/IDE of your choice and
get all things back from the github repo (but the persistent VM).

?



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

-- 
-- 
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: Teaching Clojure to students (how ?)

[Phillip Lord]

Nando Breiter  writes:
> To me, this begins to look more like a "user interface" issue than strictly
> a programming issue. The folks who do interface design have a technique -
> "pretend it's magic". What would the solution look like if it was "magic" (
> setting all programming considerations aside for the moment) ?


This is, indeed, the case. When teaching programming to new programmers
the minimum of pain points is an important consideration. At the moment,
clojure is quite hard to get going with.

Of course, Java is a total pain to get going with also ("hello new
programmer, this is an IDE -- just ignore most of it"), so this isn't
the only consideration.


> The student installs something  ... opens something ... and something just
> works. How would you flesh that out?


Someone else installs something for the student.

A persistant REPL would be nice (although, of course, as most evaluative
programmers restart periodically to avoid a balked environment, it might
introduce problems as well). 

A nice simple environment is key, but with a good path to more complex
functionality, as they become familiar the environment. I'd love to have
an IDE with a "newbie" mode which took away all the nonsense, and then
slowly turned it on with a "here's a new feature" dialog. Guess that's
not going to happen any time soon!

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
--- 
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: Regarding http://clojuredocs.org

[Marek Kubica]

On Tue, 8 Oct 2013 21:55:08 -0700
Andy Fingerhut  wrote:

> Those who created ClojureDocs.org made some progress towards
> rewriting the server side code in Clojure (it was originally
> developed in Ruby on Rails, IIRC), but have found it challenging to
> find enough time to finish that work.  I recall a month or two ago
> someone mentioning that they would be interested in finishing that
> work and updating the site, I think in a message on this group.

There was also a Clojure Cup entry which was doing a ClojureDocs
alternative, but no idea how far they got.

regards,
Marek

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

Fwd: ▶ Datomic: up and running - YouTube

[Mimmo Cosenza]

Another very nice and useful screencast by James Trunk. Everything become easy 
to understand when he explains it.   

mimmo

https://www.youtube.com/watch?v=ao7xEwCjrWQ

-- 
-- 
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: [ANN] Grenchman, for running Clojure code quickly

[Zack Maril]

How does this vary from flatland/drip?
-Zack

On Tuesday, October 8, 2013 9:49:16 PM UTC-5, Phil Hagelberg wrote:
>
> When we've polled Leiningen users in the past[1], the #1 pain point 
> people always report is its startup time. While there have been a number 
> of strategies suggested to reduce the annoyance of slow JVM startup time 
> and project loading, keeping your JVMs around can lead to awkward 
> workflows in some situations given the tooling we've had so far. 
>
> To this end I'm happy to announce the release of Grenchman, a tool for 
> executing Clojure code in a running process *quickly*: 
>
> http://leiningen.org/grench.html 
>
> With Grenchman you can launch an nREPL server in the background 
> (typically with `lein trampoline repl :headless`, but you can also embed 
> an nREPL server in a production setting) and then connect to it directly 
> From the command-line with minimal overhead: 
>
> $ time grench eval '(println "Hello, world!")' 
> Hello, world! 
>
> real0m0.117s 
> user0m0.024s 
> sys 0m0.024s 
>
> This opens up a number of new command-line-centric workflows. 
>
> You can also invoke Leiningen tasks from Grenchman if you launch a 
> separate out-of-project `lein repl :headless` server: 
>
> $ time grench lein version 
> Leiningen 2.3.3 on Java 1.6.0_27 OpenJDK 64-Bit Server VM 
> real0m0.118s 
> user0m0.032s 
> sys 0m0.020s 
>
> Finally, Grenchman includes its own interactive nREPL client using GNU 
> Readline: 
>
> $ grench repl 
> user=> (System/getProperty "user.dir") 
> "/home/phil/src/syme" 
> [...] 
>
> Plans for the next version[3] include completion in the repl client and 
> support for repl history and multi-line form input. While it is a very 
> young project, the non-interactive functionality is quite stable. 
>
> Please give Grenchman a try if this sounds interesting to you. The 
> install process is the same as Leiningen where you download and chmod an 
> executable, except that there is a different executable for different 
> platforms; I have precompiled binaries for several common platforms at 
> the link above and will post user-contributed builds for other platforms 
> I don't have access to if there is demand. 
>
> thanks, 
> Phil 
>
> [1] - https://lein-survey-2013.herokuapp.com/results and 
> https://lein-survey-2012.herokuapp.com/results 
>
> [2] - https://github.com/technomancy/leiningen/wiki/Faster 
>
> [3] - 
> https://github.com/technomancy/grenchman/issues?milestone=2&state=open 
>
> [4] - Grenchman was inspired to a degree by Jark 
> (http://icylisper.github.io/jark/) but does not share any code with 
> it. 
>
> [5] - Timings above are taken from my 4½-year-old laptop; newer hardware 
> would perform better. 
>

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