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

2013-12-24 Thread Cedric Greevey 
On Mon, Dec 23, 2013 at 7:37 PM, Rich Morin  wrote:

>   Media for Thinking the Unthinkable:
>   Designing a new medium for science and engineering
>   http://worrydream.com/MediaForThinkingTheUnthinkable/
>

Is this available in a form that is skimmable, is greppable, is cheap for
mobile users, can be perused at leisure, fits on a thumb drive, is
convertible for Kindle use, and doesn't require installing and enabling
notoriously insecure browser plugins to view, or is it only available as
video? :(

-- 
-- 
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: Om, a ClojureScript binding to Facebook's React

2013-12-24 Thread Nikita Prokopov 
Hi David,

cool work,

Just wondering, why in todomvc you rely so heavily onto #js literals, and 
prefer dsl-like syntax (dom/...) instead of some declarative markup like 
hiccup? Is it because of performance reasons?

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.

Finding available methods or docs for a value type

2013-12-24 Thread John Kida 
So i am very new to Clojure and I am wondering if there are any good 
techniques to finding available methods that will take a particular value. 
I understand this is probably very hard to do or even impossible being 
Clojure is a dynamic language and a lisp but for example.

Lets say i have a simple map data structure. Being new to Clojure i just 
start fiddling with the REPL, and try:
(keys my-hmap)
cool, got the keys from my map back. 

Now how about values
(values my-hmap)

nope. wrong method name..  I was able to quickly find it in the Clojure 
Data Structures documentation, where it had a few method names for 
examining a Map, and linked me to the Clojure Core API, is this something I 
should probably go through start to finish, so I have a good idea of what 
is available.

Or is there some technique I can use in the repl to tell me what methods 
are available to work with this particular datastructure.. that sounds not 
possible due to the dynamic lisp nature of clojure, but I wanted to ask the 
community to see if there were some good strategies to learning and finding 
available methods to work with a particular value.

-- 
-- 
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: Finding available methods or docs for a value type

2013-12-24 Thread Larry Staton Jr. 
John -

In the lein REPL, you can use (find-doc "some-string") to find related 
functions.

Also, I've found the Clojure cheat sheet to be 
helpful: http://clojure.org/cheatsheet

/ls

On Tuesday, December 24, 2013 8:58:29 AM UTC-5, John Kida wrote:
>
> So i am very new to Clojure and I am wondering if there are any good 
> techniques to finding available methods that will take a particular value. 
> I understand this is probably very hard to do or even impossible being 
> Clojure is a dynamic language and a lisp but for example.
>
> Lets say i have a simple map data structure. Being new to Clojure i just 
> start fiddling with the REPL, and try:
> (keys my-hmap)
> cool, got the keys from my map back. 
>
> Now how about values
> (values my-hmap)
>
> nope. wrong method name..  I was able to quickly find it in the Clojure 
> Data Structures documentation, where it had a few method names for 
> examining a Map, and linked me to the Clojure Core API, is this something I 
> should probably go through start to finish, so I have a good idea of what 
> is available.
>
> Or is there some technique I can use in the repl to tell me what methods 
> are available to work with this particular datastructure.. that sounds not 
> possible due to the dynamic lisp nature of clojure, but I wanted to ask the 
> community to see if there were some good strategies to learning and finding 
> available methods to work with a particular value.
>

-- 
-- 
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: Finding available methods or docs for a value type

2013-12-24 Thread Tim Visher 
My searching is failing, but I remember someone publishing a library
here that was meant to do exactly that. I can't remember if it was
based on arity or on fuzzing or whatever but IRRC it would do the sort
of thing you're asking for.

Hope someone else can use search better than me or have a better memory. :)

On Tue, Dec 24, 2013 at 8:58 AM, John Kida  wrote:
> So i am very new to Clojure and I am wondering if there are any good
> techniques to finding available methods that will take a particular value. I
> understand this is probably very hard to do or even impossible being Clojure
> is a dynamic language and a lisp but for example.
>
> Lets say i have a simple map data structure. Being new to Clojure i just
> start fiddling with the REPL, and try:
> (keys my-hmap)
> cool, got the keys from my map back.
>
> Now how about values
> (values my-hmap)
>
> nope. wrong method name..  I was able to quickly find it in the Clojure Data
> Structures documentation, where it had a few method names for examining a
> Map, and linked me to the Clojure Core API, is this something I should
> probably go through start to finish, so I have a good idea of what is
> available.
>
> Or is there some technique I can use in the repl to tell me what methods are
> available to work with this particular datastructure.. that sounds not
> possible due to the dynamic lisp nature of clojure, but I wanted to ask the
> community to see if there were some good strategies to learning and finding
> available methods to work with a particular value.
>
> --
> --
> 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: Finding available methods or docs for a value type

2013-12-24 Thread Michael Gardner 
On Dec 24, 2013, at 07:58 , John Kida  wrote:

