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

[Jason Lewis]

I think what you're banging your head against is the tension between 
computer science qua pure science, versus software engineering qua 
engineering practice.

This tension isn't unique to our field; mathematicians look down on 
theoretical physicists, who look down on practical physicists, who look 
down on engineers, all the way down to the humanities, who are generally 
ignored. Or, to summarize:


So, sure, from a theroetical standpoint, oriented toward proofs and 
provable correctness, type systems are superior. OTOH, for practicing 
software engineers, who care more about reliably and efficiently *building 
shit,* language flexibility is a massive boon, and we compensate for the 
lack of "provable correctness" with strategies like TDD.

I agree w/ Laurent; it's not a black/white issue... to me it's more apples 
and oranges, dispatching on intent. Are you trying to prove a theorem, or 
build software? Not that you can't build scalable web services in Haskell, 
but I don't know anyone within a standard deviation of "sanity" who has 
ever done so for production code. The beauty of Clojure is that it gives us 
the ability to create realiable, robust, real-world solutions without 
sacrificing elegance; not because it's dynamically typed or because it has 
an optional type system (although both of those aspects are great), but 
because it combines power and simplicity. 

Holy wars are fun for a while (if I wanted to start one on this list, I'd 
go into the superiority of vim over emacs), but if your real goal is 
building things, you gotta let them go, and when people start heckling the 
fact that Clojure doesn't implement Hindley-Milner type inference... just 
shrug, point to the reliable, scalable architecture you built in two weeks, 
and get back to work.

Just my US$0.02.

Jason

On Tuesday, October 8, 2013 12:46:41 AM UTC-4, zcaudate wrote:
>
> Hahaha, thanks Philip. Does it really take a doctorate to understand 
> classification of elephants? 
>
> I think the overall consensus is that having basic type checking is 
> good... but over doing types is bad. 
>
> Would this be a reasonable guideline for using types? 
>
>   1. Types are useful for structures that HOLD data (ints, strings, maps, 
> arrays… ) because they provide ways defining standard operations to 
> manipulate data that make sense in the context of that type of data. It is 
> helpful to have a type checker check that I am not accessing the 6th 
> element of a hashmap or that I am adding 10 to "Hello". 
>   
>   2. When a particular data-structure is sufficient for holding 
> information, then its better to just use the data-structure because we have 
> so many generic operations predefined. 
>
>   > For example, if I have to model customers in a line. I wouldn't 
> have type CUSTOMER and type LINE. I would just represent this as a QUEUE of 
>  MAPS…. 
>
>  
>
> However… I find that I am writing a lot of statements like this: 
>
> (cond (hash-map? v) 
> …… 
>
>(vector? v) 
> …… 
>
>(list? v) 
>….. 
>
> :else …..) 
>
> I'm not sure a type checker will help in that instance.

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

[Chris Zheng]

Hahaha, thanks Philip. Does it really take a doctorate to understand 
classification of elephants?

I think the overall consensus is that having basic type checking is good... but 
over doing types is bad.

Would this be a reasonable guideline for using types?

  1. Types are useful for structures that HOLD data (ints, strings, maps, 
arrays… ) because they provide ways defining standard operations to manipulate 
data that make sense in the context of that type of data. It is helpful to have 
a type checker check that I am not accessing the 6th element of a hashmap or 
that I am adding 10 to "Hello".
  
  2. When a particular data-structure is sufficient for holding information, 
then its better to just use the data-structure because we have so many generic 
operations predefined. 

  > For example, if I have to model customers in a line. I wouldn't have 
type CUSTOMER and type LINE. I would just represent this as a QUEUE of 
 MAPS….



However… I find that I am writing a lot of statements like this:

(cond (hash-map? v)
……

   (vector? v)
……

   (list? v)
   …..

:else …..)

I'm not sure a type checker will help in that instance.

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

Cut down uberjar size

[Ruslan Prokopchuk]

What are the best practices to cut down uberjar size? Is it able to 
automagically :exclude from project unused parts & dependencies of big 
libraries, and will it affect on uberjar size?

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

[John Gabriele]

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.

Re: GSoC Report: CinC, port of the clojure compiler in clojure

[Nicola Mometto]

Hi Mike,
First of all, thanks for the report and sorry for the late reply.

Your "proposal" looks like something that should definitely be tried out
in the long-term, however it implies adding a notable amount of
complexity, moving away from the  simple "read top level form -> analyze
-> compile and then forget about it" model of the current compiler.

My "short"-term idea is to have 3 different compile targets:
- a normal target, fields are untyped and everything is dynamic
- a locally typed target, local fields are typed and we use some bits of
  local-type inference, this should avoid a good amount of casting and
  still preserve the globally dynamic capabilities of clojure
