Re: Is contributing to clojurescript is intentionally made hard ?
+1 On Saturday, January 19, 2013 11:47:56 PM UTC+4, Andy Fingerhut wrote: On Jan 18, 2013, at 3:52 PM, Sean Corfield wrote: On Fri, Jan 18, 2013 at 1:33 PM, Andy Fingerhut andy.fi...@gmail.com javascript: wrote: The issue that Clojure, its contrib libraries, and ClojureScript do not accept github pull requests has been brought up several times before on this email list in the past. Feel free to search the Google group for terms like pull request. Short answer: Rich Hickey prefers a workflow of evaluating patches, not pull requests. It is easier for him. My understanding is that with pull requests it becomes much harder to provide accountability for Intellectual Property which is a legal concern, and that's why we have a Contributor's Agreement. The patch process naturally falls out of the legal CA-covered process since each patch is clearly identified as belonging to a specific contributor - and submitting a patch comes with the responsibility of vouching for the legal status of that submission. Github's pull request process makes it all too easy to incorporate code that belongs to a Github account holder who is not covered by the legal agreement and places the burden of verification on screeners to verify the IP ownership. But let's not re-hash the issue of the CA. Folks can just read the archives and there's really nothing new to add... I won't rehash the issue, but will provide direct pointers to a couple of posts that led me to believe my statements above. Here is a link to the whole thread, with many posts on the then-just-being-started clojure-doc.org web site (which I'm pleased to see has certainly come a long way since early Oct 2012): https://groups.google.com/forum/?fromgroups=#!topic/clojure/jWMaop_eVaQ Scan a down to Jay Fields post from Oct 6 2012, and then to Rich Hickey's response later the same day. I don't have any inside info about Rich's preferences for patches outside of such public messages, but it definitely seems to be due to workflow preference issues, not legal issues. Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: MVC / Observer Immutable Data
It seems that those concepts can't be directly ported, because MVC and
Observer works with changing state, and in functional programming state is
usually doesn't change.
Can You please provide links to simple GUI examples that demonstrate such
techniques, like the TODO list for Backbone.js?
On Wednesday, October 31, 2012 4:09:41 AM UTC+4, Alexey Petrushin wrote:
MVC / Observer in Immutable Data
Can You please explain what are analogues of MVC / Observer techniques in
two cases:
1. Immutable Objects (OOP style)
2. Immutable Data (functional style)
For example let's consider following simple GUI example (You can try it
live here http://tinkerbin.com/0XDHRXIl click 'Run' button to start it
and wait 2 sec for text to appear)
It's built with JavaScript because it's easy to play and MVC / Observer
are very natural to it
// Model containing the data.
var Post = Backbone.Model.extend({})
var PostView = Backbone.View.extend({
initialize: function() {
// Registering view rendering method as
// an observer on the model.
this.model.on('all', this.render.bind(this))
},
// Every time state of model changes
// this method will be called.
render: function() {
// Printing value of model.text attriubute.
this.$el.html(this.model.get('text'))
return this
}
})
// Now, any time the model is updated the view will be also
// automatically updated.
post.set({text: hello, it's me})
But I don't quite understand how to do the same with Immutable OOP and
Functional styles, what ways are there?
Thanks, Alex.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
MVC / Observer Immutable Data
MVC / Observer in Immutable Data
Can You please explain what are analogues of MVC / Observer techniques in
two cases:
1. Immutable Objects (OOP style)
2. Immutable Data (functional style)
For example let's consider following simple GUI example (You can try it
live here http://tinkerbin.com/0XDHRXIl click 'Run' button to start it and
wait 2 sec for text to appear)
It's built with JavaScript because it's easy to play and MVC / Observer are
very natural to it
// Model containing the data.
var Post = Backbone.Model.extend({})
var PostView = Backbone.View.extend({
initialize: function() {
// Registering view rendering method as
// an observer on the model.
this.model.on('all', this.render.bind(this))
},
// Every time state of model changes
// this method will be called.
render: function() {
// Printing value of model.text attriubute.
this.$el.html(this.model.get('text'))
return this
}
})
// Now, any time the model is updated the view will be also
// automatically updated.
post.set({text: hello, it's me})
But I don't quite understand how to do the same with Immutable OOP and
Functional styles, what ways are there?
Thanks, Alex.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Rouge: Ruby + Clojure
By the way is there pure clojure lang specs, without dependency on java or some other tools? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure : a good start for non-programmers?
I believe the only question You should be considering - is it interesting to You? I should say - giving up because of Your age or Your self-esteem of Yourself is a bad idea. Clojure is complex language - but it doesn't really matter, the key point - if it's interesting to You and You are ready to put energy in it and work, if so - You'll solve it, if not - not. There are some things that are really hard and can be solved only by exceptionally talented people (some math problems, creating next killer app and making tons of money, other very complex problems) but programming (I mean usual programming) - isn't at that level of complexity. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Some feedback on clojurescript
... JIRA ... The contributions we've received so far have been stellar - so I'm inclined to think the barrier is an illusion. Yes it would, but by and large the users of ClojureScript are Clojure users. So we haven't seen much real interest in this yet. Basically, what You are saying is - we are fine with the current state (heavily bounded to Java, JIRA is also used mostly in Java land only) and absolutelly not interesting in the growth of clojure in alternative directions. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Some feedback on clojurescript
issues on JIRA Theres a barrier - You has to register to JIRA to submit issue - many people won't bother with that and just ignore small bugs or proposals vs. almost everyone has github account. JVM Yeah, would be nice to have JS-on-the-fly compiler (like CoffeeScript) Would be also nice to have Node.js and NPM support. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Dart
Dart is deadborn, it would be a waste of energy. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Sample application as showcase of Clojure DSL / Metaprogramming?
Not yet, but it definitely in my todo list :) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Sample application as showcase of Clojure DSL / Metaprogramming?
1. No compilation step, quick live prototyping in browser. 2. Pure browser environment, no need to install anything. -- 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