> Or is there some technique I can use in the repl to tell me what methods are 
> available to work with this particular datastructure.. that sounds not 
> possible due to the dynamic lisp nature of clojure, but I wanted to ask the 
> community to see if there were some good strategies to learning and finding 
> available methods to work with a particular value.

I don’t know of a programmatic way to enumerate the fns that operate on a given 
type of data structure (would be nontrivial since Clojure is dynamically 
typed). But there are good references like clojuredocs.org (sadly not yet 
updated beyond Clojure 1.3, but still useful) and http://clojure.org/cheatsheet.

-- 
-- 
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: Om, a ClojureScript binding to Facebook's React

2013-12-24 Thread David Nolen 
On Tue, Dec 24, 2013 at 6:27 AM, Nikita Prokopov  wrote:

> Hi David,
>
> cool work,
>
> Just wondering, why in todomvc you rely so heavily onto #js literals, and
> prefer dsl-like syntax (dom/...) instead of some declarative markup like
> hiccup? Is it because of performance reasons?
>
> Thanks!


No. I just think Hiccup, not-Hiccup, or something else entirely should be
left up to users of the library.

David

-- 
-- 
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: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.

2013-12-24 Thread solo . levy 
Yes, after looking into this, upgrading the libraries before upgrade the 
Clojure version is unfeasible in our case. I prefer not to keep a 1.2 
environment around forever but take our time phasing it out to avoid 
service disruption. I think the dual environment consensus here is the way 
to go.

On Sunday, December 22, 2013 11:41:17 PM UTC-5, Rich Morin wrote:
>
> It sounds like the vast majority of these apps will simply sit on the 
> shelf, with no need to ever run them again.  So, as long as you have 
> a way to run them at need, in an accurate and acceptably prompt manner, 
> you don't have to worry about porting the code. 
>
> So, if you can keep a Clojure 1.2 environment around _forever_, this 
> may be a plausible strategy.  One way of doing this might be to create 
> a VM (eg, using VirtualBox) with all of the necessary apps, libraries, 
> programs, etc.  Burn this onto several CDs and save them in various 
> locations. 
>
> However, if you have to take an existing app and upgrade it in some 
> manner, you will probably want to upgrade the version of Clojure at 
> the same time.  In support of this, you might want to find a way to 
> create a mechanized way to recognize "issues we have seen before", 
> so that you can get a jump start on upgrading each revived app. 
>
> -r 
>
>  -- 
> http://www.cfcl.com/rdm   Rich Morin   
> r...@cfcl.com 
> http://www.cfcl.com/rdm/resumeSan Bruno, CA, USA   +1 650-873-7841 
>
> Software system design, development, and documentation 
>
>
>

-- 
-- 
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: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.

2013-12-24 Thread solo . levy 
That's exactly right. Almost all the report writers started their report by 
copying and pasting something previously and winging along. As a result, I 
see a lot of them with the same namespace setup but I suspect most of that 
functionality is not being used. I'm selling the idea that we'll need to 
maintain two environments in the short term. Because these reports quickly 
become obsolete, I suspect we'll be able to shutdown the 1.2 environment 
one year later. This would also give the writers the opportunity to port 
their reports over if they wish, and if anything is still active a year 
later, then it must be important and we can port them over.


On Sunday, December 22, 2013 10:46:33 PM UTC-5, Alex Miller wrote:
>
> One difficulty with this approach (which I largely following on a similar 
> operation a while back) is that the modular counterparts have continued 
> forward and in many cases are not API-compatible with the 1.2 version 
> anymore (tools.cli is one example that I remember from this transition as 
> its API changed significantly). In fact, some contrib libraries no longer 
> build or support 1.2 at all. In those cases, you're going to need to jump 
> both contrib and clojure version at the same time. 
>
> Before doing anything, I would do a census as to which of the 
> clojure.contrib namespaces are actually in use. Perhaps you examine them in 
> order from most recently run backwards.  I'm guessing that there is a 
> decent amount of duplication and copy/paste if you really have thousands of 
> these, so I suspect you'll see some patterns.
>
> On Sunday, December 22, 2013 6:07:26 PM UTC-6, solo...@gmail.com wrote:
>>
>> A third option I'm considering is to simply keep running 1.2 and replace 
>> the contrib libraries with their modular counterparts, moving to 1.5 only 
>> after that's done. The two difficulties I see here are:
>> 1) Ensuring all new reports written during this process use the modular 
>> libraries
>> 2) What to do about contrib libraries which have no counterpart (but this 
>> difficulty applies to all options)
>>
>> On Sunday, December 22, 2013 6:51:06 PM UTC-5, solo...@gmail.com wrote:
>>>
>>> At my company, we use Clojure for reporting. Specifically, reports are 
>>> written in Clojure which integrate data from a variety of sources and 
>>> display the final output to the user in a WPF-based webapp.
>>>
>>> For all intents and purposes, each 'report' is a standalone Clojure app, 
>>> and most of them use the contrib library. Not all of them are active, but 
>>> there are thousands. And I need to migrate them over to 1.5.
>>>
>>> Now I know the contrib libraries are not compatible with 1.3+. From what 
>>> I've read, the big change is related to dynamic var declaration, and there 
>>> are subtle incompatibilities involving certain scalars. I also looked at 
>>> this page for information on each library's migration:
>>> http://dev.clojure.org/display/community/Where+Did+Clojure.Contrib+Go
>>>
>>> I'm considering one of two approaches:
>>>
>>> 1) Run both Clojure 1.2 and 1.5, with all new reports required to use 
>>> the modular contrib libraries. This would require a change to the backend 
>>> appservers.
>>>
>>> 2) Grep the reports and create a list of all the distinct contrib 
>>> libraries we use. Identify which of the libraries have a modular analog, 
>>> and replace accordingly. To do this, I would need to check that the 
>>> function signatures match and the output is remains as expected. I would 
>>> also still need to run 1.2 running in production and 1.5 in a sandbox to 
>>> migrate reports over gradually.
>>>
>>> Asking individual authors to update their reports won't work.
>>>
>>> Please share your opinions on these approaches or what your experience 
>>> was in migrating from 1.2 to 1.3+.
>>>
>>> Also, is there an easier way which I'm not seeing? Thank you.
>>>
>>> Sol
>>>
>>>
>>>
>>>
>>>
>>>