- an optimizing target, tags every top-level with its inferred tag,
  losing some dynamicity but decreases the runtime-reflection

This way one can use the unoptimizing evaluation when e.g. developing
at the repl and then compile the code using the optimizing mode for
depoloyment; this is not unlike how clojurescript handles it with its
:simple/:whitespace/:advanced optimization levels.

Regarding the immutable environment idea -- honestly, that's (currently)
out of scope for CinC as it implies extensive changes on all the clojure 
runtime;
CinC is currently (only) a self-hosting analyzer/compiler with the
analyzer aiming for cross-runtime flexibility.
A complete clojure in clojure re-implementation implies a porting of the
whole runtime and it's not something I plan to do in the near future,
I've developed and will continue to develop tools.reader,
tools.analyzer, tools.analyzer.jvm and tools.emitter.jvm hoping that
they will be part of a clojure-in-clojure project some time but that will
require a lot of time and I'm not going to focus on that.

Anyway you're (and everybody) is more than welcome to contribute to CinC
and I'm open to discuss its development and the directions it should
take.

Nicola

Mikera writes:

> Hi Nicola,
>
> Congratulations - great work!
>
> My main idea/feedback is that I'd love to see the "optimised" mode become
> able to emit code that matches Java / Scala performance in all cases. This
> would be a huge boost for people (like me) who do a lot of numerical /
> realtime work and would love to do this in pure Clojure rather than
> dropping down to Java all the time.
>
> Mostly, the difference in performance comes from using the correct static
> types, avoiding boxing, and avoiding all the dynamic checks/casting that
> Clojure currently does.
>
> 1) To make that work, we need to make more use of static typing / type
> inference to emit the right optimised bytecode for each situation. Sounds
> like that is in your plan already.
>
> 2) This in turn means we are going to have to "recompile" if we want to
> retain any sort of dynamic behaviour. The current system of independently
> mutable vars won't work (for obvious reasons: changing a var could easily
> violate the previous type inference assumptions)
>
> 3) Doing recompilation efficiently and incrementally implies keeping a
> dependency graph of compiled code., as well as retaining the source code in
> memory.
>
> 4) For sanity and correctness reasons, I think the best approach to this is
> having an "immutable environment", i.e. any action that redefines a var
> (e.g. "def") produces a new modified immutable environment, including
> updated dependencies. Fortunately persistent data structures make this
> cheap.
>
> 5) Immutable environments also offer a number of other advantages over the
> current mutable namespaces, e.g. better ability to handle circular
> references, the ability to store snapshots of past environments and the
> ability to fork environments to create new independent application
> instances.
>
> That's a rough sketch of what I think would work for a truly great Clojure
> 2.0 "optimised mode". If we do all this, then we will be in a very good
> place:
> a) We'll have the compiled performance equal to Java (or maybe even better,
> if we can exploit some JVM features that Java doesn't)
> b) We'll retain all the dynamic / interactive coding capabilities of Lisp,
> which is part of what makes Clojure great now.
> c) Immutable environments can evolve to replace the current mutable
> namespace system - which I think would be a big win in the long term, and
> is the right way to go philosophically if we take the "programming with
> values" stuff seriously.
>
> If you are interested and able to make even part of this happen in CinC,
> happy to discuss and contribute where I can!
>
>
> On Monday, 23 September 2013 04:59:30 UTC+8, Nicola Mometto wrote:
>>
>>
>> For the past 3 months I've been working as part of my GSoC project,
>> on a port of the clojure compiler and analyzer to clojure.
>>
>> Tomorrow the GSoC will end, so this is a report of what I've accomplished
>> with this project thus far; note that I'm not going to stop working on
>> CinC now that the GSoC is over.
>>
>> First, a link to the project if anybody is interested:
>> https://githu

Re: Teaching Clojure to students (how ?)

[Lee Spector]

Hi James,

I have indeed tried LightTable, and it does indeed seem promising. Really 
exciting potential. But I've hit enough snags every time I've tried it that I 
haven't really found it useful (either for teaching or for my own use).

I just tried the latest version again, just now, and just for anyone who may 
care here are my (opinionated, and YMMV) reactions:

1. Is there auto-reindentation? I don't see it. Pretty essential, IMHO.

2. I can close a tab (like the documentation) if I control-click on it, but the 
pane remains... and I've ended up with lots of panes that I have to quit to get 
rid of. In general I love the look of the GUI but wish the controls were more 
obvious/standard in many cases.

3. Can automatic bracket insertion be turned off? It's problematic in my book, 
especially for newcomers who should be allowed to use the keyboarding skills 
that they already have.

4. Is there a block comment/uncomment feature?

5. The console output precedes every line with the file that generated it, 
which means that you can't get a clean output log. Lots of the code that I and 
my students write is oriented toward producing textual output in the console, 
and this sort of rules out those uses (unless you want to clean up the output 
later, which would be a pain).

6. Can I make a new project? I don't immediately see how... (Digression: tried 
to search the documentation for this but couldn't see how to do the search... I 
do get a (novel) find pane for my open editor window, but can I make that work 
for the documentation pane? Can I make it go away? Again, looks cool but I wish 
it leveraged more common GUI idioms.)

7. A new project created with lein at the command line works, but an older one 
gives "Light Table requires Clojure Version 1.5.1 or higher"... I see that that 
old project used [org.clojure/clojure "1.4.0"]... Awkward that this couldn't be 
run even if the IDE needs something newer for itself...

8. Expressions that produce big values can make it hard to read your code by 
interspersing the values, which I may not really want to see.

9. Is there anyway to get "arglist on space" or arglists (and/or documentation) 
in another pane or a popup or whatever, either as you type or when you hit a 
particular key?

Overall: Very cool in several ways, some glitches or little issues that I could 
live with, but also quite a few that would be pretty problematic to me 
personally, for my teaching and/or my own use (specifically 1, 3, 5, & 9).

Clooj is better on many of these issues, but it has some other weaknesses (esp 
that it is not maintained very actively, e.g. I don't know if it works with 
modern leiningen). NightCode is also getting into the running, I think. But 
from my perspective none of them yet fill the niche that I've been discussing.

 -Lee

PS I'd be in Clojure IDE heaven if someone could provide some version of one of 
these light-weight Clojure IDEs that also incorporated nrepl-ritz so that we 
could see the values of locals when we hit exceptions...



On Oct 7, 2013, at 4:15 PM, Jernau wrote:

> Lee,
> 
> Have you tried Light Table? I think it would be a perfect match for your 
> use-case.
> 
> Here's a screencast of me using Light Table's Instarepl to teach list 
> comprehension in Clojure. As you will hopefully agree, Light Table's features 
> are a great match for a learning/teaching situation.
> 
> Light Table's Instarepl works out-of-box after installation, so it'll be easy 
> to get your students up and running. Then, when your students have progressed 
> to wanting to create their own projects, they can install Leiningen and 
> continue to use Light Table (see my Datomic screencast for an example).
> 
> Kind regards, 
> James

-- 
-- 
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: Who uses HtmlUnit?

[Mimmo Cosenza]

Thanks to everyone for the very informed advices.

As soon as I have time and energy :( I'll take a look at this last 
cli-webdriver. 

Thanks again to everyone

mimmo

On Oct 7, 2013, at 11:32 AM, Niels van Klaveren  
wrote:

> Didn't see this was posted in the general Clojure group, and thought this had 
> been posted in another group.
> So if you want to do any automated web testing be sure to check out 
> clj-webdriver, the clojure library for Selenium Webdriver and it's Google 
> Group.
> Selenium is the java platform for browser automation, supporting most 
> browsers as well as headless browsers like HTMLunit and PhantomJS.
> 
> On Sunday, October 6, 2013 1:23:22 PM UTC+2, Magomimmo wrote:
> Hi all, 
> did anyone give a try to this java based HTMLUnit headless browser for cljs 
> unit test to be used of phantomjs? 
> 
> http://htmlunit.sourceforge.net/ 
> 
> Thanks 
> 
> Mimmo 
> 
> 
> -- 
> -- 
> 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 ?)

[Jernau]

Lee,

Have you tried Light Table ? I think it would be 
a perfect match for your use-case.

Here's a screencast  of me 
using Light Table's Instarepl to teach list comprehension in Clojure. As 
you will hopefully agree, Light Table's features are a great match for a 
learning/teaching situation.

Light Table's Instarepl works out-of-box after installation, so it'll be 
easy to get your students up and running. Then, when your students have 
progressed to wanting to create their own projects, they can install 
Leiningen and continue to use Light Table (see my Datomic screencast 
for an example).

Kind regards, 
James

On Monday, October 7, 2013 4:19:22 PM UTC+2, Lee wrote:
>
>
> On Oct 7, 2013, at 9:59 AM, John D. Hume wrote: 
> > I'd suggest that Clojure's "Hello, World!" should happen initially at 
> the repl, where leiningen definitely simplifies the UX. 
> > 
> >lein repl # from any cwd 
> >(println "...") 
> > 
> > which launches nicely into demonstrating dynamic development. 
>
> Agreed. But the complexity cliff is at the next step, after the first 
> demo. Then you really want an editor with some basic features like 
> auto-reindentation and bracket matching. 
>
> In my teaching context the REPL alone will get us through a productive 
> first day of class, but not a second, while something with roughly the 
> feature set of Clooj will get us through the first semester and maybe even 
> years of serious work depending on what kind of work we're doing. 
>
> -Lee 
>
>