-- 
-- 
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] Nightcode 0.2.0

2013-12-24 Thread Zach Oakes 
This is a new release of Nightcode , an IDE for 
Clojure and Java (we all know there aren't enough of those!). Here's a 
quick summary of what's been added since 0.1.0 was released three months 
ago:

-iOS compilation. You can now build iOS apps in Clojure and/or Java using 
an integrated copy of my plugin, lein-fruit
.
-iOS templates. There are standalone templates for normal iOS apps, and the 
game templates have also been updated (write your Clojure game once, and 
compile for desktop, Android, and iOS).
-Aesthetic improvements. You can switch to a lighter theme by running 
Nightcode with "-s light" on the command line. Also, a splash screen now 
appears while loading. Thanks to @kumarshantanu for the PRs!
-Integrated copy of lein-ancient . 
Just select a project.clj file and click "Check Versions", and it will run 
the plugin to check your dependencies.
-Non-U.S. keyboards now work better when paredit mode is on.

Some remaining problems I could use help with:

-Running the various Leiningen commands is quite slow, because I have to 
launch them in a separate process. This is because there are all sorts of 
subtle issues that could appear if I ran them in Nightcode's process. See issue 
#56 .
-On Windows, it appears that the process started by the "Run with REPL" 
button never stops, even when Nightcode exits. This button runs the 
equivalent of "lein repl". The process is created by Leiningen so I can't 
directly access it. See issue #59
.

-- 
-- 
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] Nightcode 0.2.0

2013-12-24 Thread Laurent PETIT 
2013/12/24 Zach Oakes 