-- 
-- 
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: clojars.org image for latest version of a project

[Sébastien Wagener]

It's a bit unfortunate that you cannot copy&paste the coordinates (that's
my main use of them).

Sébastien


2013/10/7 Nelson Morris 

> There is a new route on clojars.org that will create an svg of the lein
> coordinates for the latest version of a project. To use it add
> /latest-version.svg to a project url. An example can be found at
> https://clojars.org/compojure/latest-version.svg. This may be useful for
> a project readme.
>
> Many thanks to Alexander Yakushev (https://github.com/alexander-yakushev)
> for putting together the commit.
>
> -
> Nelson Morris
>
> --
> --
> 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.

ANN Introducing Machine Head, a Clojure MQTT client

[Michael Klishin]

I'm happy to announce a new ClojureWerkz project.:
Machine Head, a Clojure MQTT (v3.1) client.

Announcement blog post:
http://blog.clojurewerkz.org/blog/2013/10/07/introducing-machine-head/

Documentation site (far from being complete but Getting Started
is ready):
http://clojuremqtt.info

And finally, repositories on GitHub:

https://github.com/clojurewerkz/machine_head
https://github.com/clojurewerkz/machine_head.docs
https://github.com/clojurewerkz/machine_head.examples
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

clojars.org image for latest version of a project

[Nelson Morris]

There is a new route on clojars.org that will create an svg of the lein
coordinates for the latest version of a project. To use it add
/latest-version.svg to a project url. An example can be found at
https://clojars.org/compojure/latest-version.svg. This may be useful for a
project readme.

Many thanks to Alexander Yakushev (https://github.com/alexander-yakushev)
for putting together the commit.

-
Nelson Morris

-- 
-- 
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 reload Clojure files while connected to Clojurescript browser repl in Emacs?

[Tim Visher]

On Mon, Oct 7, 2013 at 2:26 AM, George Oliver  wrote:
> On Sunday, October 6, 2013 11:15:26 PM UTC-7, George Oliver wrote:
>> I could be wrong but my understanding is that the browser is just
>> connecting to your cljs repl which actually is in the 'clojure repl'.
>> Certainly if you refresh the page state built up in the browser is reset,
>> but state in the cljs repl is a different story.
>
> Well, that'll teach me to make a claim without verifying it first -- state
> in the repl -is- refreshed on a page refresh.

LOL. At least we both maybe have a better understanding of things now. :)

That would be pretty magical though, to have a js 'file', maybe served
out of ring, that is automatically updated based on interactions at
the repl so that your browser would always have the latest stuff. Sort
of like `cljsbuild auto`, but a slightly smaller hammer? I don't know
enough of what I'm talking about to take it further than that.

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

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

[ANN] Modern-cljs: Tutorial 20 - Learn by Contributing

[Giacomo Cosenza]

Hi all,
I just published the 20th Tutorial - Learn by Contrbuting - of the modern-cljs 
series. 

https://github.com/magomimmo/modern-cljs/blob/master/doc/tutorial-20.md

In this tutorial, while studying the very interesting and promising Enfocus 
lib, I'll started collaborating with Creighton Kirkendall, the author of 
Enfocus, by proposing few humble improvements:

- a directories layout more respectable of the separation of concerns
- the adoption of clojurescript.test lib for CLJS unit testing
- the update of the dependencies/plugins which also demonstrates where and when 
to use crossover/cljx. 

I want to thanks very much Creighton for being so kind and open to 
collaboration by accepting the above little improvements for the next 
2.0.1-SNAPHOT release.

I hope this tutorial could be useful to anyone desiring to start collaborating 
with others in this wonderful community. Creighton now need our help in moving 
all tests from the previous approach to the one based on clojurescript.test lib 
by the amazing Chas Emerick. 

Regarding CLJS unit testing we're really living on the edge and I'm sure that 
Creighton will be very open to receive any suggestion in terms of strategy, 
design and tools.

My best

Mimmo



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

[gaz jones]

Martin Odersky gave a keynote at Strangeloop this year called "The Trouble
With Types" (https://thestrangeloop.com/sessions/the-trouble-with-types)
which made me never want to use a type system again (probably the exact
opposite of his intention). The video should be coming out on infoq at some
point: (http://www.infoq.com/conferences/strangeloop2013/). I've never
looked at Scala before and I'm pretty sure I never will after sitting
through that...


On Mon, Oct 7, 2013 at 9:26 AM, juan.facorro  wrote:

> Thanks for the link! I really liked the interview, it was interesting and
> fun to watch.
>
> J
>
> On Monday, October 7, 2013 9:49:24 AM UTC+9, brad bowman wrote:
>>
>> > zcaudate  Oct 05 08:35PM -0700
>> > I'm a little bit miffed over this current craze of `types` and
>> > `correctness` of programs. It smells to me of the whole `object` craze
>> of
>> > the last two decades. I agree that types (like objects) have their
>> uses,
>> > especially in very well defined problems, but they have got me in
>> trouble
>> > over and over again when I am working in an area where the goal is
>> unclear
>> > and requirements are constantly changing.
>>
>> Joe Armstrong and Simon Peyton Jones discuss Erlang and Haskell
>> http://www.infoq.com/**interviews/armstrong-peyton-**jones-erlang-haskell
>>
>> This interview covers some of the strong-types vs flexible development
>> (apparent) dichotomy, but in a playful, open and non-dogmatic way.
>> (catmatic?)
>>
>> Simon Peyton Jones is one of the Haskell leaders, yet admits to
>> being envious of type-free generics.  Joe Armstrong of Erlang fame
>> also sees the benefit to thinking in and annotating types.
>> These two are both leaders of typed or dynamic cults but have
>> a pleasant friendly and frank conversation about the issues.
>> (Erlang's Dialyzer sounds somewhat like core.typed)
>>
>> A sample:
>>
>> SPJ: So, I've told you what I most envy about Erlang. What do you most
>> envy
>> about Haskell?
>>
>> JA: All the types. I mean they're very nice. I wish we had them. On the
>> other
>> hand, wouldn't you love to have all these generic turn-to-binary, these
>> sort
>> of things? How can you live without them?
>>
>> SPJ: I have a little bit of residual envy about generics.
>>
>> JA: You just take anything and compare it to the serializer and then send
>> it?
>>
>> SPJ: That's sinfully easy, and shouldn't be allowed.
>>
>>
>> So if these two can agree that there's strengths and weaknesses in both
>> approaches, that settles it for me.  It's a matter of knowing your
>> trade-offs and choosing your tools appropriately.
>>
>> My suspicion is that type affinity is related to some trait of
>> personality,
>> and so trying to "prove" superiority is a likely to work as "proving" you
>> are right in any other clash of personalities.
>>
>> Brad
>>
>>  --
> --
> 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: Newbie seeks advice

[Nando Breiter]

Functional Thinking with Neal Ford

http://www.youtube.com/watch?v=JeK979aqqqc



Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia


On Mon, Oct 7, 2013 at 4:22 PM, vMac  wrote:

> Thank you very much James for that detailed advice. I think it will take a
> while
> to get used to that new programming style.
> Is there any good source of information for learning functional
> programming (online, book)
> you could recommend?
> I'm right now programming mostly C -stylish with a bit knowledge of OO.
>
> -v
>
> --
> --
> 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 ?)

[Nando Breiter]

I'm in the process of trying to Clojure, and the fact that you need to
install leiningen (I think ...) isn't a problem. All I need is clear,
simple to follow instructions, and an explanation how all this plumbing
works, and what its advantages are. I find installation instructions rather
easily. Clear explanations about how the dependency plumbing works seem to
be a bit lacking up front.



Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia


On Mon, Oct 7, 2013 at 10:28 AM, Phillip Lord
wrote:

> Lee Spector  writes:
> > I teach Clojure, to beginning programmers among others.
> >
> > IMHO you really have to specify your audience(s) before any advice about
> how
> > best to teach Clojure (or programming in general) will make much sense.
>
> I'd absolutely agree with this. If you are teaching brand new
> programmers, then you really don't want to teach clojure at all; you
> want to teach programming, with the language being somewhat of a detail.
>
> You also need to know *why* you are teaching them. I teach differently
> if I am teaching new programmers hoping to gain a general understanding
> of computer science, than new programmers who have an immediate
> practical need.
>
>
> > 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.
>
>
> > So this may be totally wrong for many of your purposes, but FWIW:
> > https://github.com/lspector/clojinc
>
>
> That's a nice idea.
>
> 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: How to go about 'proving' why dynamically typed languages are better

[juan.facorro]

Thanks for the link! I really liked the interview, it was interesting and 
fun to watch.

J

On Monday, October 7, 2013 9:49:24 AM UTC+9, brad bowman wrote:
>
> > zcaudate > Oct 05 08:35PM -0700 
> > I'm a little bit miffed over this current craze of `types` and 
> > `correctness` of programs. It smells to me of the whole `object` craze 
> of 
> > the last two decades. I agree that types (like objects) have their uses, 
> > especially in very well defined problems, but they have got me in 
> trouble 
> > over and over again when I am working in an area where the goal is 
> unclear 
> > and requirements are constantly changing. 
>
> Joe Armstrong and Simon Peyton Jones discuss Erlang and Haskell 
> http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell 
>
> This interview covers some of the strong-types vs flexible development 
> (apparent) dichotomy, but in a playful, open and non-dogmatic way. 
> (catmatic?) 
>
> Simon Peyton Jones is one of the Haskell leaders, yet admits to 
> being envious of type-free generics.  Joe Armstrong of Erlang fame 
> also sees the benefit to thinking in and annotating types. 
> These two are both leaders of typed or dynamic cults but have 
> a pleasant friendly and frank conversation about the issues. 
> (Erlang's Dialyzer sounds somewhat like core.typed) 
>
> A sample: 
>
> SPJ: So, I've told you what I most envy about Erlang. What do you most 
> envy 
> about Haskell? 
>
> JA: All the types. I mean they're very nice. I wish we had them. On the 
> other 
> hand, wouldn't you love to have all these generic turn-to-binary, these 
> sort 
> of things? How can you live without them? 
>
> SPJ: I have a little bit of residual envy about generics. 
>
> JA: You just take anything and compare it to the serializer and then send 
> it? 
>
> SPJ: That's sinfully easy, and shouldn't be allowed. 
>
>
> So if these two can agree that there's strengths and weaknesses in both 
> approaches, that settles it for me.  It's a matter of knowing your 
> trade-offs and choosing your tools appropriately. 
>
> My suspicion is that type affinity is related to some trait of 
> personality, 
> and so trying to "prove" superiority is a likely to work as "proving" you 
> are right in any other clash of personalities. 
>
> Brad 
>
>

-- 
-- 
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: Newbie seeks advice

[vMac]

Thank you very much James for that detailed advice. I think it will take a 
while
to get used to that new programming style.
Is there any good source of information for learning functional programming 
(online, book)
you could recommend?
I'm right now programming mostly C -stylish with a bit knowledge of OO.

-v

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

[Lee Spector]

On Oct 7, 2013, at 9:59 AM, John D. Hume wrote:
> I'd suggest that Clojure's "Hello, World!" should happen initially at the 
> repl, where leiningen definitely simplifies the UX.
> 
>lein repl # from any cwd
>(println "...")
> 
> which launches nicely into demonstrating dynamic development.

Agreed. But the complexity cliff is at the next step, after the first demo. 
Then you really want an editor with some basic features like auto-reindentation 
and bracket matching. 

In my teaching context the REPL alone will get us through a productive first 
day of class, but not a second, while something with roughly the feature set of 
Clooj will get us through the first semester and maybe even years of serious 
work depending on what kind of work we're doing.

-Lee

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

[John D. Hume]

On Oct 7, 2013 3:29 AM, "Phillip Lord"  wrote:
> 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.

I'd suggest that Clojure's "Hello, World!" should happen initially at the
repl, where leiningen definitely simplifies the UX.

lein repl # from any cwd
(println "...")

which launches nicely into demonstrating dynamic development.

If your students work with Java, I'd make a point of demonstrating the joy
of the Clojure repl + Java interop, useful even when your project is pure
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 suppress warnings?

[Marshall Bockrath-Vandegrift]

Gary Zhao  writes:

> I'm using core.async, but always see the following warnings. How do I
> suppress them? 

It looks like you are literally `:use`ing `core.async`, or doing a
`:require ... :refer :all`.  This is generally not what you want,
because you have no control over the vars now referred in your
namespace.  You’d fix the problem causing the warnings if you just
`:require` `core.async` in your `ns` declaration and only `:refer` in
specific vars you want to use w/o a namespace-prefix.

-Marshall

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

[whitespace]

Hello Nicola et al.,

I have only learned about  your CinC effort during last week with the news 
about core.typed.
I have ported the analyzer of the self-hosted cljs compiler to ClojureC: 
 https://github.com/schani/clojurec/pull/33 and can explore it from the 
metacircular scheme REPL already. It seems to work basically, but dynamic 
runtime primitives like namespaces, dynamic protocols, records, ... needed 
for the compiler are lacking. 

I want to proceed to a native REPL and statically compiled primitives in C 
which then can be used to interactively build and explore runtime design on 
this native REPL (linked C-libraries can be called natively and will be 
garbage collected as well if done properly). I *don't* see this as 
competition for any established runtime and I still would define ClojureC 
as the host and the environment as "hosted" as I really appreciate 
Clojure's hosted approach of decoupling the runtime from the language. I 
haven't sorted that out yet, though, as it means deciding how to link 
against libraries of the host (e.g. glib).

The motivation for the project is/was to write a Clojure runtime in Clojure 
itself with the help of ClojureC (mostly to learn about compilers and 
runtimes as I only develop with Clojure for 10 months now). I can picture 
it as a simple barebone which could be used to hook 
in https://github.com/halgari/clojure-metal/ or 
http://blog.danieljanus.pl/blog/2013/05/26/lithium-revisited/ into an 
already working REPL and explore (mixed) runtime building from there and 
lift JIT compiling and different runtime optimizations independently from 
this minimal Clojure implementation while adding the necessary static 
support for performance. The immutability aspects of Clojure also 
potentially allow more aggresive JIT optimizations through memoization, but 
this is only my speculation.

Up until now I just wanted to hack the compiler together to get some 
minimal Clojure REPL going before asking for help on this list (working 
with statically compiled C sucks feedback-wise). My idea was to use 
ClojureC's runtime closures like SICP does instead of an explicit bytecode 
to emit. I pictured that as Clojure in Clojure defined only in terms of the 
lambda-calculus (closures). But now I have doubts. I thought that a 
bytecode compiler could be done additionally/independtly and through 
rebinding of vars in the ClojureC runtime additional JIT compilers like the 
LLVM one of halgari could use their own bytecode (even different 
compilers/bytecodes during one runtime) to optimize these functions 
transparently. It would implement Clojure in Clojure completely without 
bytecode, but then this possibly defeats performance and does not make the 
barebone suitable for embedded applications (as memory consumption might 
bloat). It will be fairly slow anyway, but this is atm. no problem for me.
Now I am thinking about porting CinC instead and defining a native bytecode 
with you inspired by CinC needs and other bytecodes. I want to do that as a 
long-term project, the runtime will have little use in the near future as 
NodeJs and Lua are probably better hosts even for embedded applications.

What do you think? 

Christian

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

[Laurent PETIT]

IMHO, the question is irrelevant. It implicitly assumes that statically
typed vs dynamically typed is a black / white choice, and that either
"static wins over dynamic" or "dynamic wins over static" will be a true
statement whatever the context.

Bu still ... :

I assume you are talking about the difference in how types are handled
between e.g. Clojure and Java. Maybe I'm totally off-topic.

What do people used to Java fear a lot to lose if forced to use Clojure :

- code completion

- compiler errors


And they are right. You have less powerful code completion in Clojure right
now, by the very nature of the state of things. And you have way few
compiler errors.


I too like the fact that Typed Clojure is an optional feature, because then
I can quickly prototype code without bothering with entering types. But
this also means that I keep this information in my head, or in my comments.
Because there's no chance that my Clojure program will accept to add a
String and a Long at execution time.


I tend to think more in terms of "function contract", than in terms of
types. I want to choose the level of "function contract enforcement" I keep
in my head, or in my comments, or in my code. And then accept the
consequences of having to type more, to get faster feedback (the faster
being provided by the IDE, then the compiler, then the running code - and
my own ability to reason about the code floating here and there depending
on the moment).

Types are an implementation detail. They are just a subset of the kind of
assertions a compiler or a runtime can do over the arguments passed to a
function. They are just ONE property of each argument, and we're not even
talking about inter-arguments assertions, such as (< arg1 arg2), etc.

But after having said that, I still think that it will be good to be able
to declare types if I feel the need, because they have proven to detect
early a whole class of problems when I was doing Java !









2013/10/6 zcaudate 

> I'm a little bit miffed over this current craze of `types` and
> `correctness` of programs. It smells to me of the whole `object` craze of
> the last two decades. I agree that types (like objects) have their uses,
> especially in very well defined problems, but they have got me in trouble
> over and over again when I am working in an area where the goal is unclear
> and requirements are constantly changing.
>
> BTW... This is no means a criticism of all the type system work that is
> going on in the clojure community. I am a huge fan of Ambrose's Typed
> Clojure project because it gives me the *option *of using types... not
> shoving it down my throat. I like the freedom to choose.
>
> My experience of programming in clojure has freed me from thinking about
> types and hierarchies and this article rings so true:
> http://steve.yegge.googlepages.com/is-weak-typing-strong-enough.
>
> However, everywhere I look, there are smug type-weenies telling me that my
> dynamically typed program is bad because it cannot be `proven correct` and
> not `checked by the compiler`. This question on SO really makes me
> angry
> http://stackoverflow.com/questions/42934/what-do-people-find-so-appealing-about-dynamic-languages
> because no one is defending dynamic languages on there. The reason is very
> simple. because we don`t have a theory to back us up!
>
> I do want to put up an counter argument against this barrage of abuse
> against dynamic languages. And I want to put some academic weight behind
> this. The only counter I could come up with was to use Godel's
> incompleteness theorem. For those that don't know... here is an
> introduction to the man and his theory.
> http://www.youtube.com/watch?v=i2KP1vWkQ6Y. Godel's theorem, invalidated
> Principia Mathematica as a complete system of description. Principia
> Mathematica btw  effectively led to Type Theory.
>
>
> According to http://en.wikipedia.org/wiki/Type_theory. "The types of type
> theory were invented by Bertrand Russell in response to his discovery that
> Gottlob Frege's version of naive set theory was afflicted with Russell's
> paradox. This theory of types features prominently in Whitehead and
> Russell's Principia Mathematica. It avoids Russell's paradox by first
> creating a hierarchy of types, then assigning each mathematical (and
> possibly other) entity to a type. Objects of a given type are built
> exclusively from objects of preceding types (those lower in the hierarchy),
> thus preventing loops."
>
> I'm hoping to collect a few more `proofs` from the clojure community...
> for example... if there is a paper on "why are type systems so bad at
> classifying animals"... then please forward it on.
>
> --
> --
> 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 e

Re: Who uses HtmlUnit?

[Niels van Klaveren]

Didn't see this was posted in the general Clojure group, and thought this 
had been posted in another group.
So if you want to do any automated web testing be sure to check out 
clj-webdriver , the clojure 
library for Selenium Webdriver and it's Google 
Group
.
Selenium is the java platform for browser automation, supporting most 
browsers as well as headless browsers like HTMLunit and PhantomJS.

On Sunday, October 6, 2013 1:23:22 PM UTC+2, Magomimmo wrote:
>
> Hi all, 
> did anyone give a try to this java based HTMLUnit headless browser for 
> cljs unit test to be used of phantomjs? 
>
> http://htmlunit.sourceforge.net/ 
>
> Thanks 
>
> Mimmo 
>
>

-- 
-- 
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 suppress warnings?

[Jim]

I've not used core.async yet but it seems that you need the following in 
your ns declaration:


(:refer-clojure :exclude [map into reduce merge])

Jim

ps: with this you're not really suppressing the warnings but rather 
avoiding them in the first place :)




On 07/10/13 03:15, Gary Zhao wrote:

Hello

I'm using core.async, but always see the following warnings. How do I 
suppress them?


WARNING: map already refers to: #'clojure.core/map in namespace: 
message-bus.latam, being replaced by: #'clojure.core.async/map
WARNING: into already refers to: #'clojure.core/into in namespace: 
message-bus.latam, being replaced by: #'clojure.core.async/into
WARNING: reduce already refers to: #'clojure.core/reduce in namespace: 
message-bus.latam, being replaced by: #'clojure.core.async/reduce
WARNING: merge already refers to: #'clojure.core/merge in namespace: 
message-bus.latam, being replaced by: #'clojure.core.async/merge


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.


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

[Phillip Lord]

zcaudate  writes:
> I'm a little bit miffed over this current craze of `types` and 
> `correctness` of programs. It smells to me of the whole `object` craze of 
> the last two decades. 


Programming is a highly fashion-centric occupation for any number of
reasons. This shouldn't be a surprise.

> I agree that types (like objects) have their uses, especially in very
> well defined problems, but they have got me in trouble over and over
> again when I am working in an area where the goal is unclear and
> requirements are constantly changing.

Types are good. But they have overhead. 

One of the curious things about Clojure is that it can turn into a
strange mix of typed and untyped. I'm building a library in clojure
that, in turn, wraps a typed Java library. The types in Java are so
complex that one of my desires was to simplify that away. But,
ironically, I use a lot of reflection underneath to make it all work. If
I had type based dispatch (i.e. and yes, I know about multimethods), I
would use it lots.


> However, everywhere I look, there are smug type-weenies telling me that my 
> dynamically typed program is bad because it cannot be `proven correct` and 
> not `checked by the compiler`. 

But they are correct. You cannot answer this because it is true.

> I'm hoping to collect a few more `proofs` from the clojure community... for 
> example... if there is a paper on "why are type systems so bad at 
> classifying animals"... then please forward it on. 


Classifying animals is a difficult problem, although I quite liked this
paper when I read it. Don't bother if you were using a metaphor!

http://bioinformatics.oxfordjournals.org/content/24/13/i313.full


The best source for a counter argument would be to look at the
discussion comparing UML, design-driven approaches with the various
agile methodologies; the "less-is-more" argument is hard to push, but it
can work. For me, the main advantage is that you are not forced to build
complex hierarchies just to support the type system (and this holds for
Scala type languages with good type inferencing), and that having only a
few abstractions makes it worthwhile adding lots of functions operating
over them.

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

[Phillip Lord]

Lee Spector  writes:
> I teach Clojure, to beginning programmers among others.
>
> IMHO you really have to specify your audience(s) before any advice about how
> best to teach Clojure (or programming in general) will make much sense.

I'd absolutely agree with this. If you are teaching brand new
programmers, then you really don't want to teach clojure at all; you
want to teach programming, with the language being somewhat of a detail.

You also need to know *why* you are teaching them. I teach differently
if I am teaching new programmers hoping to gain a general understanding
of computer science, than new programmers who have an immediate
practical need.


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


> So this may be totally wrong for many of your purposes, but FWIW:
> https://github.com/lspector/clojinc


That's a nice idea.

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.