> This is a new release of Nightcode , an IDE for
> Clojure and Java (we all know there aren't enough of those!). Here's a
> quick summary of what's been added since 0.1.0 was released three months
> ago:
>
> -iOS compilation. You can now build iOS apps in Clojure and/or Java using
> an integrated copy of my plugin, 
> lein-fruit
> .
> -iOS templates. There are standalone templates for normal iOS apps, and
> the game templates have also been updated (write your Clojure game once,
> and compile for desktop, Android, and iOS).
> -Aesthetic improvements. You can switch to a lighter theme by running
> Nightcode with "-s light" on the command line. Also, a splash screen now
> appears while loading. Thanks to @kumarshantanu for the PRs!
> -Integrated copy of lein-ancient .
> Just select a project.clj file and click "Check Versions", and it will run
> the plugin to check your dependencies.
> -Non-U.S. keyboards now work better when paredit mode is on.
>
> Some remaining problems I could use help with:
>
> -Running the various Leiningen commands is quite slow, because I have to
> launch them in a separate process. This is because there are all sorts of
> subtle issues that could appear if I ran them in Nightcode's process. See 
> issue
> #56 .
> -On Windows, it appears that the process started by the "Run with REPL"
> button never stops, even when Nightcode exits. This button runs the
> equivalent of "lein repl". The process is created by Leiningen so I can't
> directly access it. See issue 
> #59
> .
>

Counterclockwise shares these 2 issues
- #56 : there are parts where it's slow. The only place where I run
leiningen inside Eclipse is for computing dependencies classpath. And even
that, I from time to time consider externalizing it.
- #59: this same one explains why I haven't released the generic launcher
instead of the JDT launcher, earlier this year, when it was actually OK on
the leiningen branch. Problem with windows users prevented me to press the
"Release" button on this feature, and enter a looong hammock time.




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

2013-12-24 Thread Rich Morin 
On Dec 24, 2013, at 02:09, Cedric Greevey wrote:
> On Mon, Dec 23, 2013 at 7:37 PM, Rich Morin  wrote:
>   Media for Thinking the Unthinkable:
>   Designing a new medium for science and engineering
>   http://worrydream.com/MediaForThinkingTheUnthinkable/
> 
> Is this available in a form that is skimmable, is greppable, is cheap for 
> mobile users, can be perused at leisure, fits on a thumb drive, is 
> convertible for Kindle use, and doesn't require installing and enabling 
> notoriously insecure browser plugins to view, or is it only available as 
> video? :(

There is a video presentation, which could be downloaded and watched
at leisure (eg, on a smart phone).  I don't think this presents any
security issues.  The video is supplemented on the web page by several
interactive examples.  These require use of JavaScript and probably
would look pretty cramped on a cell phone's screen.

-r

 -- 
http://www.cfcl.com/rdm   Rich Morin   r...@cfcl.com
http://www.cfcl.com/rdm/resumeSan Bruno, CA, USA   +1 650-873-7841

Software system design, development, and documentation


-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Good resources on dataflow based programming

2013-12-24 Thread Daniel Kersten 
Here's some resources to get you started learning about dataflow as a
paradigm. From this you should be able to figure out how Pedestal's
dataflow system fits in.

A list of existing dataflow languages and systems:
http://stackoverflow.com/questions/461796/dataflow-programming-languages/949771#949771
I
would suggest looking into a few of these to learn the concepts. I'd also
suggest trying out one or more of the visual dataflow languages to get a
feel for how problems can be solved in this paradigm and how non-pure
functions fit in. I've personally used both Max/MSP and Synthmaker and
found the concepts really clicked after using them for a while.

A work in progress book on which you may also want to keep an eye:
http://dataflowbook.com/cms/

Also, if you can ignore the tone, this article has helped me better
understand how code fits together in a dataflow system (a flat hierarchy):
http://my.opera.com/Vorlath/blog/2008/07/25/hierarchies-and-equivalence and
this one talks about how dataflow differs from imperative programming:
http://my.opera.com/Vorlath/blog/2008/01/06/simple-example-of-the-difference-between-imperative-functional-and-data-flow
But
be warned that the author of those is very opinionated and feels that he is
writing about the "one true way" ;-)



On 23 December 2013 19:32, Stephen Cagle  wrote:

> < Cross posted from pedestal-users group, as many people who are not using
> pedestal may still know about dataflow, terms like effect are used in the
> context of pedestal >
>
> Pedestal seems strongly based on dataflow based programming. The gigantic
> tutorial just sort of jumps in on it.
>
> Based on my usage thus far, dataflow seems really good at modeling
> problems that are self contained. In their pure forms (no external inputs
> or internal effects), dataflow seems almost like a circuit diagram.
>
> However, I quickly get confused once we start dealing with effects. Seems
> that there is a large "Here be Dragons" area of code in that region
> (services.cljs).
>
> I feel that this may not be dataflow's fault; I just haven't got my head
> around it. When I look at dataflow, I feel like it is constraining me to a
> particular way of solving a problem. The upside of this is that I have made
> my logic declarative and potentially easier to reason about. This is a
> trade-offs that seems similar to the trade-offs one makes when moving from
> a mutable procedural programming model to a immutable functional model. I
> have yet to personally get substantial benefit from dataflow, but that does
> not mean I will not with more mastery.
>
> I am wondering if there are any any getting started guides for dataflow
> programming that you (the community) would recommend. I would be especially
> interested in "recipe books" for dataflow based programming. How do you
> really do asynchronous processing with dataflow? What if your asyncs may
> return in a random order but must be processed in a specified order? A few
> books/articles/whatever on how experts think through these problems could
> be quite beneficial.
>
> --
> --
> 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: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.

2013-12-24 Thread Sean Corfield 
On Tue, Dec 24, 2013 at 7:23 AM,   wrote:
> Yes, after looking into this, upgrading the libraries before upgrade the
> Clojure version is unfeasible in our case. I prefer not to keep a 1.2
> environment around forever but take our time phasing it out to avoid service
> disruption. I think the dual environment consensus here is the way to go.

Please keep us posted on how this goes - I think it's an interesting
case study for what happens with a large legacy code base.

Fortunately the 1.2 -> 1.3 changes were the biggest we've had to deal
with so far and all the signs indicate we won't have to deal with that
again, so this is a pain that only early adopters will be feeling.
-- 
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: Finding available methods or docs for a value type

2013-12-24 Thread Sean Corfield 
One thing you might find very helpful is Chas Emerick's
http://clojureatlas.com which lets you search on concepts (such as
maps) and see a cloud of all the related functions. It's a great way
to explore how various functions are related to each other and to
various data types.

You can use it for free but I expect Chas appreciates anyone who buys
access to it - it's very reasonably priced (I bought my access back
when it cost $40 and I've certainly got that value and more out of
it!).

Sean

On Tue, Dec 24, 2013 at 5:58 AM, John Kida  wrote:
> So i am very new to Clojure and I am wondering if there are any good
> techniques to finding available methods that will take a particular value. I
> understand this is probably very hard to do or even impossible being Clojure
> is a dynamic language and a lisp but for example.
>
> Lets say i have a simple map data structure. Being new to Clojure i just
> start fiddling with the REPL, and try:
> (keys my-hmap)
> cool, got the keys from my map back.
>
> Now how about values
> (values my-hmap)
>
> nope. wrong method name..  I was able to quickly find it in the Clojure Data
> Structures documentation, where it had a few method names for examining a
> Map, and linked me to the Clojure Core API, is this something I should
> probably go through start to finish, so I have a good idea of what is
> available.
>
> Or is there some technique I can use in the repl to tell me what methods are
> available to work with this particular datastructure.. that sounds not
> possible due to the dynamic lisp nature of clojure, but I wanted to ask the
> community to see if there were some good strategies to learning and finding
> available methods to work with a particular value.
>
> --
> --
> 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: How to go about 'proving' why dynamically typed languages are better.

2013-12-24 Thread Chris Zheng 

> Maybe this is the argument that zcaudate should use: Static typing is the 
> death of creativity.
> 
> Just kidding.

I'm doing a short study of how hair affects language design.

http://z.caudate.me/language-hair-and-popularity/

I'd be more than happy to draw up a chart of how many hours a person has spent 
proselytising static typed languages versus how many real world problem they 
have solved (although we may have to think this matrix because it is unclear to 
me how to get the data. I was thinking lines of code, but then java devs would 
win hands down).

-- 
-- 
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: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.

2013-12-24 Thread Alex Baranosky 
Hi Solo,

I did a big migration from 1.2 to 1.5 at work this past February.  Here are
a few of the things that I gleaned from that experience, i addition to the
great advice mentioned already in this thread:

* with 1000's of these applications, I'd take the approach of only
migrating to 1.5 when there's a change needed, because there's a good
chance a lot of them will never need to be modified.  Any extra apps you
need to migrate could be work down the drain.
* on the other hand, you can get a nice groove going, and may want to do a
bunch of reports in one go. The changes you may find can be repetitive.
* to make sure you are only including namespaces that absolutely need to be
used by your application, AND to convert the ns declarations into 1.5
format automatically I used https://github.com/technomancy/slamhound. Watch
out for any macro-heavy code though, because Slamhound can miss
dependencies used exclusively in macros.
* are these reports tested? If not well tested be wary, because there were
a lot of number-related changes from 1.2 to 1.3
* keep an eye out for duplicated patterns in the reports.  If there are
some common pieces you might be able to just migrate those to 1.5 and use
them as a library for the other reports. YMMV.
*

Best,
Alex

On Tue, Dec 24, 2013 at 10:48 AM, Sean Corfield wrote:

> On Tue, Dec 24, 2013 at 7:23 AM,   wrote:
> > Yes, after looking into this, upgrading the libraries before upgrade the
> > Clojure version is unfeasible in our case. I prefer not to keep a 1.2
> > environment around forever but take our time phasing it out to avoid
> service
> > disruption. I think the dual environment consensus here is the way to go.
>
> Please keep us posted on how this goes - I think it's an interesting
> case study for what happens with a large legacy code base.
>
> Fortunately the 1.2 -> 1.3 changes were the biggest we've had to deal
> with so far and all the signs indicate we won't have to deal with that
> again, so this is a pain that only early adopters will be feeling.
> --
> 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.
>

-- 
-- 
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: Om, a ClojureScript binding to Facebook's React

2013-12-24 Thread Conrad Barski 
On Tuesday, December 24, 2013 5:27:12 AM UTC-6, Nikita Prokopov wrote:
> Hi David,
> 
> cool work,
> 
> Just wondering, why in todomvc you rely so heavily onto #js literals, and 
> prefer dsl-like syntax (dom/...) instead of some declarative markup like 
> hiccup? Is it because of performance reasons?
> 
> Thanks!

I'm not David, but I'm guessing "performance reasons" is the answer. The React 
library relies on member functions to render html (React.DOM.div, 
React.DOM.input, etc) so this maps more efficiently onto a macro-based html 
rendering solution, as opposed to one based purely on EDN (like hiccup). Note 
that the approach used by Om is common in the Common Lisp & Scheme worlds 
(since those languages don't have clean map & vector literals like Clojure, the 
hiccup approach is more awkward in those languages.)

The #js literals can forwarded directly to the React.js library and are 
therefore also very efficient.

-- 
-- 
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: Om, a ClojureScript binding to Facebook's React

2013-12-24 Thread Conrad Barski 
(Should have written "DSL-based" not "macro-based"

On Tuesday, December 24, 2013 1:55:19 PM UTC-6, Conrad Barski wrote:
> On Tuesday, December 24, 2013 5:27:12 AM UTC-6, Nikita Prokopov wrote:
> > Hi David,
> > 
> > cool work,
> > 
> > Just wondering, why in todomvc you rely so heavily onto #js literals, and 
> > prefer dsl-like syntax (dom/...) instead of some declarative markup like 
> > hiccup? Is it because of performance reasons?
> > 
> > Thanks!
> 
> I'm not David, but I'm guessing "performance reasons" is the answer. The 
> React library relies on member functions to render html (React.DOM.div, 
> React.DOM.input, etc) so this maps more efficiently onto a macro-based html 
> rendering solution, as opposed to one based purely on EDN (like hiccup). Note 
> that the approach used by Om is common in the Common Lisp & Scheme worlds 
> (since those languages don't have clean map & vector literals like Clojure, 
> the hiccup approach is more awkward in those languages.)
> 
> The #js literals can forwarded directly to the React.js library and are 
> therefore also very efficient.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Good resources on dataflow based programming

2013-12-24 Thread Stephen Cagle 
Thank you. I only read the last two articles so far; some notes.

http://my.opera.com/Vorlath/blog/2008/01/06/simple-example-of-the-difference-between-imperative-functional-and-data-flow

I realized that I really wasn't getting what dataflow was about. I was 
viewing dataflow paths as a sort of hook that I could hang values on. I had 
never externalized the fact that each path only refers to the things it 
inputs upon. Specifically, I was modeling some of the patterns like path A 
passes a value to B, B does some computation, and puts the result on path 
A. This isn't neccessarily wrong, but it appears that I was using dataflow 
paths in a way similar to function evaluation. 

He makes a big deal out of not needing to know where his inputs come from, 
as well as not needing to invoke a function to create his inputs, but it 
still seems he must have a reference to his inputs.

The effectively automatic parallellization of the code is pretty neat. Not 
so much because it is parallelized (which can be done in other systems), 
but mostly because it required no forethought or synchronization. It is 
automatically parallelized and pipelined. Neato. Of course, we aren't going 
to get much of that in js without some work. 

The second to last paragraph was another head turner. I had previously 
viewed every dataflow node/path as a loop that just waits for a change in 
its inputs and computes a new value when one of them changes. However, in 
his system recursive calls are also parallelized and pipelined. I am not 
quite sure how this would be implemented, but it seems neat. Again though, 
probably not relevant to js.

http://my.opera.com/Vorlath/blog/2008/07/25/hierarchies-and-equivalence

This one is more of a philosophy/notice of intent piece. This one should 
probably be read after the previous article. If I hadn't read the previous 
article, I would understand the words he is saying, but not their 
implications. There were many parts in this article that I disagreed with, 
but it seems wasteful to argue over individual sentences.

Honestly, too many ideas came at me too fast. I would have to re-read at a 
later point to have much of an opinion. Having said that, the content may 
be good (or not), but I am not sure this article would change any opinions 
unless the person was already predisposed.

On Tuesday, December 24, 2013 9:39:58 AM UTC-8, Dan Kersten wrote:
>
> Here's some resources to get you started learning about dataflow as a 
> paradigm. From this you should be able to figure out how Pedestal's 
> dataflow system fits in.
>
> A list of existing dataflow languages and systems: 
> http://stackoverflow.com/questions/461796/dataflow-programming-languages/949771#949771
>  I 
> would suggest looking into a few of these to learn the concepts. I'd also 
> suggest trying out one or more of the visual dataflow languages to get a 
> feel for how problems can be solved in this paradigm and how non-pure 
> functions fit in. I've personally used both Max/MSP and Synthmaker and 
> found the concepts really clicked after using them for a while.
>
> A work in progress book on which you may also want to keep an eye: 
> http://dataflowbook.com/cms/
>
> Also, if you can ignore the tone, this article has helped me better 
> understand how code fits together in a dataflow system (a flat hierarchy): 
> http://my.opera.com/Vorlath/blog/2008/07/25/hierarchies-and-equivalence and 
> this one talks about how dataflow differs from imperative programming: 
> http://my.opera.com/Vorlath/blog/2008/01/06/simple-example-of-the-difference-between-imperative-functional-and-data-flow
>  But 
> be warned that the author of those is very opinionated and feels that he is 
> writing about the "one true way" ;-)
>
>
>
> On 23 December 2013 19:32, Stephen Cagle  >wrote:
>
>> < Cross posted from pedestal-users group, as many people who are not 
>> using pedestal may still know about dataflow, terms like effect are used in 
>> the context of pedestal >
>>
>> Pedestal seems strongly based on dataflow based programming. The gigantic 
>> tutorial just sort of jumps in on it. 
>>
>> Based on my usage thus far, dataflow seems really good at modeling 
>> problems that are self contained. In their pure forms (no external inputs 
>> or internal effects), dataflow seems almost like a circuit diagram. 
>>
>> However, I quickly get confused once we start dealing with effects. Seems 
>> that there is a large "Here be Dragons" area of code in that region 
>> (services.cljs).
>>
>> I feel that this may not be dataflow's fault; I just haven't got my head 
>> around it. When I look at dataflow, I feel like it is constraining me to a 
>> particular way of solving a problem. The upside of this is that I have made 
>> my logic declarative and potentially easier to reason about. This is a 
>> trade-offs that seems similar to the trade-offs one makes when moving from 
>> a mutable procedural programming model to a immutable functional model. I 
>> have yet to pers

Re: Good resources on dataflow based programming

2013-12-24 Thread Stephen Cagle 
One thing that I am seeing on a re-read is that I conflated the notion of 
the data flow function and the paths. I was sort of thinking that the data 
flow functions "sit" at a particular path location. Similar to how a value 
"sits" in a location in memory. It is more appropriate to say that the data 
flow function is associated (referred isn't quite right) with a particular 
path location. 

Taking this a bit further, a data flow function DOES NOT actually know who 
its inputs are. It only knows that it takes input values in/of a certain 
form. The schema that specifies how one set of paths map to another path 
are possibly separate from the schema that specifies which dataflow 
function is associated with which path.

On Tuesday, December 24, 2013 1:36:16 PM UTC-8, Stephen Cagle wrote:
>
> Thank you. I only read the last two articles so far; some notes.
>
>
> http://my.opera.com/Vorlath/blog/2008/01/06/simple-example-of-the-difference-between-imperative-functional-and-data-flow
>
> I realized that I really wasn't getting what dataflow was about. I was 
> viewing dataflow paths as a sort of hook that I could hang values on. I had 
> never externalized the fact that each path only refers to the things it 
> inputs upon. Specifically, I was modeling some of the patterns like path A 
> passes a value to B, B does some computation, and puts the result on path 
> A. This isn't neccessarily wrong, but it appears that I was using dataflow 
> paths in a way similar to function evaluation. 
>
> He makes a big deal out of not needing to know where his inputs come from, 
> as well as not needing to invoke a function to create his inputs, but it 
> still seems he must have a reference to his inputs.
>
> The effectively automatic parallellization of the code is pretty neat. Not 
> so much because it is parallelized (which can be done in other systems), 
> but mostly because it required no forethought or synchronization. It is 
> automatically parallelized and pipelined. Neato. Of course, we aren't going 
> to get much of that in js without some work. 
>
> The second to last paragraph was another head turner. I had previously 
> viewed every dataflow node/path as a loop that just waits for a change in 
> its inputs and computes a new value when one of them changes. However, in 
> his system recursive calls are also parallelized and pipelined. I am not 
> quite sure how this would be implemented, but it seems neat. Again though, 
> probably not relevant to js.
>
> http://my.opera.com/Vorlath/blog/2008/07/25/hierarchies-and-equivalence
>
> This one is more of a philosophy/notice of intent piece. This one should 
> probably be read after the previous article. If I hadn't read the previous 
> article, I would understand the words he is saying, but not their 
> implications. There were many parts in this article that I disagreed with, 
> but it seems wasteful to argue over individual sentences.
>
> Honestly, too many ideas came at me too fast. I would have to re-read at a 
> later point to have much of an opinion. Having said that, the content may 
> be good (or not), but I am not sure this article would change any opinions 
> unless the person was already predisposed.
>
> On Tuesday, December 24, 2013 9:39:58 AM UTC-8, Dan Kersten wrote:
>>
>> Here's some resources to get you started learning about dataflow as a 
>> paradigm. From this you should be able to figure out how Pedestal's 
>> dataflow system fits in.
>>
>> A list of existing dataflow languages and systems: 
>> http://stackoverflow.com/questions/461796/dataflow-programming-languages/949771#949771
>>  I 
>> would suggest looking into a few of these to learn the concepts. I'd also 
>> suggest trying out one or more of the visual dataflow languages to get a 
>> feel for how problems can be solved in this paradigm and how non-pure 
>> functions fit in. I've personally used both Max/MSP and Synthmaker and 
>> found the concepts really clicked after using them for a while.
>>
>> A work in progress book on which you may also want to keep an eye: 
>> http://dataflowbook.com/cms/
>>
>> Also, if you can ignore the tone, this article has helped me better 
>> understand how code fits together in a dataflow system (a flat hierarchy): 
>> http://my.opera.com/Vorlath/blog/2008/07/25/hierarchies-and-equivalence and 
>> this one talks about how dataflow differs from imperative programming: 
>> http://my.opera.com/Vorlath/blog/2008/01/06/simple-example-of-the-difference-between-imperative-functional-and-data-flow
>>  But 
>> be warned that the author of those is very opinionated and feels that he is 
>> writing about the "one true way" ;-)
>>
>>
>>
>> On 23 December 2013 19:32, Stephen Cagle  wrote:
>>
>>> < Cross posted from pedestal-users group, as many people who are not 
>>> using pedestal may still know about dataflow, terms like effect are used in 
>>> the context of pedestal >
>>>
>>> Pedestal seems strongly based on dataflow based programming. The 
>>> gigantic tutorial j

Re: get rid of reflection in proxy-super?

2013-12-24 Thread Matching Socks 
(Re Colin's note that a proxy gets damaged if super throws - goodness 
gracious!  Is it the same matter as Clojure Jira issue No.983?  It's marked 
as "minor" and affecting Clojure 1.3, and no one has voted for it.)


-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To 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: get rid of reflection in proxy-super?

2013-12-24 Thread Colin Fleming 
That is indeed the same issue, and it even includes a patch with a test!
I've voted for this one, please consider doing the same if this issue has
caught you. Link: http://dev.clojure.org/jira/browse/CLJ-983


On 25 December 2013 13:22, Matching Socks  wrote:

> (Re Colin's note that a proxy gets damaged if super throws - goodness
> gracious!  Is it the same matter as Clojure Jira issue No.983?  It's marked
> as "minor" and affecting Clojure 1.3, and no one has voted for it.)
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To 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: Good resources on dataflow based programming

2013-12-24 Thread Stephen Cagle 
Just a quick thought I had as I was walking home. 

Given an infinite number of cores, the time to process a set of dataflow 
functions is equivalent to the the time that the longest function took to 
do its processing. The efficiency is the (sum of time that all the dataflow 
functions took) / ( (count of the dataflow functions) * (the time of the 
longest running dataflow function) ). Given this, optimization is really 
simple. Take the longest running dataflow function, and see if you can 
somehow split it into smaller functions. Nothing profound here, but I 
thought it was interesting how "evident" optimizations might be when you 
use a dataflow processing model.

On Tuesday, December 24, 2013 3:50:43 PM UTC-8, Stephen Cagle wrote:
>
> One thing that I am seeing on a re-read is that I conflated the notion of 
> the data flow function and the paths. I was sort of thinking that the data 
> flow functions "sit" at a particular path location. Similar to how a value 
> "sits" in a location in memory. It is more appropriate to say that the data 
> flow function is associated (referred isn't quite right) with a particular 
> path location. 
>
> Taking this a bit further, a data flow function DOES NOT actually know who 
> its inputs are. It only knows that it takes input values in/of a certain 
> form. The schema that specifies how one set of paths map to another path 
> are possibly separate from the schema that specifies which dataflow 
> function is associated with which path.
>
> On Tuesday, December 24, 2013 1:36:16 PM UTC-8, Stephen Cagle wrote:
>>
>> Thank you. I only read the last two articles so far; some notes.
>>
>>
>> http://my.opera.com/Vorlath/blog/2008/01/06/simple-example-of-the-difference-between-imperative-functional-and-data-flow
>>
>> I realized that I really wasn't getting what dataflow was about. I was 
>> viewing dataflow paths as a sort of hook that I could hang values on. I had 
>> never externalized the fact that each path only refers to the things it 
>> inputs upon. Specifically, I was modeling some of the patterns like path A 
>> passes a value to B, B does some computation, and puts the result on path 
>> A. This isn't neccessarily wrong, but it appears that I was using dataflow 
>> paths in a way similar to function evaluation. 
>>
>> He makes a big deal out of not needing to know where his inputs come 
>> from, as well as not needing to invoke a function to create his inputs, but 
>> it still seems he must have a reference to his inputs.
>>
>> The effectively automatic parallellization of the code is pretty neat. 
>> Not so much because it is parallelized (which can be done in other 
>> systems), but mostly because it required no forethought or synchronization. 
>> It is automatically parallelized and pipelined. Neato. Of course, we aren't 
>> going to get much of that in js without some work. 
>>
>> The second to last paragraph was another head turner. I had previously 
>> viewed every dataflow node/path as a loop that just waits for a change in 
>> its inputs and computes a new value when one of them changes. However, in 
>> his system recursive calls are also parallelized and pipelined. I am not 
>> quite sure how this would be implemented, but it seems neat. Again though, 
>> probably not relevant to js.
>>
>> http://my.opera.com/Vorlath/blog/2008/07/25/hierarchies-and-equivalence
>>
>> This one is more of a philosophy/notice of intent piece. This one should 
>> probably be read after the previous article. If I hadn't read the previous 
>> article, I would understand the words he is saying, but not their 
>> implications. There were many parts in this article that I disagreed with, 
>> but it seems wasteful to argue over individual sentences.
>>
>> Honestly, too many ideas came at me too fast. I would have to re-read at 
>> a later point to have much of an opinion. Having said that, the content may 
>> be good (or not), but I am not sure this article would change any opinions 
>> unless the person was already predisposed.
>>
>> On Tuesday, December 24, 2013 9:39:58 AM UTC-8, Dan Kersten wrote:
>>>
>>> Here's some resources to get you started learning about dataflow as a 
>>> paradigm. From this you should be able to figure out how Pedestal's 
>>> dataflow system fits in.
>>>
>>> A list of existing dataflow languages and systems: 
>>> http://stackoverflow.com/questions/461796/dataflow-programming-languages/949771#949771
>>>  I 
>>> would suggest looking into a few of these to learn the concepts. I'd also 
>>> suggest trying out one or more of the visual dataflow languages to get a 
>>> feel for how problems can be solved in this paradigm and how non-pure 
>>> functions fit in. I've personally used both Max/MSP and Synthmaker and 
>>> found the concepts really clicked after using them for a while.
>>>
>>> A work in progress book on which you may also want to keep an eye: 
>>> http://dataflowbook.com/cms/
>>>
>>> Also, if you can ignore the tone, this article has helped me bett